Navrhujeme doplniť legendu ku všetkým diagramom pre zlepšenie čitateľnosti a orientácie používateľa. V prípadoch, kde sa používajú farebné odlíšenia (napr. existujúce vs. nové komponenty), je nevyhnutné, aby tieto boli konzistentne uplatnené v celom dokumente.
Zároveň upozorňujeme, že ak diagram zobrazuje komponenty, ktoré nie sú predmetom tohto konkrétneho projektu, nemali by byť vizuálne znázornené rovnakou farbou ako komponenty, ktoré projekt skutočne pokrýva. Formulácia typu „nie všetky červenou označené komponenty sú súčasťou tohto projektu“ je mätúca a znižuje vypovedaciu hodnotu schémy.
Odporúčame:
doplniť grafickú legendu ku každému diagramu,
jednoznačne odlíšiť komponenty, ktoré sú súčasťou projektu, od tých, ktoré nie sú (napr. iným odtieňom alebo typom orámovania),
zabezpečiť jednotnú logiku označovania vo všetkých vizualizáciách.
Diagram je nejasný a ťažko čitateľný. Na základe prvej časti (časť Návody) predpokladám, že ide o znázornenie procesného toku v prostredí UPVS – konkrétne pre publikovanie, vyhľadávanie a konzumáciu obsahu.
Nie je však zrejmé, akú notáciu diagram používa – pravdepodobne ide o kombináciu BPMN prvkov s vlastnou (neformálnou) architektonickou vizualizáciou. Takéto zobrazenie si vyžaduje podporné prvky, ktoré momentálne absentujú.
Medzi hlavné problémy diagramu patrí:
Absencia legendy – nie je vysvetlené, čo znamenajú použité farby. Farebné označenie nie je intuitívne a jeho význam nie je možné jednoznačne určiť.
Zmiešané úrovne abstrakcie – diagram obsahuje komponenty, aplikačné moduly, rozhodovacie body aj používateľské rozhrania bez jasného vizuálneho odlíšenia. Výsledkom je vizuálny chaos a znížená čitateľnosť.
Nejednoznačné zobrazenie červených komponentov – nie je jasné, ktoré z nich sú predmetom projektu a ktoré nie. Rovnako sťažuje orientáciu formulácia v sprievodnom texte: „nie všetky červenou označené komponenty sú súčasťou tohto projektu“ – čo je v priamom rozpore s očakávaním, že farebné odlíšenie bude reflektovať rozsah projektu.
Kapitola 3.1 Manažérske zhrnutie by mala byť stručným, jasným a štruktúrovaným vysvetlením základného rámca projektu – jeho účelu, predmetu, cieľovej skupiny, výšky rozpočtu a prínosov. V zmysle šablóny výstupu I-02 (Vyhláška č. 401/2023 Z. z.) sa od tejto kapitoly očakáva najmä zrozumiteľné zhrnutie odpovedajúce na otázky: Prečo sa projekt realizuje? Čo konkrétne rieši? Pre koho je určený? Koľko bude stáť a aký bude jeho prínos?
Z uvedených dôvodov odporúčam diagram zo súčasnej verzie kapitoly 3.1 odstrániť a presunúť do relevantnej technickej časti dokumentu (napr. kapitola 5 – Architektúra, alebo príloha). Aktuálna vizuálna forma diagramu je ťažko čitateľná a bez doplnenia legendy neposkytuje jednoznačnú výpovednú hodnotu. Zároveň svojim technickým detailom a rozsahom nepatrí do úvodného manažérskeho zhrnutia.
Text v kapitole 3.1 sa venuje prevažne projektom realizovaným v predošlom programovom období (OPII PO7), ako sú Modernizácia UPVS, MÚKC alebo KSDR. Tento obsah však nezodpovedá účelu kapitoly manažérskeho zhrnutia podľa šablóny dokumentácie definovanej vo vyhláške č. 401/2023 Z. z.
Od kapitoly manažérskeho zhrnutia sa očakáva, že stručne, jasne a štruktúrovane vysvetlí:
dôvod realizácie aktuálneho projektu (SVK3 – NASES),
jeho predmet (napr. modernizácia platformy, vývoj SW, migrácia do cloudu),
cieľovú skupinu (napr. občania, podnikatelia, OVM),
indikatívne náklady a zdroj financovania,
a očakávaný prínos v časovom rámci projektu (napr. do 30. 6. 2026 v rámci POO SR).
Zároveň upozorňujem, že opisy minulých projektov bez objektívne doloženého vyhodnotenia ich prínosov moze priniest sadu novych otazok ako - Aka hardwareová infrastruktura bola obnovená? "V rámci projektu bola dodaná a obnovená hardvérová infraštruktúra vrátane potrebných SW licencií.", su projekty ako CAMP uz produkcne pouzivane a prinasaju prinos tak ako sa hodnoti v tomto manazerskom zhrnuti?
Nie je dôvod domnievať sa, že navrhované opatrenia – ako je technologická obnova systémov slovensko.sk, automatizácia spracovania životných situácií či zavedenie modulov ako COP (centrálna orchestračná platforma) – neprispievajú k efektívnejšiemu vynakladaniu verejných finančných prostriedkov.
Zavedenie modulu COP umožňuje flexibilnú konfiguráciu procesov bez potreby zásahov externých dodávateľov, čím výrazne prispieva k eliminácii vendor lock-in, skracuje čas na implementáciu zmien a znižuje pracnosť správy služieb v čase. Tieto vlastnosti priamo podporujú ciele hospodárnosti, efektívnosti a účelnosti v zmysle zákona o rozpočtových pravidlách verejnej správy.
Ak sa tieto systémové a prevádzkové výhody očakávajú od nových komponentov (najmä COP), prečo nie sú uvedené v časti „Motivácia projektu“ alebo „Rozsah projektu“ ako deklarovaný prínos? Plánuje sa skutočne tento modul použiť na podporu flexibilného a opakovane využiteľného modelu správy životných situácií, alebo ide len o technickú integráciu bez zmeny v prístupe k riadeniu služieb?
V rámci princípov navrhovaných pre novú platformu (SVK3 – NASES) chýbajú viaceré zásadné architektonické a prevádzkové princípy, ktoré sú explicitne uvedené v Národnej koncepcii informatizácie verejnej správy 2021 (NKIVS 2021) a mali by byť záväzné pre všetky projekty verejnej správy.
Sluzba ako platforma, zdielane centralne bloky, efektivnost a uspornost, odlucenie od vendor lock-in, multikanalovy pristup, asistovane sluzby, modularita a dekompozicia, jednotny dizajn, open source preferencia,
Viete argumentovat, ze dekompozicia je vlastne popisana ako preferencia pre REST integracie ale tuto vazbu tam treba uviest aby bolo jasne ci toto je jediny nastroj ako idete splnit poziadavku na dekompoziciu tak aby sa naplnala NKIVS
Prosím o extrakciu a uplatnenie všetkých relevantných architektonických princípov platných v štáte, najmä z dokumentu NKIVS 2021.
Tato cast opat zachadza prilis zbytocne hlboko do historickeho kontextu a projektov ktore sa realizovali v minulosti namiesto toho aby jasne popisala motivaciu pre tento projekt. Predpokladam, ze v projekte nejde len o optimalizaciu a vymenu backendovych sluzieb. Tato cast musi popisat aky problem chcete projektom odstranit, to co projekt chce spravit by malo byt uz navnimane z manazerskeho zhrnutia.
Text v tejto časti neplní účel kapitoly v zmysle šablóny podľa vyhlášky č. 401/2023 Z. z. Namiesto vecného zhrnutia problému, identifikácie dotknutých biznis procesov a rámcového rozsahu projektu obsahuje len podrobný popis architektúry, historického vývoja a technických modulov, ktoré nie sú relevantné pre túto časť dokumentu.
Upozorňujeme, že ide prevažne o popis modulov IS a technickej infraštruktúry, nie o opis biznis procesov, ktoré majú byť predmetom projektu. Text preto uniká pôvodne definovanému účelu tejto kapitoly.
Odporúčanie:
Doplniť jasné a stručné formulovanie problému, ktorý projekt rieši (napr. nízka využiteľnosť služieb, zlá orientácia používateľov, nemožnosť centrálne riadiť životné situácie).
Identifikovať konkrétne biznis procesy, ktorých sa projekt týka (napr. publikovanie služieb, elektronické podanie, správa údajov používateľa, spätná väzba).
Doplniť informáciu o agende / životných situáciách, ktorým sa projekt venuje.
Doplniť rozsah projektu – t. j. ktorých subjektov a ISVS sa projekt týka.
Zarámcovať motiváciu na dosiahnutie budúceho stavu a definovať hlavné obmedzenia (časové, technologické, prevádzkové, personálne).
Prípadne vizualizáciu ponechať, ale doplniť o zrozumiteľný sprievodný text podľa vyššie uvedených bodov – inak odporúčame diagram presunúť do kapitoly 4.1 alebo prílohy.
Formulácia „platforma by mala fungovať aj v mobilnej verzii“ vyznieva nepresvedčivo a znižuje dôveryhodnosť záväzku projektu voči deklarovaným cieľom.
Otázka znie: Je mobilná verzia platformy povinnou súčasťou riešenia, alebo len želaným vedľajším efektom? Ak je cieľom projektu výrazne zvýšiť využiteľnosť elektronických služieb občanmi, potom mobilná prístupnosť a responzívne používateľské rozhranie by nemali byť formulované hypoteticky („by mala“), ale ako jednoznačný zámer a požiadavka na výsledný stav riešenia.
Odporúčanie:
Preformulovať text do záväznej formy, napr. „Platforma bude dostupná aj v mobilnej verzii / vo forme responzívneho používateľského rozhrania / mobilnej aplikácie“.
V prípade, že mobilná verzia nie je zahrnutá v rozsahu projektu, je potrebné to jednoznačne uviesť – inak môže dôjsť k zavádzaniu hodnotiteľov a prijímateľa ohľadom rozsahu dodávky.
Aplikovatelne pre celu kapitolu - prilis a zbytocne dlhe pasaze opisujuce POO, vyzvy, program a koncepcie. Toto su vychodiska, nie samotne ciele projektu na ktore by sa tento dokument mal zameriavat
Ako sa vypocital tento narast a preco v prvom roku dodania do produkcie planuje KPI iba s hodnotou 10.000 ked predpokladam, ze bude v tento moment najvacsia propagacia dodaneho projektu.
Podľa dokumentácie bolo zo strany MIRRI pre účely investičného plánu prioritných životných situácií – za účelom mitigácie rizika nesplnenia cieľa C175 v termíne do Q2/2026 – vybraných 17 životných situácií. Zároveň sa uvádza, že v rámci POO SR bude reálne implementovaných len 16.
Zároveň však KPI tabuľka predpokladá postupný nárast počtu inštitúcií integrovaných na spoločnú zbernicu udalostí až do roku 2029, čo vyvoláva otázky ohľadom úplnosti riešení, ktoré budú dodané v rámci tohto projektu.
Otázky na objasnenie:
Ak projekt deklaruje dodanie 16 životných situácií, ktorých cieľom je zjednodušenie a vizualizácia procesov pre občana, ako je možné, že nie všetky zúčastnené inštitúcie budú po dodaní projektu poskytovať údaje o stave svojich procesov?
Znamená tento posun v čase (až do roku 2029), že nie všetky deklarované životné situácie budú po ukončení projektu v Q2/2026 funkčné v plnom rozsahu a s plným prínosom pre používateľa?
Tento postupný nárast signalizuje, že platforma nebude po dodaní v plnej miere spôsobilá poskytovať používateľovi ucelený pohľad na riešenie jeho životnej situácie, čo je kľúčový deklarovaný cieľ projektu. Odporúčame preto objasniť:
ktoré životné situácie budú implementované v plnej miere v rámci projektu (do Q2/2026),
a ktoré budú dokončené, resp. rozšírené až v neskoršej fáze mimo rámca tohto projektu.
Nastavenie KPI „počet krokov v orchestrácii“ s cieľovou hodnotou 10 pôsobí nelogicky a je v rozpore s princípmi procesnej optimalizácie. Ak je cieľom projektu zjednodušiť a zracionalizovať riešenie životných situácií, potom nemá dávať zmysel kvantifikovať úspešnosť podľa toho, koľko krokov orchestrácia obsahuje.
Takto definovaný ukazovateľ môže mať neželaný vedľajší efekt – motivovať k umelému zvyšovaniu počtu krokov aj tam, kde by ich bolo možné procesne zlúčiť alebo eliminovať, čo ide proti cieľu znižovania zložitosti a zvyšovania používateľskej jednoduchosť.
Toto KPI v podobe „3 % podiel využitia“ je matematicky aj metodicky slabé a nevystihuje reálne využívanie ani prínos jednotlivých životných situácií. Odporúčam ho preformulovať alebo nahradiť KPI s jasne merateľným výsledkom (napr. počet úspešných podaní, počet interakcií, spokojnosť).
Toto KPI v podobe „3 % podiel využitia“ je matematicky aj metodicky slabé a nevystihuje reálne využívanie ani prínos jednotlivých životných situácií. Odporúčame ho preformulovať alebo nahradiť KPI s jasne merateľným výsledkom (napr. počet úspešných podaní, počet interakcií, spokojnosť).
Podla KPI pocet zmodernizoanych formularov ich ma byt 100 bez postupneho narastu, predpokladal som, ze definicia alebo kriteria modernizacia obsahuju aj predvyplnanie formularov. Tieto KPI tomu ale nenaznacuju takze opat ziadam o ich kriteria, co sa rozumie pod pojmom modernizacie. Preco v pripade, ze mame modernizaciu 100 formularov nebude projekt ihned aj predvyplnat udaje pre 100 formularov? Existuju nejake technicke obmedzenia alebo ine navaznosti na projekty ked sa pocita s narastom kedze tu ide o implemetnaciu v ramci projekt?
Co je myslene pod pojmom sandbox? Testovacie prostredie a sandboxnie sú to isté, hoci sa tieto pojmy často (nesprávne) zamieňajú. Rozdiel medzi nimi je dôležitý najmä v projektoch eGovernmentu, kde ide o úroveň prístupu, cieľovú skupinu a účel prostredia. Aky bude ucel prostredia, komu bude pristupne, pre koho je primarne urcene, ake data bude obsahovat, zrkadli produkcne prostredie etc..
Text je extrémne technokratický a dodávateľský, nie je zameraný na potreby a skúsenosť koncového používateľa.
Chýba prepojenie na používateľský kontext, persony, scenáre, ciele.
Nie je štruktúrovaný do formy „požiadavka = funkcionalita + odôvodnenie + priorita + zdroj“, ako sa očakáva v I-04 Katalógu požiadaviek.
Existuje referencia na prilohu katalog poziadaviek, toto by malo postacovat a nemusi sa duplikovat informacia aj v dokumente, dokument ma obsahovat prepojenie na koncoveho pouzivatela a user journey
Text je extrémne technokratický a dodávateľský, nie je zameraný na potreby a skúsenosť koncového používateľa.
Chýba prepojenie na používateľský kontext, persony, scenáre, ciele.
Nie je štruktúrovaný do formy „požiadavka = funkcionalita + odôvodnenie + priorita + zdroj“, ako sa očakáva v I-04 Katalógu požiadaviek.
Existuje referencia na prilohu katalog poziadaviek, toto by malo postacovat a nemusi sa duplikovat informacia aj v dokumente, dokument ma obsahovat prepojenie na koncoveho pouzivatela a user journey
Text je extrémne technokratický a dodávateľský, nie je zameraný na potreby a skúsenosť koncového používateľa.
Chýba prepojenie na používateľský kontext, persony, scenáre, ciele.
Nie je štruktúrovaný do formy „požiadavka = funkcionalita + odôvodnenie + priorita + zdroj“, ako sa očakáva v I-04 Katalógu požiadaviek.
Existuje referencia na prilohu katalog poziadaviek, toto by malo postacovat a nemusi sa duplikovat informacia aj v dokumente, dokument ma obsahovat prepojenie na koncoveho pouzivatela a user journey
Text je extrémne technokratický a dodávateľský, nie je zameraný na potreby a skúsenosť koncového používateľa.
Chýba prepojenie na používateľský kontext, persony, scenáre, ciele.
Nie je štruktúrovaný do formy „požiadavka = funkcionalita + odôvodnenie + priorita + zdroj“, ako sa očakáva v I-04 Katalógu požiadaviek.
Existuje referencia na prilohu katalog poziadaviek, toto by malo postacovat a nemusi sa duplikovat informacia aj v dokumente, dokument ma obsahovat prepojenie na koncoveho pouzivatela a user journey
Text je extrémne technokratický a dodávateľský, nie je zameraný na potreby a skúsenosť koncového používateľa.
Chýba prepojenie na používateľský kontext, persony, scenáre, ciele.
Nie je štruktúrovaný do formy „požiadavka = funkcionalita + odôvodnenie + priorita + zdroj“, ako sa očakáva v I-04 Katalógu požiadaviek.
Existuje referencia na prilohu katalog poziadaviek, toto by malo postacovat a nemusi sa duplikovat informacia aj v dokumente, dokument ma obsahovat prepojenie na koncoveho pouzivatela a user journey
Text je extrémne technokratický a dodávateľský, nie je zameraný na potreby a skúsenosť koncového používateľa.
Chýba prepojenie na používateľský kontext, persony, scenáre, ciele.
Nie je štruktúrovaný do formy „požiadavka = funkcionalita + odôvodnenie + priorita + zdroj“, ako sa očakáva v I-04 Katalógu požiadaviek.
Existuje referencia na prilohu katalog poziadaviek, toto by malo postacovat a nemusi sa duplikovat informacia aj v dokumente, dokument ma obsahovat prepojenie na koncoveho pouzivatela a user journey
Text je extrémne technokratický a dodávateľský, nie je zameraný na potreby a skúsenosť koncového používateľa.
Chýba prepojenie na používateľský kontext, persony, scenáre, ciele.
Nie je štruktúrovaný do formy „požiadavka = funkcionalita + odôvodnenie + priorita + zdroj“, ako sa očakáva v I-04 Katalógu požiadaviek.
Existuje referencia na prilohu katalog poziadaviek, toto by malo postacovat a nemusi sa duplikovat informacia aj v dokumente, dokument ma obsahovat prepojenie na koncoveho pouzivatela a user journey
Text je extrémne technokratický a dodávateľský, nie je zameraný na potreby a skúsenosť koncového používateľa.
Chýba prepojenie na používateľský kontext, persony, scenáre, ciele.
Nie je štruktúrovaný do formy „požiadavka = funkcionalita + odôvodnenie + priorita + zdroj“, ako sa očakáva v I-04 Katalógu požiadaviek.
Existuje referencia na prilohu katalog poziadaviek, toto by malo postacovat a nemusi sa duplikovat informacia aj v dokumente, dokument ma obsahovat prepojenie na koncoveho pouzivatela a user journey
Text je extrémne technokratický a dodávateľský, nie je zameraný na potreby a skúsenosť koncového používateľa.
Chýba prepojenie na používateľský kontext, persony, scenáre, ciele.
Nie je štruktúrovaný do formy „požiadavka = funkcionalita + odôvodnenie + priorita + zdroj“, ako sa očakáva v I-04 Katalógu požiadaviek.
Existuje referencia na prilohu katalog poziadaviek, toto by malo postacovat a nemusi sa duplikovat informacia aj v dokumente, dokument ma obsahovat prepojenie na koncoveho pouzivatela a user journey
Text je extrémne technokratický a dodávateľský, nie je zameraný na potreby a skúsenosť koncového používateľa.
Chýba prepojenie na používateľský kontext, persony, scenáre, ciele.
Nie je štruktúrovaný do formy „požiadavka = funkcionalita + odôvodnenie + priorita + zdroj“, ako sa očakáva v I-04 Katalógu požiadaviek.
Existuje referencia na prilohu katalog poziadaviek, toto by malo postacovat a nemusi sa duplikovat informacia aj v dokumente, dokument ma obsahovat prepojenie na koncoveho pouzivatela a user journey
Nie je zrejmé, čo reprezentuje stĺpec „Dátum“ – ide o dátum vzniku rizika, termín implementácie mitigácie alebo očakávaný dátum výskytu? Túto informáciu je potrebné explicitne uviesť.
Zároveň upozorňujem, že väčšina uvedených dátumov už spadá do minulosti, čo znižuje dôveryhodnosť celého hodnotenia rizík. Viaceré riziká majú nízku váhu, napriek tomu, že ich pravdepodobnosť výskytu alebo dopad na projekt je vzhľadom na fázu plánovania (05/2025) reálne vyššia.
Napríklad pri riziku ohrozenia harmonogramu je uvedená iba stredná pravdepodobnosť, hoci sa projekt nachádza tesne pred implementáciou a ukončenie je plánované na 06/2026 – čo je vzhľadom na zložitosť projektu relatívne krátke obdobie.
Odporúčam revidovať celú tabuľku rizík tak, aby zohľadňovala aktuálny stav projektu a realistické predpoklady jeho implementácie. Výsledné hodnotenie vážnosti rizík by malo korelovať so skutočným harmonogramom a stavom pripravenosti.
Neformálne a neúplné zdôvodnenia k jednotlivým alternatívam
Vyhodnotenie MCA v tabuľke „áno/nie“ bez odôvodnenia pri jednotlivých kritériách je v rozpore so šablónou, ktorá vyžaduje ku každému "áno/nie" aj odôvodnenie.
V dokumente chýba tabuľka so zdôvodnením kritérií pre jednotlivé stakeholder skupiny, hoci sú v texte spomenuté. Ich hodnotenie je iba schematicky „X“, čo nie je postačujúce.
Ak má alternatíva nesplnené čo i len jedno KO kritérium, nemá byť hodnotená ďalej – no v tejto MCA sú aj alternatívy s nesplnenými KO kritériami ďalej posudzované a započítané.
Alternatíva 2 napríklad nespĺňa kritérium C (KO), ale je hodnotená a odporúčaná ako relevantná
Uvedený diagram pôsobí príliš genericky a agreguje rôznorodé informačné systémy a kanály do len niekoľkých kategórií (napr. „IS FO/PO“, „IS VS“), čím sa stráca granuralita a konkrétnosť. Diagram v skutočnosti nezobrazuje sústavu biznis procesov, ale len jeden všeobecný, zjednodušený priebeh životnej situácie, čo je vzhľadom na rozsah projektu nepostačujúce.
Projekt obsahuje viac než 15 samostatných modulov a pokrýva 16 životných situácií. Takéto abstraktné znázornenie neodráža ich konkrétnu funkčnosť, prínosy ani zodpovednosti jednotlivých aktérov v procese. V tejto podobe diagram neposkytuje dostatočnú výpovednú hodnotu pre ďalšie vrstvy architektúry (aplikačná, integračná, prevádzková) ani pre nadväzujúce časti ako MCA či CBA.
Odporúčame zobraziť jednotlivé procesy (alebo aspoň reprezentatívne príklady ŽS) samostatne a doplniť väzby na konkrétne moduly SVK3, ktoré ich podporujú – vrátane zodpovedností OVM, MIRRI/NASES a koncových používateľov.
Uvedený diagram ilustruje základné biznis procesy súvisiace s poskytovaním a využívaním dôveryhodných služieb v zmysle nariadenia eIDAS, pričom zohľadňuje tri kľúčové skupiny aktérov: OVM, FO/PO a NASES (ako SNCA). Napriek správnemu identifikovaniu aktérov a základných procesov je však jeho výpovedná hodnota obmedzená z nasledovných dôvodov:
Príliš vysoký stupeň abstrakcie – Biznis procesy ako „Manažment certifikátov“ a „Využívanie dôveryhodnej služby“ sú znázornené ako jediné bloky, pričom nezachytávajú ich členenie na kľúčové podprocesy (napr. registrácia, vydanie certifikátu, podpis, zneplatnenie, remote sealing, auditovanie, incident handling, atď.).
Chýbajúce väzby na konkrétne služby – Diagram neodlišuje rôzne typy dôveryhodných služieb (napr. kvalifikovaný elektronický podpis, pečať, časová pečiatka, validácia), čím sa stráca schopnosť rozlíšiť dopad projektu na jednotlivé procesy.
Nezohľadňuje nové požiadavky projektu SVK3.0 – V projekte sa počíta s konsolidáciou SNCA, zavedením samoobslužného portálu, zavedením remote signing/sealing, podporou SAM/HSM modulov, a ďalšími významnými zmenami – tieto skutočnosti v diagrame nie sú reflektované.
V EA ako aj Bizzdesign existuje funkcia legenda kde je mozne v ramci diagramu prehladne uviest farebne oznacenie s popisom, prosim pouzivajte tuto fukncionalitu namiesto slovneho popisu, takto je to neprehladne.
Predložený diagram má ambíciu vizualizovať komponentovú architektúru modernizovanej platformy SVK3.0 v notácii ArchiMate, konkrétne na úrovni aplikačnej vrstvy. Hoci obsahuje relevantné komponenty a väzby, jeho súčasná forma výrazne znižuje čitateľnosť a vypovedaciu hodnotu z nasledovných dôvodov:
1. Vizuálny chaos a nečitateľnosť
Diagram prepája viac ako 15 komponentov jedným typom vzťahu, ktorý je použitý konzistentne, no bez vizuálneho rozlíšenia významu týchto väzieb (napr. či ide o závislosť, výmenu dát, volanie služby a pod.).
V dôsledku vysokého počtu prvkov a krížiacich sa liniek vzniká vizuálny chaos, ktorý znemožňuje rýchle porozumenie štruktúre alebo logike systému.
Chýba legenda alebo farebný kód, ktorý by vysvetľoval význam zvoleného farebného rozlíšenia (napr. zelené, modré, ružové, tyrkysové komponenty), čo ešte viac sťažuje interpretáciu.
2. Prílišná abstrakcia bez väzby na používateľské scenáre
Diagram nezachytáva žiadny konkrétny prípad použitia alebo funkcionalitu, čo je problém vzhľadom na to, že SVK3 pokrýva viac ako 15 komponentov a 16 životných situácií.
Zobrazenie všetkých komponentov naraz je prehľadovo nevhodné – chýba modulárne členenie podľa domén alebo procesných celkov (napr. identita, komunikácia, formuláre, orchestrácia).
Nie je zrejmé, ktoré komponenty sú poskytovateľmi služieb, ktoré sú konzumentmi, a aký je ich konkrétny prínos v rámci riešenia životnej situácie.
3. Zneužitie prvku "Application Collaboration"
Diagram pôsobí dojmom, že Application Collaboration alebo obdobné štruktúry boli nadužívané len ako „kontajnery na všetko“, bez toho, aby vyjadrovali skutočný model spolupráce medzi komponentmi (čo je ich pôvodný účel v ArchiMate).
Nedostatocne zakreslenie, prilisna abstrakcia, COP poskytuje informacie len mobilnej aplikacii? CNM posiela notifikacie len IS VS? Ziadne ine aplikacne sluzby ako zasielanie notifikacii nebude poskytovat CNM? Co ostatne casti AS?
Dopracovat do vacsieho detailu a zladit s katalogom poziadaviek.
Tento popis síce prezentuje modernizáciu a rozšírenie funkcionality komponentov ÚPVS ako krok vpred, no zároveň obsahuje vnútorný rozpor, ktorý spochybňuje deklarovaný cieľ eliminovať vendor lock-in.
Ak totiž návrh riešenia trvá na spätnej kompatibilite so súčasným (monolitickým a proprietárnym) riešením, znamená to v praxi:
Zachovanie existujúcich rozhraní, ktoré boli navrhnuté a implementované konkrétnym dodávateľom.
Obmedzenie možností architektonickej slobody pre nové komponenty – tie musia rešpektovať technické a procesné špecifiká pôvodného systému.
Ťažkosti pri nahrádzaní alebo modularizácii systémov, pretože nový modul musí „hrať podľa pravidiel starého sveta“.
Pretrvávanie závislosti na know-how, dokumentácii a neformálnych dohodách viazaných na pôvodného dodávateľa.
Inými slovami, spätná kompatibilita je často synonymom technologického dlhu, a ak nie je riadne ošetrená (napr. cez proxy vrstvy alebo API gatewaye), znižuje efektívnosť snahy o otvorenosť a vendor-neutralitu.
Ak projekt deklaruje, že jeho súčasťou sú aj technologické a organizačno-procesné zmeny s cieľom zvýšiť efektivitu prevádzky NASES, potom je nevyhnutné tieto zmeny detailne rozpracovať v projektovej dokumentácii.
Konkrétne by dokumentácia mala obsahovať:
Popis kľúčových prevádzkových procesov, ktoré budú optimalizované alebo novo zavedené (napr. incident management, change management, monitoring, kapacitné plánovanie).
Organizačné dopady, vrátane zodpovedností, nových kompetencií a zmien v riadení služieb (napr. prechod činností z externého dodávateľa na interný tím NASES).
Architektonické riešenia, ktoré umožnia túto optimalizáciu (napr. konsolidácia logovania, CI/CD nástroje, DevOps podpora, kontajnerizácia).
Merateľné prínosy a KPI, ktoré preukážu efekt zvýšenej prevádzkovej efektívnosti (napr. skrátenie času nasadenia, zníženie MTTR, zníženie nákladov na L2/L3 support).
Bez týchto informácií ostáva tvrdenie o optimalizácii len formálne a nie je možné ho reálne posúdiť v rámci hodnotenia prínosov a realizovateľnosti projektu.
V tomto diagrame je uz legenda pouzita spravne avsak mame 2 obrazky ktore len sumarizuju sadu modulov pre SVK 3.0, tato informacia uz bola v dokumente uvedena viackrat. Nakolko je legenda v oboch obrazkoch, staci ponechat jeden kedze je v nich rozpor, v oboch sa znazornuje sada zmien, nema teda zmysel rozdelovat aj nazvoslovne aj legendou.
Uvedený diagram nepredstavuje model z konkrétneho projektu, ale všeobecnú schému ArchiMate metamodelu, ktorá popisuje vzťahy medzi typmi elementov v rámci ArchiMate notácie.
Ako taký nemá v projektovej dokumentácii priamy prínos – neukazuje žiadne konkrétne riešenie, proces, architektúru ani výstup projektu. V tomto kontexte postačuje uviesť, že projekt využíva modelovanie v súlade s metodikou ArchiMate, a ak je potrebné pracovať s modelmi, mali by byť zamerané na konkrétne vrstvy (napr. business, application, technology) a podporovať rozhodovanie alebo plánovanie zmien.
Zaradenie metodologického prehľadu bez väzby na konkrétne artefakty alebo interpretáciu pôsobí nadbytočne.
Podľa § 24a ods. 5 zákona č. 95/2019 Z. z. o informačných technológiách vo verejnej správe možno na výkon verejnej moci využívať výhradne cloudové služby, ktoré sú riadne zaradené v Katalógu vládnych cloudových služieb.
Interná infraštruktúra NASES, ako je uvedené v dokumente, nie je v čase vyhodnotenia projektu zaradená v katalógu, čo znamená, že jej využívanie by bolo v rozpore so zákonom a súvisiacimi vykonávacími predpismi (napr. vyhláškou č. 179/2020 Z. z.). Taktiež nie je preukázané, že táto infraštruktúra spĺňa požadované bezpečnostné a prevádzkové štandardy definované MIRRI pre vládny cloud, keďže k tomu neexistuje žiadne rozhodnutie o jej overení/zápise.
Z časového hľadiska nie je reálne predpokladať, že zápis do katalógu by bol ukončený pred plánovaným dodaním projektu, čím vzniká legislatívne a prevádzkovo-rizikové vákuum.
Z tohto dôvodu je potrebné prehodnotiť prevádzkové ciele projektu a navrhnúť využitie výhradne takých cloudových služieb, ktoré sú už v čase podania projektového zámeru zaradené v katalógu vládnych cloudových služieb – teda:
verejné cloudové služby (napr. Microsoft Azure, AWS, OCI) zaradené v katalógu,
privátny cloud prevádzkovaný MV SR, ktorý je v súlade s požiadavkami MIRRI a zákonom č. 95/2019 Z. z.
Používanie akejkoľvek inej infraštruktúry bez riadneho zápisu do katalógu je nezlučiteľné s platnou legislatívou a môže predstavovať porušenie zákona pri výkone verejnej moci.
Github nie je infraštruktúrna cloudová služba v zmysle zákona č. 95/2019 Z. z. a rámcových dokumentov MIRRI. Ide o vývojové prostredie a repozitárovú službu, ktorá je síce zaradená v Katalógu vládnych cloudových služieb ako doplnková služba pre DevOps, avšak nepredstavuje platformu ani infraštruktúru pre prevádzku informačných systémov verejnej správy.
Na základe oficiálne publikovaného dokumentu Plánu obnovy a odolnosti SR (11205/23 ADD 1), konkrétne komponentu 17 – Digitálne Slovensko, je cieľ „úplné zavedenie digitálnych riešení pre 16 vybraných životných situácií“ jasne definovaný ako cieľ č. 5 a jeho termín splnenia je stanovený na Q2/2026, teda do 30. júna 2026.
V tejto súvislosti je potrebné objasniť a zosúladiť plánovaný harmonogram realizácie projektu, ak projektový zámer alebo súvisiace dokumenty uvádzajú ukončenie alebo dodanie výstupov po tomto termíne (napr. vo fáze „release final“ alebo v záverečných etapách až do roku 2031). Takýto posun by mohol:
ohroziť naplnenie kľúčového cieľa Plánu obnovy (tzv. C175),
ohroziť čerpanie finančných prostriedkov z mechanizmu obnovy,
a v neposlednom rade podkopať dôveryhodnosť celého transformačného úsilia v očiach občanov aj európskych partnerov.
Ak má projekt aj výstupy nad rámec POO, je potrebné ich jasne oddeliť od tých, ktoré spadajú pod záväzky vyplývajúce z POO a pre ktoré platí termín 30. 6. 2026.
Co popisuje obrazok nizsie? Je zobrazena 3x akceptacia a fakturacia ale nie je uvedene v akom termine sa nachadzaju, nie je uvedene ani ci je potrebne dodat vsetky kategorie poziadaviek. Analyza, implementacia a testovanie su vzdy spojene pre vsetky kategorie, vypovedna hodnota obrazku je nizka.
Komponenty ktore su popisane ale nie su predmetom dodanie je nutne jasne vizualne oddelit aby bolo pre citatela zrozumitelne a jasne co je v projekte dodavane. V popise vidime textom 5.1.1 NASES (sú predmetom projektu) ale tieto vobec popisane nie su. 5.1.2 uz popisane su ale podla popisu nie su predmetom projektu, aku ma teda relevanciu a vahu ich popis v tejto projektovej dokumentacii a ake je ich previazanie na projekt. Uvedene informacie maju byt jasne previazane a cielene pre lepsie pochopenie vazieb a relevancie.
Z nastavených KPI vyplýva, že viaceré kľúčové metriky projektu – ako počet používateľov, počet integrovaných inštitúcií, počet orchestrácií či využitie životných situácií – majú plánované hodnoty dosiahnutia až v rokoch 2027 až 2029, teda po termíne ukončenia realizácie investície definovanom v POO, ktorým je Q2/2026 (30. jún 2026).
Podľa oficiálneho dokumentu 11205/23 ADD 1 k Plánu obnovy a odolnosti SR (Komponent 17 – Digitálne Slovensko) je cieľ:
„Úplné zavedenie digitálnych riešení pre 16 vybraných životných situácií“ s dátumom splnenia do Q2/2026.
K tomu sa viaže požiadavka na:
jednotné miesto pre realizáciu služieb,
funkčný prechod medzi krokmi v rámci životnej situácie,
prístup k informáciám o stave konania,
zapojenie všetkých potrebných OVM do procesu,
a merateľné využívanie služieb občanmi a podnikateľmi.
Postupné dosahovanie cieľových hodnôt KPI až po roku 2026 je v priamom rozpore s deklarovaným stavom „úplnej implementácie“ do Q2/2026. Takto nastavené KPI:
znižujú dôveryhodnosť výstupov projektu v kontexte POO,
môžu viesť k formálnemu naplneniu projektu bez reálneho dosahu na koncových používateľov do požadovaného dátumu,
a môžu byť dôvodom pre finančné korekcie alebo auditné zistenia pri hodnotení plnenia míľnikov Európskou komisiou.
Odporúčanie: Je nevyhnutné revidovať KPI a ich časový rámec tak, aby:
zodpovedali cieľom POO a termínu Q2/2026,
reflektovali skutočné zavedenie a plnohodnotné využívanie služieb zo strany občanov a podnikateľov,
boli v súlade s princípmi plnej funkcionality, ako to požaduje dokument Plánu obnovy (napr. jednotný dizajn, plynulé prechody, notifikácie, integrácia procesov).
Bez takýchto úprav hrozí, že projekt bude hodnotený ako nedostatočne implementovaný, napriek deklarovanému formálnemu ukončeniu.
Prosím o vyjadrenie jednoznačné, či je/nie je potrebná zmena legislatívy - Realizácia projektu je/nie je podmienená prijatím alebo úpravou žiadnych právnych predpisov. Pre účely projektu nie sú potrebné žiadne zmeny v legislatíve potrebné pre naplnenie cieľov a dodanie výstupov projektu. Ak sú - uviesť.
Nesuhlasi. Nazvy sluzieb a ich struktura nesplnaju predpoklady metodiky. Nazvy a popisy su genericke. Ako spustim KS Poskytovanie informácií? Absentuju konkretne popisy urcenia a sposobu vyuzitia koncovych sluzieb. Je to skor funkcionalita portalu ako koncova sluzba.
Inkrementy sa vzajomne prekryvaju, realizačné fázy viacerých inkrementov nie je možné realizovať súbežne a realizačná fáza ďalšieho inkrementu sa začína až po ukončení realizačnej fázy predchádzajúceho inkrementu
Polovica predmetnej prilohy neodpodstatnene vykopirovava informacie z projektovej dokumentacie bez suvislosti na rozpocet a prinosy. Dochadza tak k duplikovaniu textu a vzniku rozdielov.
Zaroven nevidim dovod vytvarat samostatnu prilohu pre popis prinosov. Ak na nej trvate, prosim o abstrakt najzasadnejsich informacii podla sablony priamo sem do PZ
Prosím o korektné vyplnenie kapitoly Rozpočet a prínosy za účelom jednoznačnosti pre posúdenie hospodársnosti a efektívnosti projektu. Tzn. korektné údaje z CBA potrebujeme vidieť v tejto kapitole.
Podľa § 8 401/2023 používateľský prieskum má byť súčasťou a výstupom prípravnej a iniciačnej fázy projektu. Vychádza vaša špecifikácia potrieb používateľa z používateľského prieskumu?
Absentujú výstupy - Odporúčame postupovať podľa § 8 401/2023 - ak je súčasťou projektu alebo zmenovej požiadavky v prevádzke vytvorenie alebo zmena elektronickej služby s grafickým používateľským rozhraním slúžiacej koncovým používateľom, vytvorenie alebo zmena elektronickej služby s aplikačným rozhraním, spôsoby a postupy elektronizácie agendy verejnej správy podľa osobitného predpisu sú realizované v týchto projektových fázach: a) používateľský prieskum, ktorý je výstupom prípravnej a iniciačnej fázy projektu a predmetom ďalšieho spracovania v realizačnej fáze projektu, b) iniciálny grafický návrh, ktorý je výstupom realizačnej fázy projektu v etape Analýza a Dizajn, c) vytvorenie informačnej architektúry a mapovanie používateľskej cesty, ktoré sú výstupom realizačnej fázy projektu v etape Analýza a Dizajn, d) vytvorenie prototypu používateľského rozhrania a prototypu aplikačného rozhrania viacerými iteráciami, ktoré sú výstupom realizačnej fázy projektu v etape Analýza a Dizajn, e) používateľské testy funkčného používateľského rozhrania a funkčné, integračné a výkonové testy aplikačného rozhrania, ktoré sú výstupom realizačnej fázy projektu v etape Implementácia a Testovanie.
Datum je v minulosti
Neuspesne pridanie obrazku nizsie file:///C:
Navrhujeme doplniť legendu ku všetkým diagramom pre zlepšenie čitateľnosti a orientácie používateľa.
V prípadoch, kde sa používajú farebné odlíšenia (napr. existujúce vs. nové komponenty), je nevyhnutné, aby tieto boli konzistentne uplatnené v celom dokumente.
Zároveň upozorňujeme, že ak diagram zobrazuje komponenty, ktoré nie sú predmetom tohto konkrétneho projektu, nemali by byť vizuálne znázornené rovnakou farbou ako komponenty, ktoré projekt skutočne pokrýva. Formulácia typu „nie všetky červenou označené komponenty sú súčasťou tohto projektu“ je mätúca a znižuje vypovedaciu hodnotu schémy.
Odporúčame:
Diagram je nejasný a ťažko čitateľný. Na základe prvej časti (časť Návody) predpokladám, že ide o znázornenie procesného toku v prostredí UPVS – konkrétne pre publikovanie, vyhľadávanie a konzumáciu obsahu.
Nie je však zrejmé, akú notáciu diagram používa – pravdepodobne ide o kombináciu BPMN prvkov s vlastnou (neformálnou) architektonickou vizualizáciou. Takéto zobrazenie si vyžaduje podporné prvky, ktoré momentálne absentujú.
Medzi hlavné problémy diagramu patrí:
Kapitola 3.1 Manažérske zhrnutie by mala byť stručným, jasným a štruktúrovaným vysvetlením základného rámca projektu – jeho účelu, predmetu, cieľovej skupiny, výšky rozpočtu a prínosov. V zmysle šablóny výstupu I-02 (Vyhláška č. 401/2023 Z. z.) sa od tejto kapitoly očakáva najmä zrozumiteľné zhrnutie odpovedajúce na otázky:
Prečo sa projekt realizuje? Čo konkrétne rieši? Pre koho je určený? Koľko bude stáť a aký bude jeho prínos?
Z uvedených dôvodov odporúčam diagram zo súčasnej verzie kapitoly 3.1 odstrániť a presunúť do relevantnej technickej časti dokumentu (napr. kapitola 5 – Architektúra, alebo príloha). Aktuálna vizuálna forma diagramu je ťažko čitateľná a bez doplnenia legendy neposkytuje jednoznačnú výpovednú hodnotu. Zároveň svojim technickým detailom a rozsahom nepatrí do úvodného manažérskeho zhrnutia.
Text v kapitole 3.1 sa venuje prevažne projektom realizovaným v predošlom programovom období (OPII PO7), ako sú Modernizácia UPVS, MÚKC alebo KSDR. Tento obsah však nezodpovedá účelu kapitoly manažérskeho zhrnutia podľa šablóny dokumentácie definovanej vo vyhláške č. 401/2023 Z. z.
Od kapitoly manažérskeho zhrnutia sa očakáva, že stručne, jasne a štruktúrovane vysvetlí:
Zároveň upozorňujem, že opisy minulých projektov bez objektívne doloženého vyhodnotenia ich prínosov moze priniest sadu novych otazok ako - Aka hardwareová infrastruktura bola obnovená? "V rámci projektu bola dodaná a obnovená hardvérová infraštruktúra vrátane potrebných SW licencií.", su projekty ako CAMP uz produkcne pouzivane a prinasaju prinos tak ako sa hodnoti v tomto manazerskom zhrnuti?
Toto nie je relevantne pre kapitolu Manazerske zhrnutie
Nie je dôvod domnievať sa, že navrhované opatrenia – ako je technologická obnova systémov slovensko.sk, automatizácia spracovania životných situácií či zavedenie modulov ako COP (centrálna orchestračná platforma) – neprispievajú k efektívnejšiemu vynakladaniu verejných finančných prostriedkov.
Zavedenie modulu COP umožňuje flexibilnú konfiguráciu procesov bez potreby zásahov externých dodávateľov, čím výrazne prispieva k eliminácii vendor lock-in, skracuje čas na implementáciu zmien a znižuje pracnosť správy služieb v čase. Tieto vlastnosti priamo podporujú ciele hospodárnosti, efektívnosti a účelnosti v zmysle zákona o rozpočtových pravidlách verejnej správy.
Ak sa tieto systémové a prevádzkové výhody očakávajú od nových komponentov (najmä COP), prečo nie sú uvedené v časti „Motivácia projektu“ alebo „Rozsah projektu“ ako deklarovaný prínos?
Plánuje sa skutočne tento modul použiť na podporu flexibilného a opakovane využiteľného modelu správy životných situácií, alebo ide len o technickú integráciu bez zmeny v prístupe k riadeniu služieb?
V rámci princípov navrhovaných pre novú platformu (SVK3 – NASES) chýbajú viaceré zásadné architektonické a prevádzkové princípy, ktoré sú explicitne uvedené v Národnej koncepcii informatizácie verejnej správy 2021 (NKIVS 2021) a mali by byť záväzné pre všetky projekty verejnej správy.
Sluzba ako platforma, zdielane centralne bloky, efektivnost a uspornost, odlucenie od vendor lock-in, multikanalovy pristup, asistovane sluzby, modularita a dekompozicia, jednotny dizajn, open source preferencia,
Viete argumentovat, ze dekompozicia je vlastne popisana ako preferencia pre REST integracie ale tuto vazbu tam treba uviest aby bolo jasne ci toto je jediny nastroj ako idete splnit poziadavku na dekompoziciu tak aby sa naplnala NKIVS
Prosím o extrakciu a uplatnenie všetkých relevantných architektonických princípov platných v štáte, najmä z dokumentu NKIVS 2021.
Tato cast opat zachadza prilis zbytocne hlboko do historickeho kontextu a projektov ktore sa realizovali v minulosti namiesto toho aby jasne popisala motivaciu pre tento projekt.
Predpokladam, ze v projekte nejde len o optimalizaciu a vymenu backendovych sluzieb. Tato cast musi popisat aky problem chcete projektom odstranit, to co projekt chce spravit by malo byt uz navnimane z manazerskeho zhrnutia.
Text v tejto časti neplní účel kapitoly v zmysle šablóny podľa vyhlášky č. 401/2023 Z. z. Namiesto vecného zhrnutia problému, identifikácie dotknutých biznis procesov a rámcového rozsahu projektu obsahuje len podrobný popis architektúry, historického vývoja a technických modulov, ktoré nie sú relevantné pre túto časť dokumentu.
Upozorňujeme, že ide prevažne o popis modulov IS a technickej infraštruktúry, nie o opis biznis procesov, ktoré majú byť predmetom projektu. Text preto uniká pôvodne definovanému účelu tejto kapitoly.
Odporúčanie:
v zmysle šablóny podľa vyhlášky č. 401/2023 Z. z. by toto mala byt kapitola 3.3
v zmysle šablóny podľa vyhlášky č. 401/2023 Z. z. je kapitola 3.3 urcena pre Stakeholderov v projekte
3.4 Ciele projektu podla v zmysle šablóny podľa vyhlášky č. 401/2023 Z. z.
Preco je tu stlpec Informacy system?
Je naozaj MIRRI Biznis vlastnik pre tuto platformu a zoznam jej modulov alebo je to NASES?
Ma byt kapitola 3.4 v zmysle šablóny podľa vyhlášky č. 401/2023 Z. z.
Aplikovat do diagramov a architektury
Formulácia „platforma by mala fungovať aj v mobilnej verzii“ vyznieva nepresvedčivo a znižuje dôveryhodnosť záväzku projektu voči deklarovaným cieľom.
Otázka znie: Je mobilná verzia platformy povinnou súčasťou riešenia, alebo len želaným vedľajším efektom?
Ak je cieľom projektu výrazne zvýšiť využiteľnosť elektronických služieb občanmi, potom mobilná prístupnosť a responzívne používateľské rozhranie by nemali byť formulované hypoteticky („by mala“), ale ako jednoznačný zámer a požiadavka na výsledný stav riešenia.
Odporúčanie:
Opat "by mali"
Aplikovatelne pre celu kapitolu - prilis a zbytocne dlhe pasaze opisujuce POO, vyzvy, program a koncepcie. Toto su vychodiska, nie samotne ciele projektu na ktore by sa tento dokument mal zameriavat
Ma byt kapitola 3.5 v zmysle šablóny podľa vyhlášky č. 401/2023 Z. z.
Ako sa vypocital tento narast a preco v prvom roku dodania do produkcie planuje KPI iba s hodnotou 10.000 ked predpokladam, ze bude v tento moment najvacsia propagacia dodaneho projektu.
Pod modernizaciou sa mysli aj
ID-SK, prechod do noveho eForm, prepojenie s predvyplnovanim udajov a ich naplnanie.
Ake su kriteria modernizacie formularov?
Podľa dokumentácie bolo zo strany MIRRI pre účely investičného plánu prioritných životných situácií – za účelom mitigácie rizika nesplnenia cieľa C175 v termíne do Q2/2026 – vybraných 17 životných situácií. Zároveň sa uvádza, že v rámci POO SR bude reálne implementovaných len 16.
Zároveň však KPI tabuľka predpokladá postupný nárast počtu inštitúcií integrovaných na spoločnú zbernicu udalostí až do roku 2029, čo vyvoláva otázky ohľadom úplnosti riešení, ktoré budú dodané v rámci tohto projektu.
Otázky na objasnenie:
Tento postupný nárast signalizuje, že platforma nebude po dodaní v plnej miere spôsobilá poskytovať používateľovi ucelený pohľad na riešenie jeho životnej situácie, čo je kľúčový deklarovaný cieľ projektu. Odporúčame preto objasniť:
Plati ten isty komentar ako vyssie
Nastavenie KPI „počet krokov v orchestrácii“ s cieľovou hodnotou 10 pôsobí nelogicky a je v rozpore s princípmi procesnej optimalizácie. Ak je cieľom projektu zjednodušiť a zracionalizovať riešenie životných situácií, potom nemá dávať zmysel kvantifikovať úspešnosť podľa toho, koľko krokov orchestrácia obsahuje.
Takto definovaný ukazovateľ môže mať neželaný vedľajší efekt – motivovať k umelému zvyšovaniu počtu krokov aj tam, kde by ich bolo možné procesne zlúčiť alebo eliminovať, čo ide proti cieľu znižovania zložitosti a zvyšovania používateľskej jednoduchosť.
Toto KPI v podobe „3 % podiel využitia“ je matematicky aj metodicky slabé a nevystihuje reálne využívanie ani prínos jednotlivých životných situácií. Odporúčam ho preformulovať alebo nahradiť KPI s jasne merateľným výsledkom (napr. počet úspešných podaní, počet interakcií, spokojnosť).
Toto KPI v podobe „3 % podiel využitia“ je matematicky aj metodicky slabé a nevystihuje reálne využívanie ani prínos jednotlivých životných situácií. Odporúčame ho preformulovať alebo nahradiť KPI s jasne merateľným výsledkom (napr. počet úspešných podaní, počet interakcií, spokojnosť).
Podla KPI pocet zmodernizoanych formularov ich ma byt 100 bez postupneho narastu, predpokladal som, ze definicia alebo kriteria modernizacia obsahuju aj predvyplnanie formularov. Tieto KPI tomu ale nenaznacuju takze opat ziadam o ich kriteria, co sa rozumie pod pojmom modernizacie.
Preco v pripade, ze mame modernizaciu 100 formularov nebude projekt ihned aj predvyplnat udaje pre 100 formularov? Existuju nejake technicke obmedzenia alebo ine navaznosti na projekty ked sa pocita s narastom kedze tu ide o implemetnaciu v ramci projekt?
Co je myslene pod pojmom sandbox?
Testovacie prostredie a sandbox nie sú to isté, hoci sa tieto pojmy často (nesprávne) zamieňajú. Rozdiel medzi nimi je dôležitý najmä v projektoch eGovernmentu, kde ide o úroveň prístupu, cieľovú skupinu a účel prostredia.
Aky bude ucel prostredia, komu bude pristupne, pre koho je primarne urcene, ake data bude obsahovat, zrkadli produkcne prostredie etc..
Ma obsahovat aj :
Ako boli zozbierane poziadavky od pouzivatelov?
Vieme prilozit priskum pouzitvatelov ak sa zbierali na zaklade prieskumov?
Opravit cislovenie a radenie/podradenie
Text sa nevenuje priamo používateľom, ich potrebám, problémom ani cieľom. Namiesto toho opisuje:
Ma byt kapitola 3.8 v zmysle šablóny podľa vyhlášky č. 401/2023 Z. z.
Nie je zrejmé, čo reprezentuje stĺpec „Dátum“ – ide o dátum vzniku rizika, termín implementácie mitigácie alebo očakávaný dátum výskytu? Túto informáciu je potrebné explicitne uviesť.
Zároveň upozorňujem, že väčšina uvedených dátumov už spadá do minulosti, čo znižuje dôveryhodnosť celého hodnotenia rizík. Viaceré riziká majú nízku váhu, napriek tomu, že ich pravdepodobnosť výskytu alebo dopad na projekt je vzhľadom na fázu plánovania (05/2025) reálne vyššia.
Napríklad pri riziku ohrozenia harmonogramu je uvedená iba stredná pravdepodobnosť, hoci sa projekt nachádza tesne pred implementáciou a ukončenie je plánované na 06/2026 – čo je vzhľadom na zložitosť projektu relatívne krátke obdobie.
Odporúčam revidovať celú tabuľku rizík tak, aby zohľadňovala aktuálny stav projektu a realistické predpoklady jeho implementácie. Výsledné hodnotenie vážnosti rizík by malo korelovať so skutočným harmonogramom a stavom pripravenosti.
Ma byt kapitola 5.1.1 v zmysle šablóny podľa vyhlášky č. 401/2023 Z. z.
Obrazok alternativ je len povodny template obrazok bez obsahu, potrebne prepracovat
Neformálne a neúplné zdôvodnenia k jednotlivým alternatívam
Alternatívy v biznisovej MCA majú vyjadrovať rozsah a charakter biznis zmien, napr.(nerelevantne data v tabulke za ucelom prikladu):
Uvedený diagram pôsobí príliš genericky a agreguje rôznorodé informačné systémy a kanály do len niekoľkých kategórií (napr. „IS FO/PO“, „IS VS“), čím sa stráca granuralita a konkrétnosť. Diagram v skutočnosti nezobrazuje sústavu biznis procesov, ale len jeden všeobecný, zjednodušený priebeh životnej situácie, čo je vzhľadom na rozsah projektu nepostačujúce.
Projekt obsahuje viac než 15 samostatných modulov a pokrýva 16 životných situácií. Takéto abstraktné znázornenie neodráža ich konkrétnu funkčnosť, prínosy ani zodpovednosti jednotlivých aktérov v procese. V tejto podobe diagram neposkytuje dostatočnú výpovednú hodnotu pre ďalšie vrstvy architektúry (aplikačná, integračná, prevádzková) ani pre nadväzujúce časti ako MCA či CBA.
Odporúčame zobraziť jednotlivé procesy (alebo aspoň reprezentatívne príklady ŽS) samostatne a doplniť väzby na konkrétne moduly SVK3, ktoré ich podporujú – vrátane zodpovedností OVM, MIRRI/NASES a koncových používateľov.
Uvedený diagram ilustruje základné biznis procesy súvisiace s poskytovaním a využívaním dôveryhodných služieb v zmysle nariadenia eIDAS, pričom zohľadňuje tri kľúčové skupiny aktérov: OVM, FO/PO a NASES (ako SNCA). Napriek správnemu identifikovaniu aktérov a základných procesov je však jeho výpovedná hodnota obmedzená z nasledovných dôvodov:
V EA ako aj Bizzdesign existuje funkcia legenda kde je mozne v ramci diagramu prehladne uviest farebne oznacenie s popisom, prosim pouzivajte tuto fukncionalitu namiesto slovneho popisu, takto je to neprehladne.
Predložený diagram má ambíciu vizualizovať komponentovú architektúru modernizovanej platformy SVK3.0 v notácii ArchiMate, konkrétne na úrovni aplikačnej vrstvy. Hoci obsahuje relevantné komponenty a väzby, jeho súčasná forma výrazne znižuje čitateľnosť a vypovedaciu hodnotu z nasledovných dôvodov:
1. Vizuálny chaos a nečitateľnosť
2. Prílišná abstrakcia bez väzby na používateľské scenáre
3. Zneužitie prvku "Application Collaboration"
Opat prilis velka abstrakcia, na evidenciu AS a KS su v dokumente tabulky aj s referenciou na ISVS a kod sluzieb
Legendu uviest priamo v diagrame
Nedostatocne zakreslenie, prilisna abstrakcia, COP poskytuje informacie len mobilnej aplikacii? CNM posiela notifikacie len IS VS? Ziadne ine aplikacne sluzby ako zasielanie notifikacii nebude poskytovat CNM? Co ostatne casti AS?
Dopracovat do vacsieho detailu a zladit s katalogom poziadaviek.
Tento popis síce prezentuje modernizáciu a rozšírenie funkcionality komponentov ÚPVS ako krok vpred, no zároveň obsahuje vnútorný rozpor, ktorý spochybňuje deklarovaný cieľ eliminovať vendor lock-in.
Ak totiž návrh riešenia trvá na spätnej kompatibilite so súčasným (monolitickým a proprietárnym) riešením, znamená to v praxi:
Inými slovami, spätná kompatibilita je často synonymom technologického dlhu, a ak nie je riadne ošetrená (napr. cez proxy vrstvy alebo API gatewaye), znižuje efektívnosť snahy o otvorenosť a vendor-neutralitu.
Ak projekt deklaruje, že jeho súčasťou sú aj technologické a organizačno-procesné zmeny s cieľom zvýšiť efektivitu prevádzky NASES, potom je nevyhnutné tieto zmeny detailne rozpracovať v projektovej dokumentácii.
Konkrétne by dokumentácia mala obsahovať:
Bez týchto informácií ostáva tvrdenie o optimalizácii len formálne a nie je možné ho reálne posúdiť v rámci hodnotenia prínosov a realizovateľnosti projektu.
V tomto diagrame je uz legenda pouzita spravne avsak mame 2 obrazky ktore len sumarizuju sadu modulov pre SVK 3.0, tato informacia uz bola v dokumente uvedena viackrat.
Nakolko je legenda v oboch obrazkoch, staci ponechat jeden kedze je v nich rozpor, v oboch sa znazornuje sada zmien, nema teda zmysel rozdelovat aj nazvoslovne aj legendou.
Tieto su uz popisane a zakreslene v motivacnej vrstve projektu, opat duplicita
Uvedený diagram nepredstavuje model z konkrétneho projektu, ale všeobecnú schému ArchiMate metamodelu, ktorá popisuje vzťahy medzi typmi elementov v rámci ArchiMate notácie.
Ako taký nemá v projektovej dokumentácii priamy prínos – neukazuje žiadne konkrétne riešenie, proces, architektúru ani výstup projektu. V tomto kontexte postačuje uviesť, že projekt využíva modelovanie v súlade s metodikou ArchiMate, a ak je potrebné pracovať s modelmi, mali by byť zamerané na konkrétne vrstvy (napr. business, application, technology) a podporovať rozhodovanie alebo plánovanie zmien.
Zaradenie metodologického prehľadu bez väzby na konkrétne artefakty alebo interpretáciu pôsobí nadbytočne.
Podľa § 24a ods. 5 zákona č. 95/2019 Z. z. o informačných technológiách vo verejnej správe možno na výkon verejnej moci využívať výhradne cloudové služby, ktoré sú riadne zaradené v Katalógu vládnych cloudových služieb.
Interná infraštruktúra NASES, ako je uvedené v dokumente, nie je v čase vyhodnotenia projektu zaradená v katalógu, čo znamená, že jej využívanie by bolo v rozpore so zákonom a súvisiacimi vykonávacími predpismi (napr. vyhláškou č. 179/2020 Z. z.). Taktiež nie je preukázané, že táto infraštruktúra spĺňa požadované bezpečnostné a prevádzkové štandardy definované MIRRI pre vládny cloud, keďže k tomu neexistuje žiadne rozhodnutie o jej overení/zápise.
Z časového hľadiska nie je reálne predpokladať, že zápis do katalógu by bol ukončený pred plánovaným dodaním projektu, čím vzniká legislatívne a prevádzkovo-rizikové vákuum.
Z tohto dôvodu je potrebné prehodnotiť prevádzkové ciele projektu a navrhnúť využitie výhradne takých cloudových služieb, ktoré sú už v čase podania projektového zámeru zaradené v katalógu vládnych cloudových služieb – teda:
Používanie akejkoľvek inej infraštruktúry bez riadneho zápisu do katalógu je nezlučiteľné s platnou legislatívou a môže predstavovať porušenie zákona pri výkone verejnej moci.
Github nie je infraštruktúrna cloudová služba v zmysle zákona č. 95/2019 Z. z. a rámcových dokumentov MIRRI. Ide o vývojové prostredie a repozitárovú službu, ktorá je síce zaradená v Katalógu vládnych cloudových služieb ako doplnková služba pre DevOps, avšak nepredstavuje platformu ani infraštruktúru pre prevádzku informačných systémov verejnej správy.
Co je obsahom Release 1?
V ktorom termine je Release 1?
Na základe oficiálne publikovaného dokumentu Plánu obnovy a odolnosti SR (11205/23 ADD 1), konkrétne komponentu 17 – Digitálne Slovensko, je cieľ „úplné zavedenie digitálnych riešení pre 16 vybraných životných situácií“ jasne definovaný ako cieľ č. 5 a jeho termín splnenia je stanovený na Q2/2026, teda do 30. júna 2026.
V tejto súvislosti je potrebné objasniť a zosúladiť plánovaný harmonogram realizácie projektu, ak projektový zámer alebo súvisiace dokumenty uvádzajú ukončenie alebo dodanie výstupov po tomto termíne (napr. vo fáze „release final“ alebo v záverečných etapách až do roku 2031). Takýto posun by mohol:
Ak má projekt aj výstupy nad rámec POO, je potrebné ich jasne oddeliť od tých, ktoré spadajú pod záväzky vyplývajúce z POO a pre ktoré platí termín 30. 6. 2026.
Co je obsahom Release Final?
V ktorom termine je Release Final?
Co popisuje obrazok nizsie?
Je zobrazena 3x akceptacia a fakturacia ale nie je uvedene v akom termine sa nachadzaju, nie je uvedene ani ci je potrebne dodat vsetky kategorie poziadaviek.
Analyza, implementacia a testovanie su vzdy spojene pre vsetky kategorie, vypovedna hodnota obrazku je nizka.
Presiel kazdy modul klasifikaciou ISVS pre zaradenie U1-U4?
Nazaj pri rieseni ziadnej ZS nepride ani k aktualizacii udajov v CSRU?
Komponenty ktore su popisane ale nie su predmetom dodanie je nutne jasne vizualne oddelit aby bolo pre citatela zrozumitelne a jasne co je v projekte dodavane.
V popise vidime textom 5.1.1 NASES (sú predmetom projektu) ale tieto vobec popisane nie su.
5.1.2 uz popisane su ale podla popisu nie su predmetom projektu, aku ma teda relevanciu a vahu ich popis v tejto projektovej dokumentacii a ake je ich previazanie na projekt. Uvedene informacie maju byt jasne previazane a cielene pre lepsie pochopenie vazieb a relevancie.
Z nastavených KPI vyplýva, že viaceré kľúčové metriky projektu – ako počet používateľov, počet integrovaných inštitúcií, počet orchestrácií či využitie životných situácií – majú plánované hodnoty dosiahnutia až v rokoch 2027 až 2029, teda po termíne ukončenia realizácie investície definovanom v POO, ktorým je Q2/2026 (30. jún 2026).
Podľa oficiálneho dokumentu 11205/23 ADD 1 k Plánu obnovy a odolnosti SR (Komponent 17 – Digitálne Slovensko) je cieľ:
K tomu sa viaže požiadavka na:
Postupné dosahovanie cieľových hodnôt KPI až po roku 2026 je v priamom rozpore s deklarovaným stavom „úplnej implementácie“ do Q2/2026. Takto nastavené KPI:
Odporúčanie:
Je nevyhnutné revidovať KPI a ich časový rámec tak, aby:
Bez takýchto úprav hrozí, že projekt bude hodnotený ako nedostatočne implementovaný, napriek deklarovanému formálnemu ukončeniu.
Prosím o vyjadrenie jednoznačné, či je/nie je potrebná zmena legislatívy - Realizácia projektu je/nie je podmienená prijatím alebo úpravou žiadnych právnych predpisov. Pre účely projektu nie sú potrebné žiadne zmeny v legislatíve potrebné pre naplnenie cieľov a dodanie výstupov projektu. Ak sú - uviesť.
Toto je v tejto kapitole jediny identifikovany problem, aj to pomerne strucne.
MCA je clenena na biznis, aplikacnu a technologicku vrstvu. Uvedena MCA ich nejako nejasne spaja. Zaroven chyba analyza prepouzitie open source SW
Nesuhlasi. Nazvy sluzieb a ich struktura nesplnaju predpoklady metodiky. Nazvy a popisy su genericke. Ako spustim KS Poskytovanie informácií? Absentuju konkretne popisy urcenia a sposobu vyuzitia koncovych sluzieb. Je to skor funkcionalita portalu ako koncova sluzba.
Inkrementy sa vzajomne prekryvaju, realizačné fázy viacerých inkrementov nie je možné realizovať súbežne a realizačná fáza ďalšieho inkrementu sa začína až po ukončení realizačnej fázy predchádzajúceho inkrementu
Polovica predmetnej prilohy neodpodstatnene vykopirovava informacie z projektovej dokumentacie bez suvislosti na rozpocet a prinosy. Dochadza tak k duplikovaniu textu a vzniku rozdielov.
Zaroven nevidim dovod vytvarat samostatnu prilohu pre popis prinosov. Ak na nej trvate, prosim o abstrakt najzasadnejsich informacii podla sablony priamo sem do PZ
Prosím o korektné vyplnenie kapitoly Rozpočet a prínosy za účelom jednoznačnosti pre posúdenie hospodársnosti a efektívnosti projektu. Tzn. korektné údaje z CBA potrebujeme vidieť v tejto kapitole.
Podľa § 8 401/2023 používateľský prieskum má byť súčasťou a výstupom prípravnej a iniciačnej fázy projektu. Vychádza vaša špecifikácia potrieb používateľa z používateľského prieskumu?
Odporúčame uviesť IDSK do zoznamu skratiek a pojmov - IDSK - Jednotný dizajnový manuál elektronických služieb a webových sídiel Slovenska
Absentujú výstupy - Odporúčame postupovať podľa § 8 401/2023 - ak je súčasťou projektu alebo zmenovej požiadavky v prevádzke vytvorenie alebo zmena elektronickej služby s grafickým používateľským rozhraním slúžiacej koncovým používateľom, vytvorenie alebo zmena elektronickej služby s aplikačným rozhraním, spôsoby a postupy elektronizácie agendy verejnej správy podľa osobitného predpisu sú realizované v týchto projektových fázach:
a) používateľský prieskum, ktorý je výstupom prípravnej a iniciačnej fázy projektu a predmetom ďalšieho spracovania v realizačnej fáze projektu,
b)
iniciálny grafický návrh, ktorý je výstupom realizačnej fázy projektu v etape Analýza a Dizajn,
c)
vytvorenie informačnej architektúry a mapovanie používateľskej cesty, ktoré sú výstupom realizačnej fázy projektu v etape Analýza a Dizajn,
d)
vytvorenie prototypu používateľského rozhrania a prototypu aplikačného rozhrania viacerými iteráciami, ktoré sú výstupom realizačnej fázy projektu v etape Analýza a Dizajn,
e)
používateľské testy funkčného používateľského rozhrania a funkčné, integračné a výkonové testy aplikačného rozhrania, ktoré sú výstupom realizačnej fázy projektu v etape Implementácia a Testovanie.