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 I-02 Projektový zámer je vypracovaný v súlade s Vyhláškou MIRRI SR č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke a je určený na rozpracovanie detailných informácií prípravnej a iniciačnej fázy projektu.
Cieľom dokumentu je:

• popísať aktuálny stav (AS-IS), budúci stav (TO-BE) a navrhované riešenie projektu,
• poskytnúť podklady pre rozhodnutie o schválení a realizácii projektu,
• definovať projektové výstupy, obmedzenia, predpoklady a riziká,
• stanoviť harmonogram a rozpočet projektu,
• vyhodnotiť architektúru riešenia projektu v jednotlivých vrstvách,
• určiť požiadavky na prevádzku, údržbu a zdrojové kódy,
• popísať proces implementácie a preberania výstupov projektu.

Dokument zároveň slúži ako základný vstup pre vypracovanie nadväzujúcich výstupov:

• I-04 Katalóg požiadaviek,
• M-05 Analýza nákladov a prínosov,
• M-06 Evidencia eGovernment komponentov v MetaIS.

2.1Použité skratky a pojmy

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

Pre účely tohto projektu sa zavádza jednotný systém označovania požiadaviek, ktorý umožní ich jednoznačnú identifikáciu, jednoduchú správu a sledovanie v projektovej dokumentácii (najmä v Katalógu požiadaviek I-04).

• Funkcionálne (používateľské) požiadavky
• Označenie: FRxx
• Vysvetlenie:
  • F – funkcionálna (používateľská) požiadavka,
  • R – požiadavka,
  • xx – poradové číslo požiadavky.

Príklad:

• FR01 – Systém musí umožniť evidenciu podnetov od občanov.
• FR02 – Systém musí poskytovať export dát do formátu CSV/XML.

• Nefunkcionálne (kvalitatívne, výkonové) požiadavky

• Označenie: NRxx
• Vysvetlenie:
  • N – nefunkčná požiadavka (NFR),
  • R – požiadavka,
  • xx – poradové číslo požiadavky.

Príklad:

• NR01 – Dostupnosť systému musí byť minimálne 98,5 %.
• NR02 – Odozva systému pri vyhľadávaní údajov nesmie presiahnuť 3 sekundy.

• Ostatné typy požiadaviek

Podľa potrieb projektu je možné definovať aj ďalšie kategórie:

• SRxx – Security Requirements (bezpečnostné požiadavky).
  • SR01 – Všetky prenosy dát musia byť zabezpečené protokolom HTTPS/TLS.
• DRxx – Data Requirements (požiadavky na údaje).
  • DR01 – Systém musí ukladať všetky záznamy v súlade so zákonom o archívoch.
• IRxx – Integration Requirements (požiadavky na integráciu).

• IR01 – Systém musí umožniť export údajov pre napojenie na MetaIS

3.DEFINOVANIE PROJEKTU

3.1Manažérske zhrnutie

Obec Veľká Lomnica v súčasnosti nedisponuje žiadnymi dátami, ktoré by umožňovali kvalifikované rozhodovanie o rozvoji územia. Obec je významne dopravne zaťažená – cez jej územie prechádza hlavný cestné ťahy smerom na Kežmarok, Poprad a Vysoké Tatry. Dopravnú záťaž zvyšuje aj prítomnosť rekreačných rezortov a intenzívny turistický ruch. Rozhodovacie procesy sa preto opierajú najmä o subjektívne podnety, nie o systematicky zbierané údaje.

Predmetom projektu je inštalácia IoT senzorov v 22 lokalitách obce. Senzory (v podobe inteligentných kamier) budú schopné zbierať anonymizované údaje o dopravnej vyťaženosti a pohybe osôb. Získané dáta budú lokálne spracované a poskytované v štandardizovaných formátoch (CSV, XML/HTML) v súlade s požiadavkami prílohy č. 11 výzvy. Riešenie bude realizované ako lokálna inštalácia bez integrácie na iné informačné systémy, keďže obec v súčasnosti takýmito systémami nedisponuje.

Indikatívna výška finančných prostriedkov na realizáciu projektu predstavuje 329 321,00 EUR s DPH (hardvér, softvér, inštalácia).

Výstupy projektu budú určené nielen pre potreby obecného úradu, ale aj pre širokú verejnosť – obyvateľov a návštevníkov obce. Dáta umožnia obci efektívnejšie plánovať rozvoj dopravnej a technickej infraštruktúry, lepšie manažovať mobilitu a optimalizovať poskytovanie miestnych služieb. Súčasne projekt vytvorí základ pre ďalší rozvoj smart riešení založených na dátach.

Projekt bude financovaný z Programu Slovensko 2021–2027, opatrenie 1.2.2 – IoT, dáta a platformy. Žiadateľom a prijímateľom je Obec Veľká Lomnica, bez zapojenia partnerov. Projekt je realizovaný v rámci výzvy č. PSK-MIRRI-619-2024-ITI-EFRR.

3.2Motivácia a rozsah projektu

• Problém
  Obec Veľká Lomnica v súčasnosti nedisponuje dátami o doprave, parkovaní ani pohybe osôb. Rozhodnutia o dopravných opatreniach a investíciách do infraštruktúry sa prijímajú na základe subjektívnych podnetov, nie na základe merateľných údajov. Obec je pritom významne dopravne zaťažená – prechádza ňou hlavný cestný ťah na Poprad, Kežmarok a Vysoké Tatry, s vysokou návštevnosťou aj zo strany turistov a rezortov. Výsledkom sú dopravné zápchy, rizikové situácie a znížená kvalita života obyvateľov.
• Biznis procesy dotknuté projektom
  Projekt je zameraný na zlepšenie kľúčových procesov v správe obce:
• zber dát o pohybe osôb a dopravnej zaťaženosti v jednotlivých lokalitách,
• vyhodnocovanie kolíznych situácií a dopravných zápch,
• plánovanie investícií do infraštruktúry na základe dát (napr. nové priechody pre chodcov, úpravy križovatiek),
• plánovanie organizácie dopravy podľa reálnej vyťaženosti (dni a hodiny s najväčším dopravným problémom).
• Oblasť (agenda / životná situácia)
  Projekt sa zameriava na agendu doprava a mobilita v obci a na životné situácie, ktoré s tým súvisia:
• bezpečný a plynulý pohyb obyvateľov a návštevníkov po obci,
• dostupnosť a kapacita dopravnej infraštruktúry,
• efektívne využívanie verejných priestranstiev.
• Rozsah projektu
  Projekt sa týka obce Veľká Lomnica ako prijímateľa a jej obyvateľov a návštevníkov ako cieľovej skupiny. Predmetom je inštalácia IoT senzorov v 22 lokalitách obce. Dáta budú spracovávané lokálne a zverejňované ako otvorené údaje vo formátoch CSV a XML/HTML. Projekt sa netýka žiadnych iných ISVS, keďže obec v súčasnosti takýmto systémom nedisponuje.
• Motivácia a očakávaný budúci stav
  Motiváciou obce je prechod od subjektívneho rozhodovania k data-driven riadeniu obce. V budúcom stave bude obec využívať reálne dáta na plánovanie dopravných opatrení, investícií a organizácie dopravy. Tým sa zlepší plynulosť dopravy, skráti čas zápch a zvýši efektívnosť využívania verejného priestoru.
• Obmedzenia
  Hlavným obmedzením je proces verejného obstarávania, ktorý môže časovo predĺžiť začiatok realizácie. Ďalším limitom je kapacita obce v oblasti IT – obec nemá vlastný odborný tím, preto bude prevádzku riešenia zabezpečovať externý správca vybraný cez VO.

• ---

  

• Obrázok 1 Príklad vizualizácie motivácie pre realizáciu projektu

3.3Zainteresované strany/Stakeholderi

•  

  ID	Aktér / Stakeholder	Subjekt (názov / skratka)	Rola
  1	Žiadateľ a vlastník projektu	Obec Veľká Lomnica	Objednávateľ, prijímateľ NFP, vlastník dát a infraštruktúry
  2	Obyvatelia a návštevníci obce	Verejnosť	Koncoví používatelia, prispievajú podnetmi, využívajú výstupy vo forme otvorených dát
  3	Škola a zariadenia v obci	ZŠ Veľká Lomnica, MŠ, kultúrne zariadenia	Partneri využívajúci údaje o doprave a pohybe pre organizáciu činnosti
  4	Externý správca IT riešenia	Dodávateľ vybraný cez VO	Prevádzkovateľ a servisný partner IoT infraštruktúry
  5	Riadiaci orgán / poskytovateľ	PSK, MIRRI SR	Poskytovateľ NFP, dohľad nad implementáciou, kontrola plnenia ukazovateľov

  Tabuľka 2 Zainteresované strany (Stakeholderi)

   

3.4Ciele projektu

Tabuľka 3 Ciele projektu

3.5Merateľné ukazovatele (KPI)

•  

  ID	ID/Názov cieľa	Názov ukazovateľa (KPI)	Popis ukazovateľa	Merná jednotka	AS IS hodnoty (aktuálne)	TO BE hodnoty (cieľové)	Spôsob ich merania a pozn.
  1	Zaviesť systém zberu anonymizovaných dát v 22 lokalitách	Počet lokalít pokrytých IoT senzorom	Počet fyzicky nainštalovaných a funkčných IoT senzorov na území obce	počet lokalít	0	22	Automatizované hlásenia zo systému, odovzdávací protokol po inštalácii
  2	Zlepšiť rozhodovanie obce o investíciách a dopravných opatreniach na základe dát	Počet vypracovaných rozhodovacích podkladov na báze dát	Počet analýz / reportov využitých v rokovaniach zastupiteľstva alebo vedenia obce	počet reportov / rok	0	min. 4 ročne	Evidencia výstupov z dátovej platformy, doložené v zápisniciach zastupiteľstva
  3	Zvýšiť bezpečnosť a plynulosť dopravy v obci	Počet identifikovaných a riešených rizikových lokalít	Počet úsekov, kde na základe dát obec prijala opatrenia (napr. dopravné značenie, úprava priechodu, zmena parkovania)	počet lokalít	0	min. 5 lokalít do 1 roka po nasadení	Analýza dopravných dát, rozhodnutia zastupiteľstva, evidencia prijatých opatrení
  4	Zlepšiť dostupnosť informácií pre obyvateľov a návštevníkov	Počet zverejnených datasetov ako OpenData	Počet datasetov publikovaných na webovej stránke obce / v MetaIS	počet datasetov	0	min. 5 datasetov do konca projektu	Kontrola webového sídla obce, evidenčný protokol publikovania dát
  5	Špecifický cieľ výzvy – 1.2.2 IoT, dáta a platformy	Vybudovanie funkčného IoT riešenia pre zber a sprístupnenie dát	Existenčný ukazovateľ: systém bol vybudovaný, odovzdaný a nasadený do prevádzky	áno/nie	Nie	Áno	Zápisnica z preberania riešenia, protokol o ukončení implementácie

  Tabuľka 4 Merateľné ukazovatele

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

Definícia skupín koncových používateľov

Obyvatelia obce – motoristi (parkovanie, plynulosť premávky), chodci (bezpečné priechody, pohyb v centre).

Návštevníci a turisti – orientácia pri kaštieli, kultúrnom dome a športoviskách, dostupnosť parkovania.

Škola a rodičia žiakov – bezpečnosť žiakov pri príchode a odchode, menej kolízií áut a chodcov.

Obecný úrad a poslanci – analytické podklady pre investície, dopravné obmedzenia a parkovaciu politiku.

Persóny

Ján, 42 rokov, obyvateľ – denne cestuje autom do práce, potrebuje rýchlo zaparkovať v centre bez krúženia.

Anna, 35 rokov, matka dvoch detí – posiela deti pešo do školy, chce bezpečné priechody a menej áut v čase 7:30–8:00.

Peter, 28 rokov, turista – navštívi kaštieľ a potrebuje informáciu o parkovisku, aby nemusel hľadať voľné miesto.

Starosta, 55 rokov – rozhoduje o investíciách a chce mať dáta o doprave a parkovaní ako podklad pre zastupiteľstvo.

Používateľské potreby (formou príbehov)

Ako obyvateľ, chcem vedieť, či je voľné parkovanie v centre, aby som nestrácal čas a nezvyšoval dopravnú záťaž.

Ako rodič, chcem vedieť, či je ulica pri škole dopravne preťažená, aby som poslal dieťa bezpečne pešo.

Ako turista, chcem mať istotu, že pri kaštieli zaparkujem pohodlne, aby som využil služby obce.

Ako starosta, chcem mať rozhodovacie podklady z dát, aby som mohol investovať do dopravy na základe reálnych potrieb.

AS-IS stav

Obec dnes nedisponuje systematickým zberom dát o doprave a pohybe osôb. Rozhodovanie je založené na subjektívnych podnetoch od občanov.

TO-BE stav

Po realizácii projektu bude obec:

disponovať anonymizovanými dátami zo senzorov v 22 lokalitách,

mať automatizované reporty o doprave, parkovaní a pohybe,

poskytovať dáta ako otvorené údaje pre obyvateľov a partnerov,

využívať výstupy pre plánovanie infraštruktúry a bezpečnostných opatrení.

Používateľský prieskum

Metóda: štruktúrované rozhovory a dotazník so starostom, pracovníkmi úradu, zástupcami školy a vybranými obyvateľmi (vzorka 20 osôb).

Výsledky: identifikovaná potreba mať lepšie dáta o parkovaní, plynulosti dopravy a bezpečnosti detí.

Výstup: report používateľského prieskumu ako príloha projektového zámeru.

3.7Riziká a závislosti

Obmedzenia projektu

Rozsah výzvy: projekt je viazaný na opatrenie 1.2.2 (IoT, dáta a platformy), preto nie je možné zahrnúť iné typy infraštruktúrnych investícií (napr. výstavbu parkovísk alebo stavebné úpravy).

Technické limity: nasadenie senzorov sa obmedzí na 22 lokalít, ktoré boli vybrané na základe dopravnej a spoločenskej dôležitosti.

Finančný rámec: oprávnené výdavky sú limitované výškou alokácie a pravidlami výzvy (obmedzenie na obstaranie IoT zariadení, SW licencií, integrácie, nie však na nadväzné stavebné zásahy).

Časové obmedzenie: projekt musí byť ukončený v lehote realizácie definovanej vo výzve, čo limituje rozsah testovania a pilotných aktivít.

Legislatívne obmedzenia: systém musí rešpektovať GDPR – anonymizované dáta, bez sledovania konkrétnych osôb alebo ŠPZ.

Predpoklady úspešnej realizácie

Technická pripravenosť: dostupná elektrina a dátové pripojenie v lokalitách, kde budú senzory inštalované.

Organizačné zabezpečenie: obec disponuje kapacitami na riadenie projektu (projektový manažér, technický konzultant, účtovník).

Spolupráca partnerov: zapojenie školy, kultúrneho domu a miestnych združení do využívania a poskytovania spätnej väzby k dátam.

Integrácia na národnú platformu: IoT riešenie bude pripravené na pripojenie k Integračno-analytickej platforme (Príloha 11 výzvy) cez API a štandardizované rozhrania.

Finančné predpoklady: projekt bude financovaný z NFP s dofinancovaním z rozpočtu obce (spolufinancovanie min. 8 %).

Prevádzková udržateľnosť: obec zabezpečí servisné zmluvy na údržbu senzorov a softvéru počas obdobia udržateľnosti projektu.

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

1. 
   
   1. Detailný opis rozpočtu projektu a jeho prínosov

Nákladová stránka projektu

Celkový rozpočet projektu pozostáva z investičných a prevádzkových nákladov:

1. Investičné náklady (rok 0–1):
   • hardvér, softvér, inštalácia a konfigurácia: 329 111,43 € s DPH
   • paušálne výdavky (verejné obstarávanie, externý projektový manažment, projektová dokumentácia – 7 %): 23 037,80 €
   • Spolu oprávnené výdavky: cca 352 149,23 €
2. Spolufinancovanie:
   • 92 % (EÚ + ŠR), t. j. cca 323 977,29 €
   • 8 % (obec), t. j. cca 28 171,94 €
3. Prevádzkové náklady (rok 2–10):
   • základná SLA na úrovni 3 000 – 5 000 €/rok, ktorá pokrýva aktualizácie softvéru, monitoring a servis,
   • bežná správa systému bude zabezpečená interným zamestnancom obce (už dnes vykonáva správu webu a elektronickej úradnej tabule),
   • väčšie zásahy budú riešené formou individuálnych zákaziek.

➡ Predpokladané prevádzkové náklady v T10: cca 30 000 – 50 000 €.

Prínosy projektu (T10)

1. Kvantifikovateľné prínosy:
   • úspora pracovných kapacít (administratíva, monitoring): cca 12 000 €/rok (zodpovedá jednému pracovného úväzku),
   • efektívnejšie plánovanie údržby cintorína, cyklotrás, verejného osvetlenia a infraštruktúry: 5 000 – 10 000 €/rok,
   • optimalizácia investícií – dátové podklady umožnia nasmerovať zdroje tam, kde sú reálne potreby (odhad úspory 5 % kapitálových výdavkov obce).
2. Nekvantifikovateľné prínosy:
   • zvýšenie bezpečnosti detí pri školách a pohybu obyvateľov v rizikových lokalitách,
   • zlepšenie komfortu obyvateľov a návštevníkov,
   • transparentnosť vďaka open data (zverejňovanie agregovaných údajov na webe a e-tabuľi),
   • participácia verejnosti a podpora digitálnej transformácie,
   • možnosť budúceho rozšírenia o environmentálne senzory, smart osvetlenie či parkovací manažment.

Ukazovatele návratnosti

• Náklady T10: cca 382 000 – 402 000 € (investícia + low-cost prevádzka).
• Prínosy T10 (kvantifikovateľné): cca 170 000 – 220 000 €, bez započítania kvalitatívnych prínosov a optimalizácie investícií.
• Rok návratnosti: predbežne 7.–8. rok.
• Ukazovatele ENPV, FNPV, BCR: budú presne vypočítané až po určení dodávateľa, avšak predbežné hodnotenie ukazuje pozitívny trend (BCR > 1).

Zhrnutie

Projekt má realisticky nastavené investičné a prevádzkové náklady. Vďaka kombinácii externej SLA v nízkom rozsahu a internej správy systému sú prevádzkové náklady udržateľné aj pre obec Veľká Lomnica. Prínosy projektu sa prejavia nielen v úsporách a efektívnejšom riadení obecného majetku, ale aj v zvýšení bezpečnosti, transparentnosti a kvalite života obyvateľov.

3.8Stanovenie alternatív v biznisovej vrstve architektúry

• ARCHITEKTÚRA RIEŠENIA PROJEKTU

• Táto kapitola popisuje architektúru riešenia projektu v súlade s požiadavkami vyhlášky MIRRI SR č. 401/2023 Z. z. a metodickými pokynmi k spracovaniu projektových zámerov. Cieľom je preukázať, akým spôsobom plánované riešenie zapadá do architektonického rámca verejnej správy a aké zmeny nastanú v porovnaní so súčasným stavom.

  Projekt obce Veľká Lomnica sa zameriava na vybudovanie digitálnej infraštruktúry založenej na IoT senzoroch a analytickom softvéri, ktorá umožní zber, spracovanie a publikovanie anonymizovaných údajov z verejného priestoru. Keďže ide o projekt obstarania HW a SW s následnou implementáciou, hlavný dôraz je kladený na technologickú a aplikačnú vrstvu architektúry, pričom biznis vrstva sa popisuje v rozsahu vplyvu na procesy obce.

  Architektúra je spracovaná vo variantoch AS-IS (súčasný stav) a TO-BE (stav po realizácii projektu). Modely budú spracované v jazyku Archimate 3.0 s možnosťou exportu do formátov podporovaných systémom MetaIS. Evidencia komponentov bude priebežne aktualizovaná v súlade s § 12 ods. 1 písm. b) zákona č. 95/2019 Z. z. o informačných technológiách vo verejnej správe.

   

• 
  
  1. Stanovenie alternatív architektúry riešenia

• Cieľom tejto podkapitoly je stanoviť a porovnať možné alternatívy architektúry riešenia projektu. Výber alternatív prebieha dvojstupňovo:

• Multikriteriálna analýza (MCA) – v prvom kroku sa definujú a posúdia dostupné alternatívy podľa stanovených kritérií (technická uskutočniteľnosť, finančná náročnosť, udržateľnosť, súlad s potrebami obce).
• Hodnotenie nákladov a prínosov – do ďalšieho hodnotenia postupujú iba tie alternatívy, ktoré splnili všetky vylučovacie kritériá v MCA. Hodnotenie je spracované formou detailného opisu nákladovej a prínosovej stránky projektu (v horizonte T10), keďže projekt nepresahuje hranicu 1 000 000 € a nie je povinné spracovať samostatný dokument M-05 BC/CBA.

•  

  V súlade s metodikou je minimálny počet variantov stanovený na tri:

• nulový variant – obec nezrealizuje žiadnu investíciu, čo znamená zachovanie súčasného stavu (AS-IS),
• preferovaný variant – komplexné riešenie s dodávkou HW, SW a implementáciou analytickej platformy,
• minimalistický variant – základná verzia preferovaného variantu, ktorá realizuje iba nevyhnutné komponenty pre zber a ukladanie dát, bez rozšírených analytických a vizualizačných modulov.

• Porovnávanie alternatív sa nevzťahuje na dilemu medzi vývojom na „zelenej lúke“ a obstaraním krabicového riešenia (COTS), keďže žiadateľ nemôže vopred určiť, aké riešenie ponúknu uchádzači vo VO. Predmetom porovnania sú teda vyššie uvedené tri alternatívy, ktoré pokrývajú realistické scenáre realizácie projektu v obci.

   

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

•  

  Na základe identifikovaného rozsahu problému sa pre projekt vo Veľkej Lomnici navrhujú tri alternatívy riešenia biznis procesov:

• Nulový variant – obec nezavedie žiadnu digitálnu infraštruktúru; rozhodovanie ostáva na základe subjektívneho vnímania a manuálne získavaných podnetov.
• Minimalistický variant – nasadia sa len základné IoT senzory na hlavných ťahoch a v kritických lokalitách (napr. školy, križovatka Železničná/Farská). Dáta budú ukladané a základne vizualizované, bez pokročilých analytických modulov.
• Preferovaný variant – komplexné riešenie zahŕňajúce senzory vo viacerých lokalitách, centrálny server, analytický softvér (Axxon One Enterprise), open data publikáciu a dashboardy pre samosprávu.

• Výber alternatív v biznis vrstve bude realizovaný prostredníctvom multikriteriálnej analýzy (MCA), ktorá vyhodnotí mieru prínosu pre obec, technickú uskutočniteľnosť, udržateľnosť a finančnú primeranosť.

  Kritériá MCA (príklad pre projekt):

• Kritérium A (KO): riešenie musí priniesť dáta z hlavných dopravných ťahov → ak nie, alternatíva je vyradená.
• Kritérium B (KO): riešenie musí umožniť uchovávanie a export údajov v štruktúrovanej podobe (XML/CSV).
• Kritérium C (KO): riešenie musí byť technicky udržateľné min. 5 rokov (HW + SW).
• Kritérium D: rozsah nasadenia v ďalších lokalitách.
• Kritérium E: možnosť budúceho rozšírenia o ďalšie typy senzorov (hluk, ovzdušie, parkovanie).
• Kritérium F: úroveň prevádzkových nákladov vzhľadom na rozpočet obce.

• Hodnotenie alternatív (stručne):

• Nulový variant: nesplní kritériá A, B, C → vyradený.
• Minimalistický variant: splní A, B, C, ale obmedzený prínos v D a E.
• Preferovaný variant: spĺňa všetky kritériá a prináša najvyšší prínos pre obec.

•  

  KRITÉRIUM	ZDÔVODNENIE KRITÉRIA	STAKEHOLDER 1 (Starosta)	STAKEHOLDER 2 (Prednostka)	STAKEHOLDER 3 (Občania)
  Kritérium A (KO)	Riešenie musí priniesť dáta z hlavných dopravných ťahov.	X	X	X
  Kritérium B (KO)	Riešenie musí umožniť export údajov v štruktúrovanej podobe (XML/CSV).	X		X
  Kritérium C (KO)	Riešenie musí byť technicky udržateľné min. 5 rokov (HW + SW).	X	X	X
  Kritérium D (KO)	Rozsah nasadenia aj v ďalších lokalitách mimo hlavných ťahov.		X	X
  Kritérium E	Možnosť budúceho rozšírenia o ďalšie typy senzorov (hluk, ovzdušie, parkovanie).	X		X
  Kritérium F	Prevádzkové náklady musia byť primerané rozpočtu obce.	X	X	X

  Tabuľka 9  Príklad šablóny pre spracovanie MCA

  ZOZNAM KRITÉRIÍ	ALTERNATÍVA 1 (Minimalistický variant)	SPÔSOB DOSIAHNUTIA	ALTERNATÍVA 2 (Preferovaný variant)	SPÔSOB DOSIAHNUTIA
  Kritérium A (KO)	áno	Senzory na hlavných ťahoch (škola, križovatka).	áno	Pokrytie hlavných ťahov + ďalších lokalít v obci.
  Kritérium B (KO)	áno	Dáta sa ukladajú a exportujú vo formáte XML/CSV.	áno	Plná podpora štruktúrovaného exportu vrátane open data.
  Kritérium C (KO)	áno	HW a základný SW udržateľný min. 5 rokov.	áno	HW a SW riešenie so SLA podporou, garantovaná udržateľnosť.
  Kritérium D (KO)	nie	Lokalizácia len na najkritickejších bodoch, obmedzený rozsah.	áno	Pokrytie väčšiny sledovaných lokalít v obci.
  Kritérium E	nie	Bez rozšíriteľných modulov.	áno	Možnosť rozšíriť o ďalšie senzory (hluk, parkovanie).
  Kritérium F	áno	Nízke prevádzkové náklady.	áno	Prevádzkové náklady kryté v rozpočte, očakávané úspory z efektívnej správy.

  Tabuľka 10  Príklad šablóny pre vyhodnotenie MCA

  Návrh úpravy výstupu

• Variant 1 (nulový) – slúži ako kontrolný, do multikriteriálnej analýzy sa nezapája, slúži len na porovnanie.
• Variant 2 (minimalistický) – spĺňa povinné kritériá, ale má obmedzený rozsah (napr. iba 2–3 lokality).
• Variant 3 (preferovaný) – spĺňa všetky kritériá, zabezpečuje plný rozsah a rozšíriteľnosť riešenia.

• Do ďalšieho hodnotenia postupuje Variant 2 a Variant 3, pričom budú podrobnejšie popísané v kapitole „Náklady a prínosy projektu“.

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

• Alternatívy v aplikačnej vrstve nadväzujú na varianty definované v biznis vrstve. Ich úlohou je popísať, ktoré aplikačné moduly a funkcionality budú súčasťou riešenia a do akej miery naplnia potreby obce. Všetky moduly boli rozdelené do dvoch kategórií:

• NUTNÉ – základné aplikačné moduly, bez ktorých nie je možné projekt realizovať (napr. zber dát zo senzorov, základná vizualizácia, ukladanie údajov).
• PREFEROVANÉ – rozširujúce moduly, ktoré zvyšujú hodnotu projektu, prinášajú dodatočné prínosy (napr. rozšírené analytické funkcie, otvorené dáta, reporting pre participáciu občanov).
• Biznis alternatíva 1 (Nulový variant)
• Nerealizuje sa žiadny aplikačný modul, neexistuje žiadna funkcionalita.
• Slúži výlučne ako kontrolný variant v hodnotení nákladov a prínosov.
• Biznis alternatíva 2 (Minimalistický variant)
• Nutné moduly: základný zber dát z hlavných dopravných ťahov (školy, križovatky), jednoduchá vizualizácia.
• Preferované moduly: neuplatňujú sa.
• Rozsah je obmedzený na 2–3 merané lokality, výstupy slúžia predovšetkým pre interné rozhodovanie obce.
• Biznis alternatíva 3 (Preferovaný variant)
• Nutné moduly: komplexný zber dát z viacerých lokalít (školy, križovatky, cintorín, zberný dvor, cyklotrasa), centrálna vizualizácia, úložisko dát.
• Preferované moduly: rozšírené analytické funkcie, automatizované reporty pre starostu a zastupiteľstvo, publikácia agregovaných údajov ako open data, príprava na rozšírenie (napr. environmentálne senzory).
• Tento variant pokrýva všetky požiadavky obce a umožňuje ďalší rozvoj digitálnej infraštruktúry.

•  

  

  Obrázok 3  Znázornenie alternatív riešenia v aplikačnej vrstve

   

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

• Technologická vrstva určuje, na akom hardvéri a infraštruktúre bude bežať riešenie. Pri hodnotení sa zvážili tri základné prístupy:

• Variant 1 (nulový) – žiadne nové technológie, obec zostáva pri manuálnom zbere dát.
• Variant 2 (minimalistický) – lokálne senzory v obmedzenom rozsahu, dáta ukladané na menšie lokálne úložisko v rámci obce.
• Variant 3 (preferovaný) – komplexné nasadenie senzorov s centrálnym serverom a dátovým úložiskom umiestneným lokálne v obci, ktoré umožní rozšírenie o ďalšie senzory a publikovanie otvorených dát.
• Posúdenie možností umiestnenia
• Vládny cloud – neuvažuje sa, projekt nespadá pod ISVS a nemá požiadavky na napojenie do vládnej infraštruktúry.
• Hybridný model (časť cloud, časť lokálne) – vzhľadom na rozsah projektu a jeho cieľ (dáta pre obec) nie je ekonomicky ani technicky výhodný.
• Komerčný cloud – zamietnutý z dôvodu nákladov a trvalej závislosti od externého poskytovateľa.
• Výsledok hodnotenia

• Technologicky najvhodnejšia alternatíva pre obec je Variant 3 – lokálne riešenie s vlastným hardvérom, keďže:

• obec takto plne kontroluje spracovanie údajov,
• dáta sú uložené priamo v obci,
• riešenie je škálovateľné (možno doplniť nové senzory alebo aplikačné funkcie),
• prevádzkové náklady sú dlhodobo nižšie než pri cloude.

•  

   

• 
  
  1. Náhľad architektúry a popis budúceho cieľového produktu

• Táto kapitola nadväzuje na analýzu alternatív spracovanú v bode 5.1 a definuje budúci cieľový produkt projektu vo všetkých vrstvách architektúry. Popis predstavuje stav „TO BE“, ktorý bude po realizácii projektu využívaný obcou Veľká Lomnica.

  Budúci cieľový produkt projektu predstavuje digitálnu infraštruktúru založenú na IoT senzoroch, ktorá obci Veľká Lomnica umožní systematický zber, spracovanie a využívanie údajov z verejného priestoru. Riešenie je koncipované ako modulárne a rozšíriteľné, s dôrazom na lokálnu správu údajov, jednoduchú prevádzku a otvorenosť pre ďalší rozvoj.

• Biznis vrstva
• Hlavní používatelia: starosta, prednostka a poverený zamestnanec obecného úradu.
• Primárne ciele: získavanie dát o pohybe osôb, vozidiel a využívaní verejných priestranstiev ako podkladu pre rozhodovanie a plánovanie služieb.
• Sekundárni používatelia: občania – prostredníctvom publikovaných open data súborov.
• Očakávané prínosy: zlepšenie efektivity samosprávy, úspory pri údržbe a investíciách, vyššia participácia verejnosti na rozvojových aktivitách.
• Aplikačná vrstva
• Zber dát: aplikácia pre príjem dát zo senzorov v reálnom čase.
• Ukladanie: databázová vrstva pre štruktúrované uchovávanie dát v lokálnom úložisku.
• Vizualizácia a reporting: dashboardy pre vedenie obce a pravidelné výstupy vo forme mesačných prehľadov.
• Otvorené údaje: export agregovaných datasetov v štandarde open data (3★).
• Rozšíriteľnosť: možnosť pripojenia ďalších modulov (napr. senzory hluku, ovzdušia, parkovanie).
• Technologická vrstva
• IoT zariadenia: senzory pohybu osôb, vozidiel, vyťaženosti priestorov.
• Komunikačná infraštruktúra: káblové aj bezdrôtové pripojenie podľa lokality, využitie existujúcej elektrickej siete.
• Server a úložisko: lokálne umiestnený server v správe obce, ktorý zabezpečuje databázu, spracovanie a vizualizáciu údajov.
• Záložné zdroje: UPS pre zabezpečenie kontinuálnej prevádzky.
• Škálovateľnosť: architektúra umožňuje dopĺňať nové senzory a aplikačné funkcionality bez nutnosti zásahu do základnej infraštruktúry.

• ---

• Funkčné požiadavky
• Zber dát zo senzorov v reálnom čase.
• Ukladanie údajov v štruktúrovanej forme.
• Dashboardy a vizualizácie pre vedenie obce.
• Export otvorených údajov (open data).
• Možnosť dopĺňať ďalšie senzory a moduly.
• Nefunkčné požiadavky
• Prevádzková dostupnosť min. 95 %.
• Odolnosť zariadení voči poveternostným podmienkam (min. IP66, -20 °C až +50 °C).
• Škálovateľnosť riešenia bez zásadných investícií do základnej infraštruktúry.
• Jednoduché používateľské rozhranie pre administráciu.
• Anonymizácia údajov – žiadne osobné identifikátory.

•  

Obrázok 4  Návrh modelu TO BE

3.9Multikriteriálna analýza

Na základe identifikovaného rozsahu problému sa pre projekt vo Veľkej Lomnici navrhujú tri alternatívy riešenia biznis procesov:

• Nulový variant – obec nezavedie žiadnu digitálnu infraštruktúru; rozhodovanie ostáva na základe subjektívneho vnímania a manuálne získavaných podnetov.
• Minimalistický variant – nasadia sa len základné IoT senzory na hlavných ťahoch a v kritických lokalitách (napr. školy, križovatka Železničná/Farská). Dáta budú ukladané a základne vizualizované, bez pokročilých analytických modulov.
• Preferovaný variant – komplexné riešenie zahŕňajúce senzory vo viacerých lokalitách, centrálny server, analytický softvér (Axxon One Enterprise), open data publikáciu a dashboardy pre samosprávu.

Výber alternatív v biznis vrstve bude realizovaný prostredníctvom multikriteriálnej analýzy (MCA), ktorá vyhodnotí mieru prínosu pre obec, technickú uskutočniteľnosť, udržateľnosť a finančnú primeranosť.

Kritériá MCA (príklad pre projekt):

• Kritérium A (KO): riešenie musí priniesť dáta z hlavných dopravných ťahov → ak nie, alternatíva je vyradená.
• Kritérium B (KO): riešenie musí umožniť uchovávanie a export údajov v štruktúrovanej podobe (XML/CSV).
• Kritérium C (KO): riešenie musí byť technicky udržateľné min. 5 rokov (HW + SW).
• Kritérium D: rozsah nasadenia v ďalších lokalitách.
• Kritérium E: možnosť budúceho rozšírenia o ďalšie typy senzorov (hluk, ovzdušie, parkovanie).
• Kritérium F: úroveň prevádzkových nákladov vzhľadom na rozpočet obce.

Hodnotenie alternatív (stručne):

• Nulový variant: nesplní kritériá A, B, C → vyradený.
• Minimalistický variant: splní A, B, C, ale obmedzený prínos v D a E.

Preferovaný variant: spĺňa všetky kritériá a prináša najvyšší prínos pre obec

Tabuľka 9  Príklad šablóny pre spracovanie MCA

Tabuľka 10  Príklad šablóny pre vyhodnotenie MCA

Návrh úpravy výstupu

• Variant 1 (nulový) – slúži ako kontrolný, do multikriteriálnej analýzy sa nezapája, slúži len na porovnanie.
• Variant 2 (minimalistický) – spĺňa povinné kritériá, ale má obmedzený rozsah (napr. iba 2–3 lokality).
• Variant 3 (preferovaný) – spĺňa všetky kritériá, zabezpečuje plný rozsah a rozšíriteľnosť riešenia.

Do ďalšieho hodnotenia postupuje Variant 2 a Variant 3, pričom budú podrobnejšie popísané v kapitole „Náklady a prínosy projektu“.

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

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

Alternatívy v aplikačnej vrstve nadväzujú na varianty definované v biznis vrstve. Ich úlohou je popísať, ktoré aplikačné moduly a funkcionality budú súčasťou riešenia a do akej miery naplnia potreby obce. Všetky moduly boli rozdelené do dvoch kategórií:

• NUTNÉ – základné aplikačné moduly, bez ktorých nie je možné projekt realizovať (napr. zber dát zo senzorov, základná vizualizácia, ukladanie údajov).
• PREFEROVANÉ – rozširujúce moduly, ktoré zvyšujú hodnotu projektu, prinášajú dodatočné prínosy (napr. rozšírené analytické funkcie, otvorené dáta, reporting pre participáciu občanov).
• Biznis alternatíva 1 (Nulový variant)

• Nerealizuje sa žiadny aplikačný modul, neexistuje žiadna funkcionalita.
• Slúži výlučne ako kontrolný variant v hodnotení nákladov a prínosov.

• Biznis alternatíva 2 (Minimalistický variant)

• Nutné moduly: základný zber dát z hlavných dopravných ťahov (školy, križovatky), jednoduchá vizualizácia.
• Preferované moduly: neuplatňujú sa.
• Rozsah je obmedzený na 2–3 merané lokality, výstupy slúžia predovšetkým pre interné rozhodovanie obce.

• Biznis alternatíva 3 (Preferovaný variant)

• Nutné moduly: komplexný zber dát z viacerých lokalít (školy, križovatky, cintorín, zberný dvor, cyklotrasa), centrálna vizualizácia, úložisko dát.
• Preferované moduly: rozšírené analytické funkcie, automatizované reporty pre starostu a zastupiteľstvo, publikácia agregovaných údajov ako open data, príprava na rozšírenie (napr. environmentálne senzory).
• Tento variant pokrýva všetky požiadavky obce a umožňuje ďalší rozvoj digitálnej infraštruktúry.
  
  

Obrázok 3  Znázornenie alternatív riešenia v aplikačnej vrstve

3.11Stanovenie alternatív v technologickej vrstve architektúry

• Technologická vrstva určuje, na akom hardvéri a infraštruktúre bude bežať riešenie. Pri hodnotení sa zvážili tri základné prístupy:

• Variant 1 (nulový) – žiadne nové technológie, obec zostáva pri manuálnom zbere dát.
• Variant 2 (minimalistický) – lokálne senzory v obmedzenom rozsahu, dáta ukladané na menšie lokálne úložisko v rámci obce.
• Variant 3 (preferovaný) – komplexné nasadenie senzorov s centrálnym serverom a dátovým úložiskom umiestneným lokálne v obci, ktoré umožní rozšírenie o ďalšie senzory a publikovanie otvorených dát.
• Posúdenie možností umiestnenia
• Vládny cloud – neuvažuje sa, projekt nespadá pod ISVS a nemá požiadavky na napojenie do vládnej infraštruktúry.
• Hybridný model (časť cloud, časť lokálne) – vzhľadom na rozsah projektu a jeho cieľ (dáta pre obec) nie je ekonomicky ani technicky výhodný.
• Komerčný cloud – zamietnutý z dôvodu nákladov a trvalej závislosti od externého poskytovateľa.
• Výsledok hodnotenia

• Technologicky najvhodnejšia alternatíva pre obec je Variant 3 – lokálne riešenie s vlastným hardvérom, keďže:

• obec takto plne kontroluje spracovanie údajov,
• dáta sú uložené priamo v obci,
• riešenie je škálovateľné (možno doplniť nové senzory alebo aplikačné funkcie),
• prevádzkové náklady sú dlhodobo nižšie než pri cloude.

•  

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

• Táto kapitola nadväzuje na analýzu alternatív spracovanú v bode 5.1 a definuje budúci cieľový produkt projektu vo všetkých vrstvách architektúry. Popis predstavuje stav „TO BE“, ktorý bude po realizácii projektu využívaný obcou Veľká Lomnica.

  Budúci cieľový produkt projektu predstavuje digitálnu infraštruktúru založenú na IoT senzoroch, ktorá obci Veľká Lomnica umožní systematický zber, spracovanie a využívanie údajov z verejného priestoru. Riešenie je koncipované ako modulárne a rozšíriteľné, s dôrazom na lokálnu správu údajov, jednoduchú prevádzku a otvorenosť pre ďalší rozvoj.

• Biznis vrstva
• Hlavní používatelia: starosta, prednostka a poverený zamestnanec obecného úradu.
• Primárne ciele: získavanie dát o pohybe osôb, vozidiel a využívaní verejných priestranstiev ako podkladu pre rozhodovanie a plánovanie služieb.
• Sekundárni používatelia: občania – prostredníctvom publikovaných open data súborov.
• Očakávané prínosy: zlepšenie efektivity samosprávy, úspory pri údržbe a investíciách, vyššia participácia verejnosti na rozvojových aktivitách.
• Aplikačná vrstva
• Zber dát: aplikácia pre príjem dát zo senzorov v reálnom čase.
• Ukladanie: databázová vrstva pre štruktúrované uchovávanie dát v lokálnom úložisku.
• Vizualizácia a reporting: dashboardy pre vedenie obce a pravidelné výstupy vo forme mesačných prehľadov.
• Otvorené údaje: export agregovaných datasetov v štandarde open data (3★).
• Rozšíriteľnosť: možnosť pripojenia ďalších modulov (napr. senzory hluku, ovzdušia, parkovanie).
• Technologická vrstva
• IoT zariadenia: senzory pohybu osôb, vozidiel, vyťaženosti priestorov.
• Komunikačná infraštruktúra: káblové aj bezdrôtové pripojenie podľa lokality, využitie existujúcej elektrickej siete.
• Server a úložisko: lokálne umiestnený server v správe obce, ktorý zabezpečuje databázu, spracovanie a vizualizáciu údajov.
• Záložné zdroje: UPS pre zabezpečenie kontinuálnej prevádzky.
• Škálovateľnosť: architektúra umožňuje dopĺňať nové senzory a aplikačné funkcionality bez nutnosti zásahu do základnej infraštruktúry.

• ---

• Funkčné požiadavky
• Zber dát zo senzorov v reálnom čase.
• Ukladanie údajov v štruktúrovanej forme.
• Dashboardy a vizualizácie pre vedenie obce.
• Export otvorených údajov (open data).
• Možnosť dopĺňať ďalšie senzory a moduly.
• Nefunkčné požiadavky
• Prevádzková dostupnosť min. 95 %.
• Odolnosť zariadení voči poveternostným podmienkam (min. IP66, -20 °C až +50 °C).
• Škálovateľnosť riešenia bez zásadných investícií do základnej infraštruktúry.
• Jednoduché používateľské rozhranie pre administráciu.
• Anonymizácia údajov – žiadne osobné identifikátory.

•  

5.NÁHĽAD ARCHITEKTÚRY

• 
  
  1. Biznis vrstva
• 5.3.1 Návrh riešenia v biznis vrstve architektúry

AS-IS stav (súčasnosť):

• Obec Veľká Lomnica v súčasnosti nezbiera systematicky dáta z verejných priestranstiev.
• Rozhodovanie prebieha na základe skúseností starostu, prednostky a pracovníkov úradu, prípadne z podnetov občanov.
• Neexistuje automatizovaný systém, ktorý by poskytoval štruktúrované dáta o využívaní verejných priestorov, pohybe obyvateľov a návštevníkov alebo dopravných tokoch.
• Žiadne koncové služby v oblasti IoT nie sú evidované v MetaIS.
• Optimalizačná príležitosť: zavedením dátového zberu a analytiky možno podstatne zlepšiť kvalitu rozhodovania, skrátiť čas prípravy podkladov a znížiť chybovosť vyplývajúcu zo subjektívnych odhadov.

TO-BE stav (cieľ):

• Projektom sa vybuduje IoT infraštruktúra (senzory, server, aplikácie), ktorá umožní automatizovaný zber a spracovanie údajov.
• V budúcom stave bude obec disponovať digitálnym nástrojom na podporu rozhodovania. Dáta budú pravidelne exportované v štruktúrovanej podobe a využité ako open data.
• Proces rozhodovania sa opiera o agregované údaje namiesto manuálnych odhadov.
• Obec bude schopná monitorovať kľúčové ukazovatele – napr. intenzitu pohybu na vybraných lokalitách, vyťaženie verejných priestorov, dlhodobé trendy.
• GAP analýza: rozdiel medzi súčasným a budúcim stavom spočíva v prechode od manuálneho a subjektívneho rozhodovania k dátami podloženému a automatizovanému prístupu.

Prehľad Koncových služieb (výstupy projektu, ktoré sa zaevidujú v MetaIS):

1. Služba zberu dát z verejného priestoru – plánovaná, výstupom sú štruktúrované dáta.
2. Služba sprístupnenia agregovaných údajov (open data) – plánovaná, výstupom sú dataset-y na využitie verejnosťou.
3. Služba podpory rozhodovania pre samosprávu – plánovaná, prostredníctvom dashboardov a pravidelných prehľadov.

Ukazovatele a metriky:

• Počet monitorovaných lokalít: AS-IS = 0, TO-BE = min. 3.
• Frekvencia spracovania dát: AS-IS = manuálne/občasné, TO-BE = automatizované, denne.
• Dostupnosť otvorených datasetov: AS-IS = 0, TO-BE = min. 1 dataset / mesiac.
• Úspora času pri rozhodovaní: AS-IS = kvalitatívny odhad (subjektívne), TO-BE = objektívne dáta → očakávaná úspora 20–30 %.
• Zapojenie verejnosti: AS-IS = minimálne, TO-BE = participácia prostredníctvom dostupných open data.

Obrázok č.5  Stav  (AS IS)

Obrázok č. 6 Stav (TO BE)

Tabuľka č.11 GAP analýza – Biznis vrstva

1. 
   
   1. 
      
      1. Prehľad koncových služieb – budúci stav (TO BE):

Tabuľka 12 Prehľad koncových služieb - budúci stav (TO BE)

1. 
   
   1. 
      
      1. Organizačné zmeny a Procesy dotknuté navrhovaným riešením

Organizačné zmeny

• Nová zodpovednosť:
  Na obecnom úrade bude určený poverený pracovník zodpovedný za správu systému zberu a spracovania údajov.
• Podporná úloha:
  Prednostka obce bude koordinovať využívanie dát pri rozhodovaní a bude prizývať ďalších odborníkov úradu podľa potreby (napr. stavebný úrad, oddelenie údržby).
• Externá podpora:
  Externý projektový manažér bude počas realizácie a prvých rokov prevádzky metodicky viesť procesy využívania dát.
• Bez vytvárania novej organizačnej jednotky:
  Zmeny sa riešia v rámci existujúcich kapacít, nevzniká nová sekcia ani odbor.

Tabuľka 13  Procesy dotknuté riešením

• Stručné zhrnutie
• Projektom nedochádza k zlučovaniu alebo vytváraniu nových oddelení, ide o presun zodpovedností na existujúcich zamestnancov.
• Vzniká nový proces využívania dát pri rozhodovaní a plánovaní, ktorý nahrádza ad hoc postupy.
• Procesné diagramy budú vypracované podľa metodiky MV SR, pričom pre projekt Veľká Lomnica nejde o procesy zahrnuté do národného projektu Optimalizácia procesov vo verejnej správe (EVS).

1. 
   
   1. 
      
      1. Jazyková podpora lokalizácia

Jazyková podpora používateľského rozhrania

• Primárnym jazykom riešenia bude slovenčina.
• Používateľské rozhranie administrácie a výstupné vizualizácie budú dostupné v slovenčine.
• V prípade potreby rozšírenia systému o verejne prístupné moduly (napr. open data portál s vizualizáciami) je riešenie navrhnuté tak, aby bolo možné doplniť ďalšie jazykové mutácie (najmä angličtinu).
• Lokalizácia výstupov

• Otvorené údaje budú publikované v štandardizovaných formátoch (napr. CSV, XML, JSON), ktoré sú jazykovo nezávislé.
• Ak budú vytvárané správy alebo vizualizácie pre verejnosť, budú primárne v slovenskom jazyku s možnosťou rozšírenia o anglickú verziu pre cudzincov (napr. turistov alebo odbornú verejnosť).

• Používatelia zo zahraničia

• Riešenie je určené prioritne pre obyvateľov obce a vedenie obce.
• V prípade poskytovania otvorených dát pre odbornú verejnosť sa predpokladá, že dáta môžu byť využívané aj používateľmi z členských štátov EÚ alebo iných krajín.
• Na tento účel je zabezpečená jazyková nezávislosť datasetov a možnosť doplniť anglické metadáta.

• Požiadavky do Katalógu požiadaviek

1. Používateľské rozhranie musí byť lokalizované v slovenskom jazyku.
2. Riešenie musí umožniť doplnenie ďalších jazykových mutácií (minimálne angličtiny).
3. Všetky otvorené údaje musia byť poskytované v štandardizovanom, jazykovo nezávislom formáte (CSV, XML, JSON).
4. Metadáta publikovaných datasetov musia byť dostupné minimálne v slovenčine a angličtine.
   1. Aplikačná vrstva

5.4.1 Návrh riešenia v aplikačnej vrstve architektúry

• AS-IS stav
• Obec Veľká Lomnica nemá vybudovaný samostatný informačný systém pre zber a spracovanie údajov z verejného priestoru.
• K dispozícii sú len čiastkové aplikácie (napr. evidencia webovej stránky obce, elektronická úradná tabuľa), ktoré nie sú prepojené s procesmi zberu a analýzy dát.
• Neexistuje žiadna aplikačná služba, ktorá by podporovala koncové služby v oblasti získavania dát o mobilite, vyťaženosti priestorov alebo plánovaní údržby infraštruktúry.
• Integrácie s externými IS alebo spoločnými modulmi eGovernmentu sa v tejto oblasti nevyužívajú.
• TO-BE stav

Navrhované riešenie doplní aplikačnú architektúru o nové komponenty:

• Informačný systém IoT dát (nový ISVS komponent) – centrálna aplikácia pre príjem, spracovanie a ukladanie údajov zo senzorov.
• Aplikačné služby:
  1. Zber dát zo senzorov – príjem dát v reálnom čase.
  2. Ukladanie a správa dát – databázová služba pre štruktúrované dáta.
  3. Analytická a vizualizačná služba – dashboardy, grafy, mesačné prehľady pre vedenie obce.
  4. Open Data export – agregované dataset-y publikované v CSV/XML/JSON.
• Vzťahy na biznis vrstvu:
  • Podpora koncovej služby „Rozhodovanie na základe dát“.
  • Podpora životnej situácie „Plánovanie investícií a údržby verejných priestorov“.
• Integrácie:
  • V prvej fáze samostatné riešenie bez integrácie na iné ISVS.
  • Architektúra umožňuje budúce napojenie na externé moduly prostredníctvom API (napr. Open Data portály).

• GAP analýza (rozdiely medzi AS-IS a TO-BE)

• Chýba vs. pribudne: v súčasnosti neexistuje aplikačná podpora, po projekte vznikne kompletný ISVS komponent pre IoT dáta.
• Nové aplikačné služby: Zber dát, Ukladanie dát, Vizualizácia, Open Data export.
• Zmena v poskytovaní služieb: namiesto manuálneho, ad-hoc rozhodovania bude obec využívať digitalizované dáta.
• Podpora koncových služieb: pôvodne žiadna, po realizácii jasná väzba na rozhodovacie procesy samosprávy a participáciu občanov.

Tabuľka č. 14  Prehľad aplikačných služieb

Tabuľka 15  – Prehľad eGovernment komponentov

Projekt nezahŕňa napojenie na žiadne spoločné moduly verejnej správy SR (napr. ÚPVS, RPO, DCOM, IAM).
Rovnako nie je plánovaná žiadna externá integrácia na informačné systémy tretích strán.
Všetky spracované dáta budú ukladané lokálne v správe obce Veľká Lomnica a výstupy budú poskytované formou súborov (XML/CSV).

Projekt nepredpokladá žiadne integrácie medzi budovanými eGovernment komponentmi a inými externými systémami. Z tohto dôvodu nebude vytvorený žiadny integračný vzťah, ktorý by bolo potrebné evidovať ako súčasť výstupu M-06.

1. 
   
   1. 
      
      1. Rozsah informačných systémov – budúci stav (TO BE)

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

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

1. 
   
   1. 
      
      1. Prehľad plánovaných integrácií na iné ISVS  – budúci stav (TO BE)

1. 
   
   1. 
      
      1. Aplikačné služby pre Koncové služby – budúci stav (TO BE)

1. 
   
   1. 
      
      1. Aplikačné služby na integráciu – budúci stav (TO BE)

1. 
   
   1. Dátová architektúra

  Projekt nepracuje s osobnými údajmi. Zberané údaje sú agregované počty a intenzity (osoby, vozidlá, cyklisti, vyťaženosť lokality) bez identifikátorov osôb alebo EČV.

  Doménový model je zameraný na merania v čase a priestore a na agregované metriky pre rozhodovanie samosprávy a publikovanie otvorených údajov.

  Štandardy: formáty CSV/XML/JSON, metadáta pre open data podľa DCAT-AP; časy v ISO 8601, súradnice vo WGS84.

  Interoperabilita: identifikátory lokalít (miest inštalácie) budú interné kódy obce; ak to bude účelné, je možné doplniť URI obce (napr. z RPO/REGOB) na identifikáciu správcu datasetov.

1. 
   
   1. 
      
      1. Objekty evidencie

.

• Riadenie životného cyklu údajov
• Tvorba údajov: kontinuálny príjem z IoT zariadení → validácia (formát, rozsah, výpadky) → uloženie do primárnej tabuľky Measurement.
• Agregácia: denné a mesačné dávky (ETL) vytvoria AggregatedMetric (sumy/mediány/percentily podľa potreby).
• Kvalita dát: automatické kontroly (duplicita, outliers, chýbajúce intervaly), log výnimiek, reprocessing po dotiahnutí oneskorených meraní.
• Verzionovanie datasetov: každá nová publikácia Dataset dostane verziu (v1, v2…) a dátum vydania.
• Retenčná politika:
  • Measurement (surové dáta) – uchovávanie 24 mesiacov.
  • AggregatedMetric – min. 5 rokov (pre trendové analýzy).
  • Dataset (open data) – bez obmedzenia; archivácia verzií.
• Zálohovanie: denné inkrementálne, týždenné plné zálohy; obnova testovaná 2× ročne.
• Publikovanie open data: mesačne (minimálne), formáty CSV+JSON, metadáta DCAT-AP (producent, licencie, periodicita, priestorový a časový rozsah).

• ystematický manažment údajov (Data Governance)
• Dátový kurátor (dátový architekt) – poverený zamestnanec obce
  • správa doménového modelu a dátových slovníkov,
  • dohľad nad kvalitou, retenčnou politikou a publikovaním datasetov,
  • koordinácia požiadaviek na zmeny (Change log),
  • komunikácia s dodávateľom (SLA, incidenty) a s komunitou open data.
• Procesy Data Governance (RACI skratka):
  • Definícia štruktúr a metadát – R: kurátor, A: prednostka, C: externý PM, I: starosta.
  • Publikovanie open data – R: kurátor, A: prednostka, C: IT podpora, I: verejnosť.
  • Kvalita a audit dát – R: kurátor, A: prednostka, C: dodávateľ, I: vedenie obce.

Tabuľka 16  Objekty evidencie

1. 
   
   1. 
      
      1. Referenčné údaje

V rámci projektu obce Veľká Lomnica nie sú vytvárané nové objekty evidencie ani atribúty, ktoré by bolo možné alebo potrebné vyhlásiť za referenčné. Projekt pracuje výlučne s technickými a anonymizovanými údajmi zo senzorov (pohyb, intenzita dopravy, vyťaženosť priestorov), ktoré nespadajú do kategórie referenčných údajov podľa definície v NKIVS a v rámci legislatívy SR.
Z tohto dôvodu sa tabuľka návrhu referenčných údajov vyplnila s poznámkou, že sa projekt nedotýka referenčných registrov ani údajov spravovaných v IS CSRÚ/CPDI.

Tabuľka 17  Návrh na vyhlásenie a zmeny referenčných údajov

1. 
   
   1. 
      
      1. Poskytovanie údajov z ISVS do IS CPDI – budúci stav (TO BE)

Projekt obce Veľká Lomnica nepredpokladá poskytovanie údajov z budovaných komponentov do IS CPDI (kód MetaIS = isvs_5836, pôvodne IS CSRÚ).
Riešenie je založené na spracovaní a využívaní anonymizovaných senzorických údajov (pohyb, doprava, vyťaženosť verejných priestorov), ktoré nemajú charakter referenčných údajov a nie sú určené na výmenu prostredníctvom IS CPDI.
Všetky výstupy budú poskytované v podobe open data datasetov publikovaných obcou a nebudú predmetom centrálnej integrácie v rámci CPDI.
Z tohto dôvodu zostáva tabuľka č. 20 prázdna.

Tabuľka 18  Poskytovanie údajov z ISVS do IS CPDI – budúci stav (TO BE)

1. 
   
   1. 
      
      1. Konzumovanie údajov z IS CPDI – budúci stav (TO BE)

Projekt obce Veľká Lomnica nepredpokladá konzumovanie údajov z IS CPDI (kód MetaIS = isvs_5836, pôvodne IS CSRÚ).
Predmetom riešenia je spracovanie a publikovanie dát generovaných z lokálnych IoT senzorov, ktoré sú úplne nezávislé od údajov poskytovaných prostredníctvom IS CPDI.
Obec teda nebude spotrebovávať žiadne externé referenčné alebo prevádzkové údaje z centrálnej platformy a všetky potrebné výstupy budú tvoriť interné procesy riešenia a následne publikované ako otvorené údaje.
 

Tabuľka 19  Konzumovanie údajov z IS CPDI – budúci stav (TO BE)

1. 
   
   1. 
      
      1. Identifikácia údajov a subjektov pre konzumovanie alebo poskytovanie údajov do/z CPDI (CSRÚ)

V rámci projektu sa identifikovali objekty evidencie, ktoré môžu byť v budúcnosti predmetom poskytovania alebo konzumovania prostredníctvom IS Centrálna platforma dátovej integrácie (IS CPDI, kód MetaIS=isvs_5836, pôvodné IS CSRÚ).

Hlavným cieľom je zabezpečiť, aby údaje spracovávané v systéme boli dostupné pre ďalšie orgány verejnej správy, a zároveň aby sa eliminovalo opakované požadovanie tých istých údajov od občanov či podnikateľov.

• Poskytované údaje – týkajú sa predovšetkým objektov evidencie vytváraných v rámci IoT Monitoring Modulu (údaje o prostredí, bezpečnostné údaje, štatistické dáta).
• Konzumované údaje – ide najmä o referenčné údaje, ktoré budú využívané pre identifikáciu a správne priradenie dát (napr. základné údaje o obci, fyzických a právnických osobách).
• Subjekty – poskytovateľom údajov je obec / mestský úrad ako prevádzkovateľ budovaného IS, konzumentmi môžu byť iné obce, VÚC, prípadne štátne inštitúcie, ak si to vyžiada budúci rozvoj riešenia.
• Právne predpisy – sprístupňovanie a používanie údajov sa bude riadiť zákonom č. 95/2019 Z. z. o informačných technológiách vo verejnej správe, zákonom č. 305/2013 Z. z. o e-Governmente a príslušnými špecifickými predpismi podľa typu údajov (napr. zákon č. 369/1990 Zb. o obecnom zriadení).

Tabuľka 20  Identifikácia údajov pre konzumovanie alebo poskytovanie údajov do/z CPDI (CSRÚ)

1. 
   
   1. 
      
      1. Kvalita a čistenie údajov

Objekty evidencie spracovávané v rámci projektu (údaje zo senzorov, agregované údaje a open data výstupy) musia byť riadené so zreteľom na ich kvalitu a presnosť. Hlavným rizikom pri dátovej nekvalite je skreslenie rozhodovania samosprávy (napr. nesprávne údaje o vyťaženosti priestorov môžu viesť k chybnému plánovaniu investícií).

Preto bude zavedený systematický manažment údajov:

• Možnosť overenia hodnoty údajov – systém umožní spätné overenie zdrojových dát (surové senzorické údaje budú uchovávané a porovnateľné s agregovanými výstupmi).
• Obmedzenia hodnôt a číselníky – aplikačná vrstva bude obsahovať základné validácie (rozsahy, povolené formáty, poveternostné limity senzorov).
• Migrácia údajov – projekt nepredpokladá migráciu dát z iných ISVS, údaje budú generované výhradne zo senzorov.
• Riadenie kvality – nastavené budú postupy pravidelného čistenia a agregácie dát, aby boli open data publikované v konzistentnom formáte.

Tabuľka 21 Zhodnotenie dátovej kvality objektov evidencie

Tabuľka 22  Personálne zabezpečenie a roly pri riadení dátovej kvality

1. 
   
   1. 
      
      1. Otvorené údaje

Projekt predpokladá sprístupnenie vybraných dát zo senzorov a ich agregovaných výstupov ako otvorených údajov. Publikácia bude realizovaná podľa vyhlášky č. 78/2020 Z. z. o štandardoch pre ITVS a dáta budú registrované v centrálnom katalógu otvorených údajov na data.gov.sk.

• Formáty publikácie: CSV, XML, JSON, pri vyšších úrovniach kvality aj RDF/OWL.
• Úroveň interoperability: minimálne 3*, pre agregované údaje o mobilite a vyťaženosti 4*.
• Periodicita publikovania: podľa charakteru údajov – od týždennej po polročnú.

Tabuľka 23  Objekty evidencie, ktoré budú sprístupnené ako otvorené údaje

1. 
   
   1. 
      
      1. Analytické údaje

Projekt umožní, aby údaje zo senzorov a agregované dáta boli pripravené na analytické spracovanie. To poskytne samospráve podklady pre strategické plánovanie, optimalizáciu dopravnej a priestorovej infraštruktúry a transparentnejšie rozhodovanie.

• Spracovanie bude prebiehať až po pseudonymizácii/anonymizácii, aby nedochádzalo k spracúvaniu osobných alebo citlivých údajov.
• Údaje budú poskytované vo forme agregovaných datasetov (mobilita, vyťaženosť verejných priestorov, environmentálne dáta).
• Účelom je umožniť obci a iným zainteresovaným subjektom (napr. VÚC, akademická obec) analyzovať dáta v dlhodobom horizonte a podporiť tvorbu verejných politík a rozhodovacích procesov.
• Všetky analytické datasety budú v súlade s metodikou MIRRI registrované v Katalógu požiadaviek.

Tabuľka 24  Objekty evidencie, ktoré budú projektom pripravené pre analytické účely

1. 
   
   1. 
      
      1. Moje údaje

Projekt sa zameriava najmä na údaje získané zo senzorov a ich agregáciu. Z pohľadu kategórie „Moje údaje“ je potrebné zohľadniť:

• Údaje sa neviažu na identifikovateľnú fyzickú alebo právnickú osobu (anonymizácia a agregácia prebieha už na úrovni systémov).
• Projekt preto nevytvára nové údaje patriace do kategórie Moje údaje (napr. osobné údaje o osobe, právnickom subjekte, adresy, čísla dokladov).
• Údaje zo senzorov sú spracovávané v anonymnej podobe a nie je možné ich spätne priradiť ku konkrétnej osobe.

 Záver: V rámci tohto projektu nevznikajú Moje údaje, ktoré by bolo potrebné sprístupňovať prostredníctvom IS CPDI alebo služby Moje údaje.

Tabuľka 25 Objekty evidencie, ktoré spadajú do kategórie Mojich údajov

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

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

1. 
   
   1. Technologická architektúra

• 5.6.1 Návrh riešenia technologickej architektúry

Popis súčasného stavu (AS-IS):

• Obec Veľká Lomnica v súčasnosti nemá vybudovanú samostatnú technologickú infraštruktúru pre zber a spracovanie dát zo senzorov.
• Existujú iba základné pracovné stanice a kancelárske nástroje (MS Office, e-mailová komunikácia).
• Neexistuje lokálny server ani dátové úložisko určené pre uchovávanie dát v štruktúrovanej podobe.
• Komunikácia medzi občanmi a obecným úradom prebieha prevažne manuálne alebo prostredníctvom elektronickej úradnej tabule a webovej stránky.
• Z toho dôvodu nie je možné zabezpečiť systematické ukladanie a analytické spracovanie dát v reálnom čase.

Popis budúceho stavu (TO-BE):
Navrhované riešenie bude tvoriť základ technologickej infraštruktúry obce a pozostávať z nasledovných komponentov:

• IoT senzory (pohyb, vozidlá, vyťaženosť priestorov, prípadne environmentálne dáta ako teplota či hluk).
• Komunikačná infraštruktúra: kombinácia bezdrôtových technológií (Wi-Fi, LTE/5G) a káblového pripojenia podľa lokality.
• Lokálny server: fyzicky umiestnený v priestoroch obce, zabezpečený UPS a redundantným úložiskom.
• Databázové a úložiskové riešenie: štruktúrované uchovávanie dát zo senzorov, správa prístupov a zálohovanie.
• Aplikačná vrstva: softvér na spracovanie a vizualizáciu údajov, dashboardy pre vedenie obce a export dát vo formáte Open Data.
• Zálohovanie a bezpečnosť: pravidelné automatické zálohy, antivírusová ochrana, firewall a obmedzený prístup na úrovni rolí.

Architektonické rozhodnutia a požiadavky:

• Riešenie bude postavené na lokálnej infraštruktúre s možnosťou postupného rozšírenia (scalability).
• Server a úložisko budú v správe obce, čím sa zabezpečí kontrola nad dátami a ochrana osobných údajov (GDPR).
• V budúcnosti je možné zvážiť hybridné riešenie s cloudovou architektúrou (pre publikovanie open data alebo vzdialené zálohy).
• Základom bude interoperabilita riešenia s inými systémami cez štandardné dátové formáty (CSV, XML, JSON).

Prístup k architektúre:

• Pri vývoji budú využité open-source riešenia alebo cenovo dostupné licencované produkty.
• Technologická architektúra bude podporovať monitoring prevádzky senzorov aj samotného servera.
• Rozvoj a dopĺňanie ďalších senzorov nebude vyžadovať zásadné zmeny v infraštruktúre (modulárnosť).

1. 
   
   1. 
      
      1. Požiadavky na výkonnostné parametre, kapacitné požiadavky – budúci stav (TO BE)

Tabuľka 27  Požiadavky na výkonnostné parametre, kapacitné požiadavky – budúci stav (TO BE)

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

Projekt nepredpokladá využívanie služieb z katalógu vládneho cloudu. Navrhovaná architektúra je postavená na lokálnom serveri a úložisku v správe obce. Prevádzka je dimenzovaná na pokrytie všetkých požiadaviek riešenia, a preto nie je potrebné využívať externé cloudové prostredie.

1. 
   
   1. Bezpečnostná architektúra

• 
  
  1. 
     
     1. Návrh riešenia bezpečnosti
• AS-IS stav

V súčasnosti obec využíva základnú on-premise infraštruktúru (lokálny server, kancelárske počítače, kancelárske nástroje). Bezpečnostná architektúra je obmedzená najmä na:

• Fyzickú bezpečnosť – uzamykateľná serverová miestnosť, prístup iba povereným zamestnancom,
• Antivírusová ochrana a firewall – bežné komerčné riešenia,
• Zálohovanie dát – realizované manuálne alebo prostredníctvom externého úložiska (napr. USB/HDD),
• Obmedzená politika prístupov – používateľské účty spravované ad hoc, bez centrálneho identity managementu,
• Bezpečnosť prenosu dát – realizovaná cez štandardné VPN pripojenie alebo zabezpečený prístup do IS.

Súčasný stav nezohľadňuje plnohodnotne požiadavky Národného bezpečnostného rámca a strategických priorít MIRRI v oblasti kybernetickej bezpečnosti.

• TO-BE stav

Navrhované riešenie posilňuje bezpečnostnú architektúru s cieľom dosiahnuť vyššiu úroveň dôvernosti, integrity a dostupnosti dát.
Opatrenia a princípy:

1. Riadenie prístupov a identít
   • Zavedenie systému role-based access control (RBAC),
   • Prístup na základe pridelených oprávnení a zodpovedností,
   • Evidencia prístupov a logovanie aktivít.
2. Ochrana dát a komunikácie
   • Šifrovanie dát v pokoji (na úložisku) aj počas prenosu (TLS/SSL, VPN),
   • Bezpečné úložiská pre zálohy (offsite, šifrované),
   • Elektronická evidencia prístupu k údajom v IS.
3. Prevencia a detekcia incidentov
   • Nasadenie firewallu novej generácie a IDS/IPS systémov,
   • Monitorovanie bezpečnostných udalostí, pravidelné testy zraniteľnosti,
   • Incident Response Plan pre riešenie kybernetických incidentov.
4. Organizačné opatrenia
   • Definovanie bezpečnostných politík v súlade so zákonom o kybernetickej bezpečnosti,
   • Určenie bezpečnostného manažéra (zodpovedná osoba v obci alebo externe),
   • Pravidelné školenia zamestnancov v oblasti kybernetickej hygieny.
5. Legislatívne a regulačné požiadavky
   • Dodržanie zákona č. 69/2018 Z.z. o kybernetickej bezpečnosti,
   • Dodržanie zákona č. 18/2018 Z.z. o ochrane osobných údajov (GDPR).

• Rozdielová analýza (GAP)

• AS-IS: základná ochrana (antivírus, firewall, lokálne zálohy).
• TO-BE: zavedenie systematického riadenia bezpečnosti – identity management, šifrovanie dát, prevencia incidentov, bezpečnostné politiky a procesy, zosúladenie s legislatívou.

1. 
   
   1. 
      
      1. Určenie obsahu bezpečnostných opatrení

Projekt musí rešpektovať požiadavky na minimálne bezpečnostné opatrenia podľa vyhlášky ÚPVII č. 179/2020 Z.z., ktoré sa aplikujú na budované ISVS a projektové aktíva. Okrem toho musí byť vypracovaný bezpečnostný projekt v zmysle § 23 ods. 1 a 2 zákona č. 69/2018 Z.z. o kybernetickej bezpečnosti a § 8a vyhlášky č. 401/2023 Z.z.

Tabuľka 28  – Určenie zdrojov a obsahu bezpečnostných opatrení

• Kategória I: zabezpečí základné opatrenia (riadenie prístupov, firewall, antivírus, šifrovanie dát).
• Kategória II: zabezpečí rozšírené opatrenia (logovanie, monitoring, pravidelné testovanie zraniteľností, reakcia na incidenty).
• Kategória III: sa neaplikuje, pretože obec nie je prevádzkovateľom kritickej infraštruktúry.
• Bezpečnostný projekt: bude vypracovaný ako samostatný výstup projektu a bude obsahovať analýzu rizík, návrh bezpečnostných opatrení a implementačný plán.
• Osobitné predpisy: ochrana osobných údajov (GDPR), zákon o archívoch a registratúre, prípadne osobitné rezortné normy.

1. 
   
   1. 
      
      1. Legislatívne, právne, štatutárne, regulačné a zmluvné požiadavky

Navrhované riešenie bezpečnostnej architektúry musí byť v súlade s príslušnými právnymi predpismi, technickými normami a metodikami, ktoré stanovujú úroveň potrebnej bezpečnosti IS.

Projekt sa bude riadiť najmä týmito legislatívnymi rámcami:

• Zákon č. 95/2019 Z.z. o informačných technológiách vo verejnej správe.
• Zákon č. 69/2018 Z.z. o kybernetickej bezpečnosti.
• Vyhláška č. 362/2018 Z.z. – ustanovuje obsah bezpečnostných opatrení a dokumentácie.
• Vyhláška č. 179/2020 Z.z. – ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení ISVS.
• Vyhláška č. 78/2020 Z.z. – o štandardoch pre informačné technológie verejnej správy.
• Nariadenie GDPR – (EÚ) 2016/679 a zákon č. 18/2018 Z.z. – ochrana osobných údajov.
• Zákon č. 45/2011 Z.z. o kritickej infraštruktúre (ak by došlo k rozšíreniu do tejto kategórie).

Okrem toho sa uplatnia interné metodické pokyny, ako aj usmernenia CSIRT.SK (napr. metodika hardeningu systémov).

Výstup: Projekt zabezpečí zosúladenie všetkých opatrení s uvedenými právnymi a regulačnými rámcami.

1. 
   
   1. 
      
      1. Riešenie autentifikácie a prístupov používateľov

Pri autentifikácii používateľov sa uplatní princíp jednotného prihlásenia (Single Sign-On, SSO) a Autentifikačný modul ÚPVS, ak bude vyžadovaný.

• Interní používatelia:
• pracovníci obce a samosprávy,
• pracovníci zodpovední za správu aplikácií,
• administrátori IT infraštruktúry.
• Externí používatelia:

• občania,
• partneri a tretie strany (napr. konzultačné firmy, dodávatelia).

• Prístupové pravidlá:

• Role-based access control (RBAC) – používateľské prístupy budú viazané na pracovné role,
• Audit a logovanie prístupov – všetky prístupy budú evidované,
• Viacfaktorová autentifikácia (MFA) pre prístup k citlivým údajom a pre administrátorov,
• Prístupy budú pravidelne kontrolované a aktualizované.

Výstup: Požiadavky na autentifikáciu a prístupové práva budú zapísané do Katalógu požiadaviek a implementované ako povinný bezpečnostný prvok riešenia.

1. PREVÁDZKA A ÚDRŽBA VÝSTUPOV PROJEKTU

• 
  
  1. Návrh riešenia prevádzky a údržby
• AS-IS stav

V súčasnosti obec využíva základné nástroje pre evidenciu a správu dát (kancelárske aplikácie, jednoduché interné postupy). Prevádzka a údržba informačných systémov je zabezpečovaná ad-hoc spôsobom, bez formálne nastavených procesov SLA a bez centralizovaného dohľadu.
Obnova dát je realizovaná len čiastočne (napr. manuálnymi zálohami). Chýba systematické monitorovanie a prevencia výpadkov.

• TO-BE stav

Navrhované riešenie zabezpečí prevádzku a údržbu v štandardoch eGovernmentu a v súlade s požiadavkami informačnej bezpečnosti:

• Prevádzka systému bude zabezpečená dodávateľom počas záručnej doby a následne prenesená na interného správcu IS obce.
• Údržba systému bude prebiehať pravidelne (aktualizácie SW, bezpečnostné záplaty, optimalizácia výkonu).
• Úroveň poskytovania služieb (SLA):
  • garantovaná dostupnosť systému minimálne 99 %,
  • reakčná doba na nahlásený incident do 4 hodín,
  • doba odstránenia kritickej poruchy do 24 hodín,
  • pravidelné mesačné reporty o prevádzke a incidentoch.
• Obnova systému a dát:
  • pravidelné denné zálohovanie prevádzkových dát,
  • uchovávanie záloh v oddelenom úložisku (on-premise + cloud),
  • testovanie obnovy dát minimálne 2× ročne,
  • plán kontinuity prevádzky (BCP) a plán obnovy po havárii (DRP).
• Podpora a integrácie

• Pre manažment služieb podpory sa bude využívať helpdesk systém (napr. open-source alebo komerčné riešenie), ktorý umožní evidenciu incidentov, požiadaviek a zmien.
• Systém umožní integráciu na iné ISVS prostredníctvom štandardizovaných rozhraní (napr. XML, CSV, REST API).

• Požiadavky na prevádzku a údržbu

• zabezpečenie školenia interného správcu IS,
• nastavenie procesov ITSM (incident management, change management),
• pravidelný monitoring výkonu a bezpečnosti,
• podpora používateľov (helpdesk, hotline, vzdialená asistencia).

Výstup: Riešenie prinesie stabilnú a predvídateľnú úroveň poskytovania služieb, transparentnú správu incidentov a bezpečné uchovávanie a obnovu údajov, čím sa minimalizuje riziko výpadku a straty dát.

.

1. 
   
   1. Zabezpečenie podpory používateľov a prevádzky

Koncepcia podpory

• Podpora používateľov a prevádzky bude zabezpečená v troch úrovniach podpory:

• Podpora L1 (Level 1) – základná úroveň podpory:
  • slúži ako primárny kontaktný bod pre používateľov,
  • rieši jednoduché problémy a poskytuje základné informácie,
  • zabezpečuje evidenciu incidentov a ich kategorizáciu,
  • typické činnosti: reset hesiel, základné nastavenia aplikácií, diagnostika bežných problémov.
• Podpora L2 (Level 2) – rozšírená podpora:
  • rieši požiadavky a incidenty, ktoré presahujú možnosti L1,
  • poskytuje detailnejšiu analýzu a technické riešenia,
  • zabezpečuje spoluprácu s odbornými tímami a prípravu návrhov opráv,
  • typické činnosti: správa aplikačných služieb, konfigurácia IS, testovanie opráv.
• Podpora L3 (Level 3) – expertná úroveň:
  • najvyššia úroveň podpory, ktorú poskytuje dodávateľ systému,
  • rieši najzložitejšie problémy vrátane analýzy zdrojového kódu alebo architektúry systému,
  • zabezpečuje dlhodobú optimalizáciu a plánovanie zmien.

• SLA a dostupnosť podpory

Podpora bude zabezpečená podľa nasledovných pravidiel:

• L1 – základná podpora: dostupnosť počas pracovných dní od 8:00 do 16:00, garantovaná reakčná doba 4 hodiny.
• L2 – technická podpora: dostupnosť počas pracovných dní od 8:00 do 18:00, reakčná doba 2 hodiny.
• L3 – expertná podpora: dostupnosť 24/7 pre kritické incidenty, reakčná doba 1 hodina.

Tabuľka 29 – Prehľad riešenia podpory používateľov a prevádzky

1. 
   
   1. Riešenie incidentov v prevádzke - parametre úrovní služby

Incident je akákoľvek hlásená alebo zistená relevantná skutočnosť týkajúca sa aktíva (informačného systému) alebo jeho časti, ktorej nedostupnosť alebo nefunkčnosť má vplyv na poskytovanie služieb.
Cieľom riešenia incidentov je zabezpečiť rýchlu reakciu a obnovu funkčnosti systému tak, aby bol dopad na používateľov a poskytovanie služieb čo najnižší.

Klasifikácia incidentov sa riadi kombináciou naliehavosti a dopadu, pričom každý incident je zaradený do kategórie priority.

Tabuľka 30  Klasifikácia Naliehavosti incidentu

Tabuľka 31  Klasifikácia Závažnosti incidentu

Určenie priority incidentu je kombináciou dopadu a naliehavosti podľa nasledovnej matice:

Tabuľka 32 Určenie priority incidentu

Parametre služby Riešenia incidentov v prevádzke:

Tabuľka 33  Parametre služby Riešenia incidentov v prevádzke

1. 
   
   1. Požadovaná dostupnosť informačného systému:

Dostupnosť informačného systému je jedným z kľúčových parametrov kvality poskytovaných služieb.

Navrhovaný budúci stav (TO BE) stanovuje nasledovné požiadavky na časovú dostupnosť, servisné okná, parametre obnovy a celkové SLA:

• Prevádzkové hodiny
• 12 hodín denne, v pracovných dňoch od 06:00 do 18:00.
• Podporné procesy (helpdesk, správa infraštruktúry) budú dostupné počas pracovných dní.
• Servisné okno
• 24 hodín denne, mimo pracovnej doby (00:00 – 23:59 hod. počas dní pracovného pokoja a štátnych sviatkov).
• Servis a údržba budú realizované tak, aby nedošlo k obmedzeniu prevádzky počas definovaných prevádzkových hodín.
• Dostupnosť produkčného prostredia IS
• Požadovaná úroveň: 98,5 % dostupnosť počas roka.
• Maximálny mesačný čas výpadku je 66 hodín.
• Nedostupnosť počas servisného okna sa nezapočítava do SLA.
• V prípade nedodržania dostupnosti IS bude začatý ďalší pracovný deň ako nepretržitý incident až do úplného odstránenia problému.
• RTO a RPO
• RTO (Recovery Time Objective): 4 hodiny – maximálny čas na obnovenie systému po výpadku.
• RPO (Recovery Point Objective): 6 hodín – maximálna prípustná strata dát po výpadku.

Tabuľka 34  – Požadovaná dostupnosť informačného systému

1. 
   
   1. Požiadavky na ľudské zdroje potrebné pre zabezpečenie prevádzky

Prevádzka budovaného systému si vyžaduje nasadenie kvalifikovaných ľudských zdrojov, ktoré budú pokrývať všetky oblasti jeho správy a podpory. Požiadavky sú:

Prevádzkový administrátor systému – zodpovedný za technickú správu IS, monitoring, konfiguráciu a riadenie prevádzky.

Špecialista používateľskej podpory (helpdesk, L1) – prvý kontaktný bod pre používateľov, evidencia incidentov, základné riešenia problémov a eskalácia.

Špecialista druhej úrovne podpory (L2) – riešenie zložitejších incidentov, analýza problémov, spolupráca s dodávateľom IS.

Bezpečnostný špecialista – dohľad nad dodržiavaním bezpečnostných opatrení, kontrola prístupov a reakcia na bezpečnostné incidenty.

Dátový kurátor – dohľad nad kvalitou údajov a správnosťou dátových štruktúr, zodpovednosť za evidenciu údajov.

Ďalšie požiadavky:

pravidelné školenia a certifikácie pre administrátorov a používateľov,

zabezpečenie dostupnosti podpory v rozsahu SLA,

dokumentovaný plán pre zálohovanie a obnovu činností v prípade výpadku personálnych kapacít.

1. 
   
   1. Požiadavky na zdrojové kódy

Projekt musí zabezpečiť, aby zdrojové kódy budovaných aplikácií a častí riešenia boli dodané v súlade s legislatívou:

• v zmysle § 15 ods. 6 zákona č. 95/2019 Z. z. o informačných technológiách verejnej správy,
• podľa Metodického usmernenia č. 024077/2023 o kvalite zdrojových kódov a balíkov softvéru.
• Požiadavky na zdrojové kódy:

• Dodanie úplných a otestovaných zdrojových kódov vrátane dokumentácie.
• Zdrojové kódy musia byť odovzdané v otvorenej štruktúre (napr. repozitár Git, SVN).
• Súčasťou odovzdania musia byť aj inštalačné skripty, konfigurácie a testovacie scenáre.
• Forma a štruktúra archívu musí byť kompatibilná so štandardmi MIRRI SR.
• Zdrojové kódy sa musia odovzdávať priebežne, podľa fakturačných míľnikov projektu.

• Licencovanie:

• Preferované je použitie EUPL licencie, resp. iných open-source licencií kompatibilných s verejnou správou.
• V prípade použitia tretích strán alebo knižníc musí byť zabezpečená plná licenčná kompatibilita.

• Prenos a archivácia:

• Dodávateľ je povinný preniesť kompletné zdrojové kódy do centrálneho repozitára ITVS (Národný projekt Manažment zdrojových kódov a ITVS).
• Odovzdané zdrojové kódy musia byť archivované tak, aby bola zaručená ich dlhodobá dostupnosť a použiteľnosť.
• Všetky zdrojové kódy budú zahrnuté aj v SLA.

1. OPIS IMPLEMENTÁCIE PROJEKTU A PREBERANIA VÝSTUPOV PROJEKTU

Projekt bude implementovaný postupne v jednotlivých etapách podľa schváleného harmonogramu. Zvolený prístup je iteratívny (Agile) s prvkami Waterfall tam, kde je to vhodné (napr. právne a procesné rámce, bezpečnostné opatrenia).

• Postup implementácie:
• Etapa 1 – Analýza a návrh riešenia
  • zber požiadaviek, analýza súčasného stavu (AS-IS), návrh cieľového stavu (TO-BE), príprava architektonickej dokumentácie, špecifikácia aplikačných služieb a dátových štruktúr.
• Etapa 2 – Vývoj a konfigurácia systému
  • implementácia informačného systému, vývoj aplikačných komponentov, nastavenie infraštruktúry, realizácia bezpečnostných opatrení.
• Etapa 3 – Testovanie a pilotná prevádzka
  • funkčné a integračné testy, bezpečnostné testy, pilotné nasadenie u vybraných používateľov, zber spätnej väzby.
• Etapa 4 – Produkčné nasadenie a školenie používateľov
  • nasadenie do plnej prevádzky, školenia používateľov a správcov, nastavenie procesov prevádzky a podpory (SLA).
• Etapa 5 – Odovzdanie výstupov a uzatvorenie projektu
  • dodanie všetkých projektových produktov, zdrojových kódov a dokumentácie, vypracovanie záverečnej správy a ukončenie projektu.

• Preberanie výstupov:

Preberanie výstupov projektu sa bude realizovať formou akceptačných protokolov, v ktorých budú presne špecifikované:

• projektové výstupy podľa vyhlášky MIRRI č. 401/2023 Z. z. (vrátane zdrojových kódov a dokumentácie),
• koncové služby a procesy pripravené pre občanov a samosprávu,
• technologické a aplikačné komponenty riešenia,
• aktualizovaná projektová dokumentácia.

Za akceptáciu zodpovedá Obec Veľká Lomnica ako prijímateľ, pričom akceptácia bude prebiehať na základe testovacích scenárov, protokolov o skúškach a overení funkčnosti.

• Preberanie výstupov:

Preberanie výstupov projektu sa bude realizovať formou akceptačných protokolov, v ktorých budú presne špecifikované:

• projektové výstupy podľa vyhlášky MIRRI č. 401/2023 Z. z. (vrátane zdrojových kódov a dokumentácie),
• koncové služby a procesy pripravené pre občanov a samosprávu,
• technologické a aplikačné komponenty riešenia,
• aktualizovaná projektová dokumentácia.

Za akceptáciu zodpovedá Obec Veľká Lomnica ako prijímateľ, pričom akceptácia bude prebiehať na základe testovacích scenárov, protokolov o skúškach a overení funkčnosti.

7.ROZPOČET A PRÍNOSY

Po

1. 
   
   1. Detailný opis rozpočtu projektu a jeho prínosov

Nákladová stránka projektu

Celkový rozpočet projektu pozostáva z investičných a prevádzkových nákladov:

1. Investičné náklady (rok 0–1):
   • hardvér, softvér, inštalácia a konfigurácia: 329 111,43 € s DPH
   • paušálne výdavky (verejné obstarávanie, externý projektový manažment, projektová dokumentácia – 7 %): 23 037,80 €
   • Spolu oprávnené výdavky: cca 352 149,23 €
2. Spolufinancovanie:
   • 92 % (EÚ + ŠR), t. j. cca 323 977,29 €
   • 8 % (obec), t. j. cca 28 171,94 €
3. Prevádzkové náklady (rok 2–10):
   • základná SLA na úrovni 3 000 – 5 000 €/rok, ktorá pokrýva aktualizácie softvéru, monitoring a servis,
   • bežná správa systému bude zabezpečená interným zamestnancom obce (už dnes vykonáva správu webu a elektronickej úradnej tabule),
   • väčšie zásahy budú riešené formou individuálnych zákaziek.

➡ Predpokladané prevádzkové náklady v T10: cca 30 000 – 50 000 €.

Prínosy projektu (T10)

1. Kvantifikovateľné prínosy:
   • úspora pracovných kapacít (administratíva, monitoring): cca 12 000 €/rok (zodpovedá jednému pracovného úväzku),
   • efektívnejšie plánovanie údržby cintorína, cyklotrás, verejného osvetlenia a infraštruktúry: 5 000 – 10 000 €/rok,
   • optimalizácia investícií – dátové podklady umožnia nasmerovať zdroje tam, kde sú reálne potreby (odhad úspory 5 % kapitálových výdavkov obce).
2. Nekvantifikovateľné prínosy:
   • zvýšenie bezpečnosti detí pri školách a pohybu obyvateľov v rizikových lokalitách,
   • zlepšenie komfortu obyvateľov a návštevníkov,
   • transparentnosť vďaka open data (zverejňovanie agregovaných údajov na webe a e-tabuľi),
   • participácia verejnosti a podpora digitálnej transformácie,
   • možnosť budúceho rozšírenia o environmentálne senzory, smart osvetlenie či parkovací manažment.

Ukazovatele návratnosti

• Náklady T10: cca 382 000 – 402 000 € (investícia + low-cost prevádzka).
• Prínosy T10 (kvantifikovateľné): cca 170 000 – 220 000 €, bez započítania kvalitatívnych prínosov a optimalizácie investícií.
• Rok návratnosti: predbežne 7.–8. rok.
• Ukazovatele ENPV, FNPV, BCR: budú presne vypočítané až po určení dodávateľa, avšak predbežné hodnotenie ukazuje pozitívny trend (BCR > 1).

Zhrnutie

Projekt má realisticky nastavené investičné a prevádzkové náklady. Vďaka kombinácii externej SLA v nízkom rozsahu a internej správy systému sú prevádzkové náklady udržateľné aj pre obec Veľká Lomnica. Prínosy projektu sa prejavia nielen v úsporách a efektívnejšom riadení obecného majetku, ale aj v zvýšení bezpečnosti, transparentnosti a kvalite života obyvateľov.

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

Predkladaný projekt je v hodnote  do 1 000 000,- EUR,  CBA sa na základe usmernenia nevypracováva.

Sumy sú uvedené s DPH

Tabuľka 6 Sumarizácia nákladov a prínosov

Prevádzkové náklady boli odhadnuté konzervatívne vo výške 3 000 – 5 000 € ročne. Presná suma bude známa až po ukončení procesu verejného obstarávania a bude závisieť od dodávateľa riešenia.

Projekt je ekonomicky efektívny, keďže v horizonte 10 rokov (T10) prínosy prevyšujú náklady. Odhadovaný pomer prínosov a nákladov (BCR) je vyšší ako 1,00 a očakáva sa kladná ekonomická čistá súčasná hodnota (ENPV). Prevádzkové náklady na úrovni 3 000 – 5 000 €/rok sú pre obec udržateľné.

Okrem kvantifikovateľných úspor (administratíva, efektívnejšie plánovanie údržby, optimalizácia investícií) projekt prináša aj významné spoločenské prínosy: kvalitnejšie rozhodovacie podklady pre samosprávu, lepšiu organizáciu dopravy a verejných služieb, transparentné zverejňovanie údajov a podporu participácie obyvateľov.

Projekt je nastavený tak, aby sa stal základom pre ďalšie digitálne riešenia obce a z dlhodobého hľadiska podporil jej rozvojovú stratégiu.

1. 
   
   1. 
      
      1. Zdroj financovania

Projekt bude financovaný prostredníctvom výzvy s kódom : PSK-MIRRI-619-2024-ITI-EFRR
Obec patrí medzi menej rozvinuté regióny a preto finanocvanie bude nasledovné:
Zdroj EÚ - 85 %

Štátny rozpočet - 7 %

Prijímateľ (obec Veľká Lomnica ) - 8 %

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

Na realizáciu projektu bude použitá metodika waterfall, nakoľko projekt neobsahuje fázu vývoja softvéru a jeho realizácia prebieha sekvenčne. Implementácia riešenia prebehne ako celok, bez potreby priebežného nasadzovania po funkčných celkoch.

Na realizáciu projektu bude použitá metodika waterfall, nakoľko projekt neobsahuje fázu vývoja softvéru a jeho realizácia prebieha sekvenčne. Implementácia riešenia prebehne ako celok, bez potreby priebežného nasadzovania po funkčných celkoch.

9.PROJEKTOVÝ TÍM

Zos

Tabuľka 8 Projektový tím

• Riadiaci výbor projektu – Veľká Lomnica

1. Predseda Riadiaceho výboru (RV)

• Zodpovedná osoba: Ing. Andrea Kromková, prednostka
• Zodpovednosti:
  • Zvoláva a vedie zasadnutia RV.
  • Schvaľuje hlavné rozhodnutia projektu a dohliada na súlad s cieľmi obce.
  • Reprezentuje projekt voči zriaďovateľovi a riadiacim orgánom.

2. Biznis vlastník

• Zodpovedná osoba: Mgr. Peter Duda, starosta obce
• Zodpovednosti:
  • Zodpovedá za naplnenie cieľov projektu z pohľadu samosprávy.
  • Dohliada na súlad projektu s rozvojovými prioritami obce.
  • Koordinuje interné procesy obce súvisiace s implementáciou výstupov.

3. Zástupca prevádzky

• Zodpovedná osoba: Ing. Andrea Kromková, prednostka
• Zodpovednosti:
  • Zabezpečuje správu a údržbu systému po jeho nasadení.
  • Komunikuje s dodávateľom počas záručného obdobia a SLA podpory.
  • Zodpovedá za technické a personálne podmienky pre dlhodobú prevádzku.

4. Projektový manažér realizátora projektu

• Zodpovedná osoba: Ing. Miriam Kulíková, externý projektový manažér
• Zodpovednosti:
  • Riadi projekt podľa schváleného harmonogramu.
  • Zabezpečuje komunikáciu medzi obcou a dodávateľom.
  • Koordinuje činnosti verejného obstarávania, implementácie a testovania.
  • Vedenie projektovej dokumentácie a reporting.

5. Kľúčový používateľ

• Zodpovedná osoba: Mgr. Peter Duda, starosta obce
• Zodpovednosti:
  • Reprezentuje používateľské potreby obce počas celého projektu.
  • Poskytuje spätnú väzbu k funkcionalite riešenia a testovacím scenárom.
  • Overuje výstupy z pohľadu praktického využitia.

6. Špecialista na IoT riešenia (HW a SW dodávateľ)

• Zodpovedná osoba: TBD (vybraný dodávateľ na základe VO)
• Zodpovednosti:
  • Spolupracuje na návrhu technického riešenia a dodávke komponentov.
  • Realizuje inštaláciu, konfiguráciu a testovanie systému.
  • Poskytuje úvodné zaškolenie obsluhy a technickú podporu počas nasadenia.

10.ODKAZY

Pri príprave tohto dokumentu boli využité nasledovné materiály a zdroje:

• Národná koncepcia informatizácie verejnej správy (NKIVS),
• Strategická priorita Manažment údajov a Otvorené údaje,
• Vyhláška ÚPVII č. 179/2020 Z. z. o štandardoch pre informačné technológie verejnej správy,
• Vyhláška MIRRI č. 401/2023 Z. z. o riadení projektov a zmene požiadaviek v prevádzke,
• Metodické usmernenia MIRRI k riadeniu kvality údajov, zdrojových kódov a bezpečnostných opatrení,
• Používateľská príručka systému MetaIS,
• Metodika optimalizácie procesov vo verejnej správe (MV SR),
• Katalóg služieb vládneho cloudu,
• CSIRT metodiky pre hardening a kybernetickú bezpečnosť.

1. PRÍLOHY

Príloha 1: Zoznam rizík a závislostí (Excel): https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html