Komentáre k I-03 Prístup k projektu (pristup_k_projektu)

Dokument neuvádza zrozumiteľné metodologické východisko, na základe ktorého boli jednotlivé požiadavky identifikované, zatriedené a mapované na konkrétne komponenty alebo systémy. Ide skôr o súbor vybraných používateľských požiadaviek (EPIC/user story) – bez uvedenia ich pôvodu (napr. výsledok dizajnového workshopu, výskumu používateľských potrieb, analýzy agendových procesov atď.).

Aj keď je uvedená určitá miera väzby na „centrálny katalóg ŽS“, nie je jasné, aký je vzťah medzi týmto zoznamom a reálnymi informačnými systémami jednotlivých OVM – ktoré sú bežne označované ako externé systémy. Namiesto mapovania na konkrétne externé systémy (napr. IS PFS, RIS, IS Sociálnej poisťovne, IS zdravotných poisťovní, a pod.), sú všetky „závislosti“ prezentované skôr ako predpokladané technologické komponenty projektu samotného (napr. IAM, SvM, eDesk, CAMP), teda interné komponenty riešenia.

Z toho vyplýva, že:

• nejde o reálnu analýzu dopadov na externé systémy mimo projektu (t. j. systémy OVM, ktoré budú musieť vykonať úpravy v súvislosti s integráciou na riešenie),
• z pohľadu projektového manažmentu tu chýba identifikácia zainteresovaných strán mimo NASES a ich povinnosti v zmysle závislostí na projekte,
• dokument nespĺňa štandard pre systematickú analýzu závislostí, aký sa predpokladá napr. pri projektovom riadení podľa PRINCE2 alebo v požiadavkách vyhlášky č. 401/2023 Z. z. (príloha č. 2 – Oznámenie o začatí realizácie projektu).

Odporúčanie: Dokument prepracovať s jasným popisom:

• zdrojov požiadaviek (odkiaľ pochádzajú, kto ich validoval),
• presného zoznamu externých systémov a ich vlastníkov (OVM),
• analýzy dopadov (technických a organizačných),
• spôsobu koordinácie zmien a zabezpečenia súčinnosti.

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.

Hoci táto časť textu deklaruje, že nová architektúra rešpektuje vybrané požiadavky, ide len o veľmi úzky a fragmentárny výpočet technologických prvkov a deklarovaných benefitov. Absentuje však ucelený pohľad na architektúru ako celok – nie sú pomenované jej kľúčové súčasti, ktoré sú zároveň nositeľmi najväčšej pridanej hodnoty projektu.

Zásadným nedostatkom je, že v prehľade chýba explicitné zachytenie komponentov ako centrálna zbernica údajov (CZÚ), centrálny orchestrátor procesov (COP), centrálny notifikačný modul (CNM), IAM 3.0, nový PAP alebo nástroje konfigurácie procesov a správy identít, ktoré sú pritom nosnými prvkami navrhovanej architektonickej transformácie.

Tieto komponenty prinášajú zásadné systémové zmeny:

• zlepšujú správu a sledovateľnosť procesov,
• umožňujú efektívnejšie doručovanie zmien (DevOps, low-code),
• odstraňujú závislosť od dodávateľov (vendor-lock),
• umožňujú konfigurovateľnosť, auditovateľnosť a spätnú väzbu.

Ich nezahrnutie medzi rešpektované požiadavky novej architektúry pôsobí ako nepochopenie vlastného návrhu a vedie k oslabeniu dôveryhodnosti celého dokumentu. Projekt by mal jasne preukázať, že architektúra je navrhnutá s ohľadom na kľúčové funkcionality, systémové dopady a prevádzkové výhody, nie len ako súbor technických nástrojov.

Formulácia „v súlade s dizajnovými princípmi a štandardmi organizácie NASES“ je nepresná a zavádzajúca. Štandardy NASES ako organizácie nie sú relevantnou normatívnou autoritou pre návrh IT architektúry vo verejnej správe. Pre návrh a realizáciu informačných systémov verejnej správy sú záväzné najmä:

• vyhláška č. 78/2020 Z. z. o štandardoch pre informačné systémy verejnej správy,
• súvisiace dokumenty a architektonické princípy ITVS,
• rámce ako Národná koncepcia informatizácie verejnej správy (NKIVS),
• európske metodiky ako EIF,
• a architektonické vzory odporúčané v IDSK (Informačný dizajn systém krajiny).

V prípade, že má NASES interne definované vlastné dizajnové princípy, tieto musia byť transparentne zverejnené a zosúladené s vyššie uvedenými normami. Inak ich nemožno považovať za záväzné, ani relevantné pre hodnotenie súladu architektúry.

Odporúčanie: Formuláciu je potrebné preformulovať tak, aby explicitne odkazovala na platné právne predpisy a národné štandardy, nie na interné postupy jedného z realizátorov. V opačnom prípade dochádza k oslabeniu deklarovaného súladu architektúry s pravidlami ITVS.

Zachovávanie spätnej kompatibility predstavuje dvojsečnú stratégiu. Na jednej strane je potrebná pre hladký prechod medzi starým a novým riešením, najmä pri integrácii so závislými systémami. Na druhej strane však môže udržiavať technické dlhy a závislosť od existujúcich proprietárnych riešení, čím zabraňuje reálnemu odstráneniu vendor locku.

Ak projekt deklaruje, že sa snaží o modularizáciu a nezávislosť komponentov, je potrebné, aby zároveň:

• špecifikoval rozsah a časovú obmedzenosť spätnej kompatibility,
• preukázal, že táto kompatibilita nebude znamenať pokračujúcu závislosť na konkrétnom dodávateľovi alebo technológii,
• a uviedol plán jej postupného vypnutia alebo refaktoringu.

Bez týchto prvkov sa zachovanie spätnej kompatibility ľahko môže stať legitimizáciou zachovania existujúcich väzieb na dodávateľov a ich špecifické rozhrania či API, čím sa fakticky znižuje prínos odstránenia vendor locku.

Ak projekt explicitne deklaruje, že zahŕňa aj technologické a organizačno-procesné zmeny, je nevyhnutné tieto zmeny konkrétne špecifikovať a zdokumentovať. V opačnom prípade ide len o formálnu deklaráciu bez preukázateľného obsahu, ktorá nemá žiadnu výpovednú hodnotu a nemá čo hľadať v dodávanej dokumentácii.

Konkrétne očakávania sú nasledovné:

• Výpočet organizačno-procesných zmien – aké procesy sa menia, v akej podobe, kto je za ne zodpovedný, a aký bude ich dopad na chod organizácie.
• Popis nového alebo upraveného procesného modelu, ideálne v štandardizovanej forme (napr. BPMN).
• Naviazanie na architektúru a technické riešenia – ako technologické zmeny podporujú tieto procesné úpravy.
• Merateľné ukazovatele (KPI) – aby bolo možné zhodnotiť, či sa deklarovaná „efektivita prevádzky“ reálne dosiahla.

Bez týchto prvkov nie je možné overiť, že daná časť projektu má reálny obsah a prínos. Zároveň je potrebné, aby sa zmeny pretavili do konkrétnych výstupov plánovania, implementácie a riadenia zmien, inak je takáto časť projektu z pohľadu hodnotenia a riadenia irelevantná a nemala by byť schvaľovaná.

V dokumente je už v rámci pohľadu AS-IS zachytená aj sada plánovaných zmien, čo nie je štandardný prístup.

Bežná prax je buď:

• zobraziť AS-IS a TO-BE stav v samostatných diagramoch, alebo
• použiť jednotný obrázok s jasným vizuálnym odlíšením (napr. farebne alebo štýlom liniek) medzi existujúcim a plánovaným stavom.

Kombinácia oboch prístupov bez jednoznačného rozlíšenia spôsobuje neprehľadnosť a znižuje vypovedaciu hodnotu diagramu. Pre korektné a auditovateľné porovnanie architektonických zmien je potrebné tieto stavy oddeliť.

V ramci projektu nebude menena sada modulov ako PEP, MEF, KAV a podobne? Prosim o preverenie a opravu. 

Formulácia, že nové riešenie má mať „výkon minimálne na úrovni súčasného riešenia“, je nedostatočná a zavádzajúca, keďže rozsah funkcionality, používateľských scenárov aj požiadaviek na dostupnosť a škálovateľnosť sa zásadne rozširuje.

Z hľadiska technických aj prevádzkových parametrov je teda nevyhnutné, aby nové riešenie dosahovalo vyšší výkon, priepustnosť a spoľahlivosť než súčasné IAM, a to s ohľadom na budúce rozšírenie.

Rovnaký výkon ako dnes by znamenal neschopnosť pokryť zvýšené nároky systému, čím by hrozilo spomalenie služieb alebo nedostupnosť.

Zároveň je potrebné odlíšiť, ktoré časti riešenia zachovávajú spätnú kompatibilitu (napr. API) a ktoré musia byť technicky, výkonnostne a používateľsky modernizované.

Opat, vyssie sa pise, ze nove riesenie musi mat funknost, privetivost a vykon minimalne na urovni sucasneho riesenia ale zaroven sa ocakava jednoduchsi pristup k tvorbe reportov a statistik.
V pripade, ze bude dodana naozaj ta minimalna funkcnost ktoru ma sucasne riesenie nedosiahnete jednoduchsi pristup k tvorbe reportov a statistik.

V tejto casti sa ma popisovat biznis architektura a nie aplikacna a technicka architektura, vacsina textu je zatial aplikacne a technicky smerovana. 

Časť „4.1 Biznis vrstva“ nezodpovedá požiadavkám na popis biznis architektúry, ako sú uvedené v metodike a dokumentácii k projektovému zámeru. Namiesto popisu biznis vrstvy bola dodaná len funkčná špecifikácia aplikačných komponentov (modulov), a to s dôrazom na ich technické vlastnosti, nie biznis procesy, služby či prínosy.

V dokumente chýbajú:

• identifikácia životných situácií relevantných pre projekt (vrátane prepočtu nákladov VS/obyvateľov),
• zoznam a popis existujúcich koncových služieb (AS-IS),
• procesné diagramy aktuálneho stavu podľa metodiky MV SR (vrátane zodpovedností, komunikácie),
• optimalizačné príležitosti,
• ukazovatele a metriky výkonnosti súčasného stavu (počty podaní, časy vybavenia, náklady/príjmy),
• TO-BE stav popísaný z hľadiska zmien v procesoch, službách, organizácii VS,
• očakávané ukazovatele a monitorovanie prínosov v zmysle CBA,
• porovnanie AS-IS a TO-BE (napr. formou tabuliek alebo vizuálne).

Aktuálne spracovanie je čisto technologické a neumožňuje:

• pochopiť reálny dopad na verejnú správu a občana,
• vyhodnotiť procesné zmeny alebo zlepšenia v poskytovaní služieb,
• overiť koherenciu s cieľmi CBA a MCA.

❗ Odporúčanie: Vypracovať kompletný popis biznis vrstvy architektúry v rozsahu požiadaviek – vrátane životných situácií, koncových služieb, procesov, metrík, porovnania AS-IS a TO-BE. Bez toho nie je možné hodnotiť prínosy projektu, jeho opodstatnenosť ani plánované výsledky.

V dokumente chýbajú:

• identifikácia životných situácií relevantných pre projekt (vrátane prepočtu nákladov VS/obyvateľov),
• zoznam a popis existujúcich koncových služieb (AS-IS),
• procesné diagramy aktuálneho stavu podľa metodiky MV SR (vrátane zodpovedností, komunikácie),
• optimalizačné príležitosti,
• ukazovatele a metriky výkonnosti súčasného stavu (počty podaní, časy vybavenia, náklady/príjmy),
• TO-BE stav popísaný z hľadiska zmien v procesoch, službách, organizácii VS,
• očakávané ukazovatele a monitorovanie prínosov v zmysle CBA,
• porovnanie AS-IS a TO-BE (napr. formou tabuliek alebo vizuálne).

Časť „4.1.1.2 eIDAS 3/ Stotožňovací modul - Systému na stotožnenie osôb“ nezodpovedá požiadavkám na popis biznis architektúry, ako sú uvedené v metodike a dokumentácii k projektovému zámeru. Namiesto popisu biznis vrstvy bola dodaná len funkčná špecifikácia aplikačných komponentov (modulov), a to s dôrazom na ich technické vlastnosti, nie biznis procesy, služby či prínosy.

V dokumente chýbajú:

• identifikácia životných situácií relevantných pre projekt (vrátane prepočtu nákladov VS/obyvateľov),
• zoznam a popis existujúcich koncových služieb (AS-IS),
• procesné diagramy aktuálneho stavu podľa metodiky MV SR (vrátane zodpovedností, komunikácie),
• optimalizačné príležitosti,
• ukazovatele a metriky výkonnosti súčasného stavu (počty podaní, časy vybavenia, náklady/príjmy),
• TO-BE stav popísaný z hľadiska zmien v procesoch, službách, organizácii VS,
• očakávané ukazovatele a monitorovanie prínosov v zmysle CBA,
• porovnanie AS-IS a TO-BE (napr. formou tabuliek alebo vizuálne).

Aktuálne spracovanie je čisto technologické a neumožňuje:

• pochopiť reálny dopad na verejnú správu a občana,
• vyhodnotiť procesné zmeny alebo zlepšenia v poskytovaní služieb,
• overiť koherenciu s cieľmi CBA a MCA.

❗ Odporúčanie: Vypracovať kompletný popis biznis vrstvy architektúry v rozsahu požiadaviek – vrátane životných situácií, koncových služieb, procesov, metrík, porovnania AS-IS a TO-BE. Bez toho nie je možné hodnotiť prínosy projektu, jeho opodstatnenosť ani plánované výsledky.

Časť dokumentu venovaná modulom eForm Dizajnér a eForm Filler formálne poskytuje AS-IS a TO-BE modely v notácii ArchiMate, avšak nerealizuje požiadavky na popis biznis vrstvy architektúry podľa záväznej štruktúry. Konkrétne:

• Chýba úplný popis AS-IS biznis architektúry, ktorý by vychádzal z reálnych životných situácií, dotknutých koncových služieb, aktuálnych procesov (vrátane BPMN) a súvisiacich ukazovateľov (počty podaní, časové a finančné náklady).
• TO-BE pohľad je len technokratický výpis komponentov, bez vysvetlenia, ako sa zlepší výkon verejnej správy – či už z pohľadu občana, úradu alebo štátu ako celku.
• Chýba zdôvodnenie zmien – nie je vysvetlené, prečo je nové riešenie navrhované práve takto (napr. ktoré problémy súčasného stavu sa riešia, aké riziká sa eliminujú, aké nové schopnosti vznikajú).
• Nie je zadefinovaný procesný dopad na OVM – napr. úspory práce úradníkov, zníženie počtu chýb pri podaniach, zníženie potreby podpory zo strany helpdesku, zníženie nákladov na vývoj šablón a formulárov.
• Neobsahuje žiadne metriky naviazané na CBA alebo KPI z plánu obnovy, ktoré by pomohli odmerať reálne prínosy tohto riešenia.
• Nie je identifikovaná žiadna optimalizačná príležitosť podľa metodiky optimalizácie procesov (MV SR), ani ich vplyv na výkon procesov a náklady.
• Nie je uvedené, ako zmeny reflektujú existujúce legislatívne rámce alebo strategické dokumenty, ako napríklad NKIVS 2021+, IDSK 3.0 či vyhláška o štandardoch ITVS.

🛑 Odporúčanie: Doplniť:

1. Plnohodnotný popis AS-IS a TO-BE stavu – vrátane BPMN procesov pre kľúčové ŽS.
2. Zoznam existujúcich koncových služieb a ich zmeny v rámci projektu (naviazané na MetaIS).
3. Racionalizáciu zmien – prečo sa čo mení, čo sa ruší, aké nové služby vznikajú.
4. Biznis prínosy – kvantifikovateľné aj kvalitatívne, napr. skrátenie času podania, zníženie chybovosti, zvýšenie spokojnosti používateľov.
5. Napojenie na optimalizačné príležitosti (napr. menej krokov, menej fyzických návštev, automatizácia).
6. Zmeny v nákladoch a výnosoch – prepojené s CBA a KPI v projekte aj v pláne obnovy.

Bez doplnenia týchto zásadných častí nie je možné považovať popis biznis vrstvy za kompletný, čím sa výrazne znižuje preukázateľnosť dopadov projektu.

V dokumente sa uvádza, že "koncepčná biznis architektúra modulu sa v rámci SVK 3.0 nebude meniť", no zároveň sú explicitne vymenované viaceré zmeny funkcionalít, ako napríklad:

• podpora responzívneho dizajnu,
• podpisovanie prostredníctvom centrálneho podpisového komponentu,
• kolaborácia nad elektronickým podaním,
• validácia voči MetaIS,
• spracovanie rozpracovaných podaní.

Tieto zmeny majú zásadný dopad na používateľskú interakciu a spôsob výkonu verejnej moci, teda typicky spadajú do rámca biznis architektúry, aj keď sú technicky realizované vo vrstve aplikácií.

Ak sa tieto funkcionality zavádzajú:

• mení sa spôsob, akým občan alebo úradník realizuje úradný úkon,
• dochádza k optimalizácii procesov (napr. skrátenie doby podania, zníženie potreby asistencie),
• zavádza sa kolaboratívny režim práce nad podaniami, ktorý dnes neexistuje,
• a možno predpokladať úsporu v nákladoch či zvýšenie úspešnosti podaní.

Odporúčanie: Ak skutočne dochádza k zavádzaniu nových možností interakcie, zjednodušeniu a úprave tokov medzi občanom, OVM a komponentami ÚPVS, je nevyhnutné revidovať tvrdenie o nemenenej biznis architektúre. Alternatívne je potrebné vysvetliť, prečo sa takéto zmeny nepovažujú za zmenu biznis architektúry, čo však v kontexte architektonických metodík (napr. TOGAF, ArchiMate) nie je štandardné.

Bez zohľadnenia týchto zmien v biznis vrstve nie je možné objektívne posúdiť ani dosah projektu, ani jeho príspevok k zlepšeniu výkonu verejnej správy.

V predloženej časti k modulu Lokátor služieb 3.0 absentuje:

1. Biznis procesný pohľad (BPMN alebo obdobný model) – chýba popis, ako sa mení interakcia používateľov alebo OVM pri registrácii, vyhľadávaní a konzumácii služieb. Vzhľadom na to, že Lokátor je vstupným bodom pre výber služieb občanom aj úradom, ide o významný komponent so zásadným dopadom na používateľský zážitok aj prevádzku služieb.

2. Popis biznis prínosov a racionalizácie – neuvádzajú sa očakávané dopady zavedenia novej funkcionality (napr. vyhľadávanie aj služieb mimo MetaIS, flexibilnejšie konfigurovanie, responzívne UI, atď.). Tie by mohli priniesť:

   • skrátenie času na zverejnenie novej služby,
   • zlepšenie orientácie občana v ponuke služieb,
   • zvýšenie dostupnosti služieb cez viaceré kanály (napr. mobil, slovensko.sk),
   • zníženie chybovosti pri konfigurácii služieb.
3. Vysvetlenie zmeny medzi AS-IS a TO-BE – prezentované obrázky sú veľmi abstraktné (v ArchiMate), bez vysvetlenia zmien v procese, ktoré by vysvetlili čo a prečo sa zlepšuje. Navyše, obrázok AS-IS neobsahuje žiadnu väzbu na realitu alebo metriky výkonu súčasného stavu.

V predloženom materiáli sa v diagrame výslovne uvádza, že:

„Koncepčná biznis architektúra modulu sa v rámci SVK3.0 nebude meniť. Zmeny v eDesk a Úložisku správ sú technologicky integračného charakteru. Preto AS IS a TO BE verzie zdieľajú jeden model.“

Zároveň však textová časť kapitoly explicitne popisuje nové funkcionality, ktoré majú zásadný vplyv na používateľskú skúsenosť aj na prevádzkové scenáre, napríklad:

• podpora mobilnej aplikácie s vlastným GUI,
• rozšírené možnosti správy oprávnení,
• zvýšenie limitov pre veľkosť správ,
• pokročilé možnosti čítania a správy správ v mobilnom prostredí.

🛑 Takéto tvrdenie o nezmenenej biznis architektúre je neakceptovateľné.

➡️ Buď sa biznis architektúra reálne mení a je potrebné to:

• adekvátne priznať a doplniť nové BPMN procesy alebo ich aktualizácie,
• vysvetliť zmenu očakávanej interakcie používateľa alebo OVM s modulom,
• popísať dopad na poskytované služby (napr. dostupnosť mimo webového rozhrania, možnosti mobilného podpisovania),
• a zrevidovať metriky a očakávané prínosy (napr. zvýšenie počtu vybavených správ cez mobil, zníženie latencie, atď.),

alebo:
➡️ Funkcionality uvedené v texte sú len kozmetické/technické a nemajú žiadny dopad na procesnú alebo biznis vrstvu, čo ale v tomto prípade zjavne nie je pravda.

🔁 Odporúčanie: Táto časť musí byť prepracovaná, odstrániť rozpor medzi tvrdením a obsahom textu, doplniť zodpovedajúce modely TO-BE procesov a identifikovať prínosy z pohľadu:

• používateľa (občan/podnikateľ),
• OVM (napr. výkon správy),
• prevádzky (napr. zníženie nákladov, podpora omnichannel doručovania).

Bez týchto doplnení je táto časť zavádzajúca a nespĺňa požiadavky na dokumentáciu TO-BE stavu biznis vrstvy podľa vyhlášky č. 401/2023 Z. z. o štandardoch pre IT VS.

Popis modulu CNM je extrémne stručný a formálny, bez toho, aby poskytoval akékoľvek konkrétne informácie o funkčných zmenách, ktoré má nový modul priniesť. V texte chýba:

1. Detailný popis AS-IS procesov notifikácií a spôsobu ich generovania, autorizácie, doručovania (napr. čo dnes robí ÚPVS, OVM, MetaIS, eDesk).

2. TO-BE popis nového spracovania a distribúcie notifikácií, t. j. vysvetlenie:

   • ako sa majú zmeniť toky informácií,
   • ako sa bude nastavovať šablóna správy,
   • aký bude model rozhodovania o kanáli a čase odoslania (napr. eDesk vs. push notifikácia),
   • ako sa mení interakcia s používateľom alebo inštitúciou.
3. Absencia BPMN modelov, ktoré by ukázali, aké nové procesy CNM zavádza alebo optimalizuje.

4. Žiadne vysvetlenie prínosu z pohľadu biznisu:

   • Skracuje sa čas doručenia?
   • Znižuje sa chybovosť (duplicitné správy, neadresné notifikácie)?
   • Znižujú sa náklady na doručovanie (papier/pošta)?
   • Zvyšuje sa zásah cieľovej skupiny občanov (napr. relevantné upozornenia podľa kontextu)?

Popis modulu Portfólio a profil klienta (PaP) je z formálneho hľadiska nedostatočný, a to hneď v niekoľkých zásadných aspektoch:

1. Nie je poskytnutý žiadny procesný model (napr. BPMN), ktorý by znázornil, ako používateľ interaguje so systémom – napríklad nastavenie notifikácií, zmena zastupovania, alebo konfigurácia preferencií.
2. Chýba akýkoľvek popis AS-IS procesov – nie je jasné, ako používateľ spravuje svoje identity, preferencie alebo oprávnenia v súčasnom stave a v ktorých systémoch (IAM? eDesk? samostatne?).

3. TO-BE stav nie je vysvetlený – v texte sa uvádza, že používateľ bude môcť „nastaviť preferencie pre celý digitálny ekosystém“, ale:

   • Nie je jasné, ktoré systémy tento „ekosystém“ tvoria.
   • Nie je popísané, ako budú tieto preferencie prenášané, synchronizované, alebo uplatňované v iných komponentoch (napr. v eDesk, CNM alebo COP).
   • Nie je uvedené, ako sa zmení UX občana alebo úradníka oproti súčasnému stavu.

4. Nie sú uvedené žiadne konkrétne prínosy:

   • Zníženie duplicít pri nastavovaní preferencií?
   • Zrýchlenie onboardingového procesu?
   • Zlepšenie dostupnosti funkcie zastupovania?
   • Väčšia personalizácia služieb?

5. Z pohľadu požiadaviek vyhlášky 401/2023 Z. z.:

   • Nie sú uvedené ukazovatele výkonu a kvality služieb v AS-IS ani TO-BE stave.
   • Nie je preukázaná optimalizačná príležitosť, ani jej dopad na výkonnosť procesov ŽS.

V dokumente sa na jednej strane uvádza, že koncepčná biznis architektúra sa nemení, avšak zároveň sa podrobne popisujú nové funkcionality a zásadné architektonické zmeny ako:

• mikroslužbová architektúra,
• remote sealing (pečatenie na diaľku),
• podpora pre synchrónnu aj asynchrónnu validáciu podpisov,
• pokročilé logovanie a monitoring,
• spájanie a rozdeľovanie podpisových kontajnerov,
• konverzia medzi formátmi EÚ,
• škálovateľnosť databázy.

Tieto zmeny predpokladame zásadne menia spôsob spracovania podaní z pohľadu:

• interakcie s ostatnými komponentmi (napr. eDesk, CPK),
• spôsobu autorizácie a validácie dokumentov,
• výkonových charakteristík a možností škálovania,
• ako aj vysokú mieru autonómie a flexibility pri spracovaní podaní (napr. asynchrónne spracovanie, ktoré mení dynamiku biznis procesov).

Ak zároveň tvrdíme, že „biznis architektúra sa nemení“, vzniká nevyhnutný rozpor medzi technickou a biznis vrstvou návrhu, ktorý:

• znemožňuje sledovanie reálnych biznis prínosov (napr. skrátenie času na spracovanie, vyššia spoľahlivosť doručenia, rýchlejšie vybavenie),
• neumožňuje vyhodnotiť dopad na životné situácie a procesy verejnej moci,
• degraduje hodnotu TO-BE návrhu, ktorý by mal byť zameraný na zlepšenie služieb občanovi.

Deklarovaný účel modulu COP – orchestrace procesov životných situácií (ŽS) – predstavuje zásadnú architektonickú, technologickú aj funkčnú zmenu v prístupe k digitálnemu výkonu verejnej moci. Nejde len o technickú modernizáciu, ale o zavedenie úplne novej procesnej logiky:

• centrálna koordinácia krokov medzi OVM,
• automatizácia riadenia sekvencie aktivít,
• využitie rozhodovacích pravidiel (DMN),
• a monitoring priebehu procesu z pohľadu štátu aj občana.

V dokumentácii však absentuje zodpovedajúci biznis popis tejto zmeny, čo vedie k významnému nedorozumeniu účelu COP – text miestami evokuje, že ide len o vizualizačný alebo technický nástroj, nie aktívnu výkonnú platformu.

Kľúčové nedostatky:

Chýbajú BPMN modely

• Ak je jednou z hlavných výhod COP možnosť BPMN modelovania, je nevyhnutné preukázať túto funkcionalitu konkrétnym príkladom.
• Odporúča sa demonštrovať 1–2 modely ŽS (napr. narodenie dieťaťa, zmena trvalého pobytu, podanie daňového priznania), ktoré budú po novom riešené cez COP.
• Bez BPMN modelu nie je možné overiť, či platforma reálne plní svoju úlohu – teda riadi priebeh procesu, rozhoduje, eskaluje, vyhodnocuje podmienky a prechod medzi OVM.

Nie je popísané AS-IS vs. TO-BE riešenie procesov

• V projekte absentuje vysvetlenie, ako sa dané ŽS riešia dnes:

  • Aké úkony vykonáva občan manuálne?
  • Akým spôsobom dnes spolupracujú OVM?
  • Kde dochádza k redundantnému zadávaniu údajov alebo k zdržaniu?
• TO-BE stav sa zameriava výlučne na technickú funkcionalitu, nie na biznis dopad pre občana alebo úrad.

Nie sú kvantifikované žiadne prínosy

• Očakávané dopady zavedenia COP nie sú uvedené ani kvalitatívne, ani kvantitatívne:

  • Skrátenie trvania riešenia ŽS (napr. o 30 %),
  • Redukcia počtu podaní alebo krokov,
  • Zníženie interakcie občana s viacerými úradmi,
  • Zvýšenie úspešnosti prvého podania (first-time-right).

Nie sú spomenuté interné procesy správy a governance

• COP zároveň prináša aj významnú zmenu v spôsobe správy procesnej architektúry štátu:

  • Centralizované modelovanie v súlade so štandardmi (BPMN 2.0, DMN),
  • Možnosť jednoduchšieho plánovania, správy a úprav procesov,
  • Zvýšenie transparentnosti a auditovateľnosti procesnej logiky (logy, inštancie, reštarty, vyhodnocovanie pravidiel),
  • Potenciál pre governance – verzovanie, validácia modelov, schvaľovacie workflow pre úpravy.

Tieto interné zmeny (v oblasti modelovania, správy procesov, ich nasadzovania a monitoringu) sú legitímnym biznis prínosom a mali by byť v dokumentácii jasne pomenované, keďže predstavujú kľúčovú racionalizačnú zložku projektu.

Grafické schémy väčšieho rozsahu a komplexnejšej štruktúry je potrebné priložiť vo vektorovom formáte (napr. SVG) alebo vo vyššom rozlíšení, aby bola zabezpečená ich čitateľnosť. V aktuálnej podobe nie je možné diagramy prehliadať v dostatočnej kvalite ani pri priblížení, čo znemožňuje ich efektívne hodnotenie.

Text definuje CZU len ako technický komponent na „prijímanie a sprístupňovanie udalostí“, bez hlbšieho vysvetlenia, čo je biznisová hodnota týchto udalostí:

• Aký problém CZU rieši v praxi?
• Ako CZU pomáha občanovi alebo OVM?
• Ako sa zmení poskytovanie služieb verejnej správy po zavedení CZU?

Bez týchto odpovedí je CZU zredukovaná na „data relay“, nie na kľúčový prvok architektúry event-driven štátu.
 

Rovnako ako pri COP, chýbajú akékoľvek BPMN diagramy, ktoré by demonštrovali použitie CZU v praxi. Napríklad:

• Ktoré udalosti vznikajú pri riešení ŽS a ako sa spracujú?
• Ako sa zmení postupnosť krokov v ŽS, keď systém bude „počúvať“ udalosti?

Bez demonštrácie konkrétneho procesu alebo toku udalostí nie je možné posúdiť reálnu funkciu CZU.
 

Nie je popísané, ako prebieha výmena informácií medzi OVM dnes (manuálne, cez centrálne komponenty, iné integračné služby) a ako sa to zmení po zavedení CZU.

• Kde vznikajú zdržania, redundancia, neaktuálne dáta?
• Ako CZU tieto problémy odstráni?
• Ktoré systémy budú do CZU integrované a čo z toho vyplýva

Nie sú uvedené žiadne merateľné dopady, ako napríklad:

• Skrátenie doby synchronizácie údajov medzi OVM
• Eliminácia potreby „pollingových“ integračných mechanizmov
• Zvýšenie presnosti zobrazenia stavu ŽS pre občana
• Zníženie nákladov na udržiavanie ad-hoc integrácií

​​​​​​​Nie, predložený obsah nespĺňa požiadavky na popis biznis architektúry podľa vyhlášky č. 401/2023 Z. z. a metodických pokynov k vypracovaniu biznis vrstvy v dokumentácii IT projektov. Namiesto toho ide o technický a produktovo-marketingový opis funkcionalít SNCA.

• Nie je uvedené, aké zlepšenia biznis procesov alebo prínos bude modul mat
• Nie je uvedené, aké procesy sa menia, kto ich vykonáva, ako sa mení ich výkon a aké sú vstupy a výstupy.

• Neexistuje žiadny BPMN diagram, ani jednoduché procesné flow, ktoré by ilustrovali:

  • ako je dnes vydávaný mandátny certifikát (AS-IS),
  • ako to bude vyzerať po konsolidácii (TO-BE).

Nie je uvedené:

• koľko autorít dnes existuje, kde sú,
• aké sú súčasné náklady, redundancia, záťaž jednotlivých OVM,
• aký dopad bude mať centralizácia na úrady, občanov, prevádzku a bezpečnosť.

• Neuvádzajú sa žiadne biznis metriky (napr. skrátenie času vydania certifikátu, počet zjednotených procesov, zníženie počtu lokálnych CA).
• Nie je uvedené, ako centralizácia zlepší dostupnosť, spoľahlivosť alebo bezpečnosť služieb z pohľadu používateľa alebo prevádzky.

Obrázky sú len abstraktné ArchiMate výrezy:

• Predložené obrázky síce používajú ArchiMate notáciu, ale:

  • sú vizuálne nečitateľné (z dôvodu nekvalitného formátu),
  • neobsahujú vysvetlenie vzťahov, aktérov a toku aktivít,
  • neposkytujú žiadne pohľady na konkrétnu ŽS alebo službu z pohľadu používateľa alebo OVM.

zoznam evidovaných aplikácií a koncových služieb (KS a AS) je z metodického aj vecného hľadiska nedostatočný a nekorešponduje s rozsahom a ambíciou projektu „Modernizácia Platformy pre rozvoj a riešenie prioritných životných situácií“

• Napriek tomu, že moduly ako eForm Dizajnér, eForm Filler, Orchestrátor (COP), Notifikačný modul (CNM), IAM, CZU, PaP a ďalšie deklarujú množstvo funkcionalít, v zozname sú uvedené len 1–2 aplikačné služby na modul.
• To nereflektuje reálnu granularitu a nedodržiava odporúčania na evidenciu aplikačných služieb podľa funkčných celkov, ktoré budú integrované samostatne.

Podľa metodiky MetaIS by mala mať každá AS väzbu na konkrétnu KS, ktorú implementuje. V uvedenom zozname sú niektoré AS vedené bez takejto väzby alebo len ako „Podpora riešenia ŽS“ bez konkrétneho vymedzenia.

Pri každej koncovej službe by mali byť uvedené životné situácie, ktorých sa týka (napr. „Narodenie dieťaťa“, „Zápis do školy“...). Tu je len „All“, čo je nešpecifické a neumožňuje ani základné naviazanie na CBA, KPI a hodnotenie projektu. 

• Naozaj každá AS bude nevyhnutná pre každú ŽS? 

Z pohľadu integrácie je nutné jasne identifikovať, ktoré AS sú poskytované a ktoré konzumované, obzvlášť pre CZU, COP, IAM, CNM, ktoré budú integrované z viacerých systémov.

Stĺpec „Po sprístupnení MetaIS“ znamená čo? Projekt sa nachádza v pokročilom štádiu a služby už mali byť založené v MetaIS s požadovanými atribútmi a väzbami.

Integrácia na CAMP - Prázdne

Integrácia na AS poskytovateľa - Prázdne 

Realizuje ISVS - Prázdne

• Neuvádza sa, aké komponenty majú byť viacjazyčné (formuláre, portály, notifikácie, metaúdaje, hlavičky správ...).
• Nie je jasné, kde a akým spôsobom sa budú jazykové mutácie spravovať (napr. či bude existovať jazykový modul alebo len textové súbory).
• Nie je uvedené, kto bude zodpovedný za preklady a ako sa bude riešiť verzovanie jazykových mutácií.
• Nie je popisaná podpora pre rozsirovanie lokalizacie 

Naozaj nebude v ziadnej ZS prebiehat aktualizacia teda zapis udajov z registrov? 

Zásadné nedostatky a nesúlady s požiadavkami šablóny podľa vyhlášky č. 401/2023 Z. z.:

🔹 4.3.1 Údaje v správe organizácie

• Problém: Tvrdenie „Údaje nie sú v správe organizácie NASES“ je síce pravdivé, ale nezbavuje predkladateľa povinnosti popísať dátovú architektúru riešenia – predovšetkým z pohľadu:

  • procesu spracovania údajov (napr. aké údaje vstupujú a vystupujú z modulov),
  • životného cyklu údajov,
  • a zapojenia správnych orgánov.
• Chýba diagram tried/logický model údajov a štruktúrovaný popis entít a atribútov (t. j. UML alebo podobný formát) – to je výslovná požiadavka šablóny.

🔹 4.3.2 Dátový rozsah projektu

• Namiesto doménového modelu je len „výpočtový zoznam“ objektov evidencie.
• Chýba diagram doménového modelu, ktorý by ukazoval väzby medzi entitami a prepojenie na centrálne URI z centrálneho dátového modelu (napr. pper:PhysicalPerson).
• Nie je jasné, ktoré objekty sú nové a ktoré sú spätne kompatibilné – iba sa to v texte deklaruje.

🔹 4.3.3 Referenčné údaje

• Tvrdenie, že nevznikajú referenčné údaje, si vyžaduje zdôvodnenie a presné overenie. Je potrebné vysvetliť

🔹 4.3.4 Kvalita a čistenie údajov

• Neuvádza sa žiadny proces čistenia, žiadna prioritizácia kvality dát, žiadny odhad dopadu chybných údajov.
• Nie sú uvedené roly (dátový kurátor, data steward) ani personálne zabezpečenie – tieto požiadavky sú explicitné.
• Nie je uvedená tabuľka hodnotenia kvality a citlivosti údajov.

🔹 4.3.5 Otvorené údaje

• Uvádza sa, že budú sprístupnené ako „v súčasnom stave“, je to naozaj tak a nebudu poskytovane alebo obohacovane? V ramci projektu ZS sa naozaj nepocita, ze budu poskytovane nove otvorene udaje v nejakom rozsahu? 

  • Chýba výpis, ktoré objekty budú otvorené.
  • Nie je uvedená požadovaná interoperabilita (3★ – 5★).
  • Nie je uvedená periodicita publikovania.

🔹 4.3.6 Analytické údaje

• Deklaruje sa odosielanie do DWH, ale:

  • Nie sú uvedené konkrétne objekty evidencie, ich štruktúra, atribúty.
  • Chýba formálna tabuľka zo šablóny.

🔹 4.3.7 Moje údaje

• Tvrdenie, že „nevznikajú dáta typu moje údaje“ je pravdepodobne nesprávne:

  • Moduly ako eDesk, PaP, Konštruktor správ alebo COP budú spracúvať údaje o občanoch.
  • Aj správy alebo stavy procesov súvisia s konkrétnou osobou – teda ide o moje údaje.
• Nesprávne vynechanie povinnej sekcie a nespĺňa to minimálny rozsah.

🔹 4.3.8 Súhrnná tabuľka

• Tabuľka je formálne vyplnená, ale:

  • nie je zosúladená s predchádzajúcimi sekciami – ak je napr. „Služba“ označená ako otvorený údaj, tak to nie je uvedené v 4.3.5.
  • Neobsahuje zdôvodnenie, prečo sú niektoré polia prázdne.

🟡 Zhrnutie hodnotenia:

🔴 Záver:

Kapitola 4.3 ako celok nie je akceptovateľná. Ignoruje veľkú časť požiadaviek definovaných v šablóne a vyhláške 401/2023 Z. z. Vyžaduje zásadné prepracovanie všetkých podkapitol, najmä doplnenie:

• diagramov (triedy, doménový model),
• popisu životného cyklu údajov,
• návrhov na referenčné údaje,
• personálneho zabezpečenia pre dátovú kvalitu,
• formálnych tabuliek pre moje údaje, otvorené údaje a analytické údaje.

Bez tohto doplnenia nie je možné posúdiť dátovú vrstvu ako riadne navrhnutú ani udržiavateľnú.

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. 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

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 nepredstavuje infraštruktúrnu cloudovú službu v zmysle zákona č. 95/2019 Z. z. o informačných technológiách verejnej správy ani podľa rámcových dokumentov MIRRI. Ide o vývojové a repozitárové prostredie, ktoré je síce zaradené v Katalógu vládnych cloudových služieb ako doplnková DevOps služba, avšak nie je určené na samotnú prevádzku informačných systémov verejnej správy.

Na zabezpečenie zálohovania (backupov) sa odporúča využiť verejnú časť vládneho cloudu, ktorá poskytuje škálovateľné, zabezpečené a cenovo efektívne služby v súlade s princípmi „cloud-first“ a s požiadavkami legislatívy.

Dátové centrá NASES nie sú súčasťou vládneho cloudu, preto ich zobrazenie v diagrame ako „Dátové centrum 1 – 3“ môže byť v rozpore s oficiálnou architektonickou dokumentáciou. V prípade, že tieto DC predstavujú infraštruktúru mimo schváleného vládneho cloudu, je potrebné túto skutočnosť explicitne uviesť a zdôvodniť.

Odporúčame vykonať klasifikáciu príslušných ISVS podľa vyhlášky o kategorizácii, následne posúdiť hospodárnosť, efektívnosť a vhodnosť jednotlivých typov cloudových služieb (IaaS, PaaS, SaaS) z Katalógu vládneho cloudu a na tomto základe zvoliť cieľové cloudové umiestnenie jednotlivých komponentov projektu.

Deklarácia, že „súčasťou projektového zámeru je obnova a doplnenie robustnej, škálovateľnej a bezpečnej hybridnej cloudovej infraštruktúry“, je z pohľadu rozsahu, významu aj finančných dopadov zásadná informácia, ktorá však nie je v dokumentácii projektu spracovaná v primeranej hĺbke ani štruktúre.

Vzhľadom na to, že ide o veľký projekt s predpokladaným dopadom na eGovernment infraštruktúru, nie je akceptovateľné, aby sa problematika obnovy hardvérových zdrojov a kapacitného posilnenia dátových centier obmedzila na niekoľkovetné rámcové konštatovanie bez ďalších súvislostí.

Zistené nedostatky a odporúčania:

1. Nedostatočné technické rozpracovanie:

   • V dokumentácii absentuje konkrétny opis technických komponentov, ktoré budú obnovené alebo novo budované (napr. výpočtové uzly, úložiská, sieťová infraštruktúra, bezpečnostné vrstvy, orchestrácia, kontajnerové platformy, CI/CD nástroje).
   • Nie je predložený ani základný sizing, ktorý by určoval, aká infraštruktúrna kapacita je pre jednotlivé moduly a komponenty projektu potrebná, aké sú očakávané výkonnostné a prevádzkové parametre, či aká je miera ich škálovania do budúcna.

2. Absencia prepojenia na CBA a zdôvodnenie investície:

   • Z pohľadu metodiky MIRRI a požiadaviek je nevyhnutné, aby každá väčšia investícia do IT infraštruktúry bola riadne zahrnutá do analýzy nákladov a prínosov (CBA).
   • V dokumente však nie je nijak preukázané, že kapacity dátových centier, ktoré budú v rámci projektu posilňované, sú dnes nedostatočné, vyťažené alebo inak limitujúce. Absentuje justifikácia potreby investície vrátane číselného porovnania „súčasný stav vs. potrebný stav“.

3. Neidentifikovaný poskytovateľ infraštruktúry:

   • Nie je zrejmé, ktorý subjekt má poskytovať túto hybridnú infraštruktúru, či pôjde o nové riešenie pod NASES, alebo o využitie existujúcej časti vládneho cloudu (napr. MV SR alebo verejný cloud).
   • Ak sa uvažuje s využitím dátových centier NASES, treba uviesť, že tieto nie sú súčasťou vládneho cloudu a teda nespĺňajú legislatívne požiadavky vyplývajúce z § 24a zákona č. 95/2019 Z. z. – teda nie sú zapísané v Katalógu vládnych cloudových služieb a ich využitie na výkon verejnej moci nie je v súlade s platnou legislatívou.

4. Chýba katalogizácia a popis služieb:

   • Ak má hybridná infraštruktúra poskytovať služby iným komponentom projektu, je potrebné tieto služby katalogizovať, t. j. uviesť typ služby (IaaS, PaaS, SaaS), SLA, parametre, dostupnosť, bezpečnostné vrstvy a spôsob integrácie.
   • Nie je jasné, ako budú jednotlivé moduly (napr. COP, CZU, eDesk, IAM) prevádzkované – na akých zdrojoch, s akými nárokmi, či tieto zdroje už existujú, alebo sú predmetom obstarania.

Táto kapitola pôsobí ako neformálna prezentácia používaných technológií bez väzby na potreby projektu, bez architektonickej integrácie a bez rozpočtového alebo prevádzkového ukotvenia.

Je nevyhnutné:

1. Prepojiť každú technológiu s konkrétnym modulom alebo komponentom.
2. Uviesť, ktoré technológie sú nové, ktoré existujúce a aké budú ich náklady a prevádzkové dopady.
3. Zaradiť infraštruktúrne rozhodnutia do CBA a vyhodnotiť, či sú v súlade s princípmi vládneho cloudu.
4. Zaradiť výpočet spotreby a sizing (napr. RAM/CPU/disk pre jednotlivé moduly, ich nárast).
5. Vyjasniť právny a prevádzkový rámec využitia „interných služieb“ mimo katalógu vládneho cloudu.

Opat GitHub nie je infrastrukturna sluzba

AS IS stav bezpečnosti (chýba úplne)

🔻 Vyžaduje sa opis aktuálneho stavu bezpečnostnej architektúry (Ramcovo tak aby sa nedal extrahovat potencialny vektor utoku)

➡️ Doplniť samostatnú podkapitolu AS IS bezpečnostná architektúra.

Porovnanie alternatív (tiež chýba)

🔻 Šablóna žiada porovnanie alternatívnych prístupov k navrhnutej bezpečnostnej architektúre.

• Napr. pre autentifikáciu – interné IAM vs. externý GovIAM vs. SAML federácia.
• Pre SIEM – vlastný Elastic vs. nákup služby z vládneho cloudu.
• Pre segmentáciu – VPN vs. service mesh vs. fyzická segmentácia.

Preukázanie súladu s právnymi a technickými normami

🔻 text tieto zákony a vyhlášky neuvádza explicitne:

• Zákon č. 95/2019 Z. z.
• Zákon č. 69/2018 Z. z.
• Vyhlášky č. 78/2020, 179/2020, 158/2018 Z. z.
• GDPR a zákon č. 18/2018 Z. z.

➡️ Vlož jednu vetu k jednotlivým normám, ktorá deklaruje súlad (napr. „Riešenie reflektuje požiadavky vyhlášky 179/2020 Z. z. a bude implementované v súlade s kategorizáciou ISVS na úrovni X.“)

Postupy na zabezpečenie dôvernosti, integrity, dostupnosti (CIA)

🔻 V texte je implicitne pokryté, ale nie explicitne viazané na CIA triádu.
➡️ Odporúčame zaradiť krátku podsekciu 4.5.X Zabezpečenie CIA:

• Dôvernosť – IAM, šifrovanie, segmentácia.
• Integrita – HIDS, kontrola zmien, GitOps.
• Dostupnosť – autoscaling, HA clustre, loadbalancing, self-healing.

Pre kazdy modul a ISVS vykonat klasifikaciu alebo sem odzrkadlit danu klasifikaciu/cie v prehladnej tabulke

5. Bezpečnostný projekt – požiadavky

🔻 Chýba informácia, že bude vypracovaný samostatný Bezpečnostný projekt (ako vyžaduje § 14 vyhl. č. 179/2020 Z. z.).
 

6. Správa prístupov, roly, administrácia (chýba)

🔻 Téma prístupov je zmienená v IAM sekcii, ale chýba explicitná tabuľka alebo opis rolí ako vyžaduje šablóna.
➡️ Doplniť podsekciu 4.5.X Riadenie prístupov a roly, napríklad:

🔎 Zhrnutie:

Kapitola „5. Závislosti na ostatné ISVS / projekty“ nedodržiava štruktúru šablóny podľa požiadaviek vyhlášky a usmernení MIRRI. Aktuálny text je len všeobecné vyjadrenie zámeru a neobsahuje povinný výpočet konkrétnych závislostí, ich termínov, ani stakeholderov, čo je kritický nedostatok z pohľadu hodnotenia projektového zámeru.

• ❌ Nie je uvedený zoznam konkrétnych projektov alebo ISVS, na ktoré má projekt závislosť.
• ❌ Nie sú uvedení stakeholderi – teda OVM, ktoré majú poskytnúť súčinnosť.
• ❌ Nie sú uvedené kódy ISVS/projektov z MetaIS, ani termíny ukončenia.
• ❌ Nie je popísaný charakter závislosti – technická, procesná, legislatívna alebo kapacitná.

Aktuálne znenie kapitoly 5 je nedostatočné a nezodpovedá metodickým požiadavkám. Odporúčam kapitolu prepracovať podľa uvedenej tabuľkovej štruktúry a doplniť explicitné závislosti – najmä pri centrálnych moduloch a referenčných údajoch, ktoré sú kľúčové pre správne fungovanie celého projektu.

1. ❌ Chýba vyjadrenie k vlastníctvu zdrojového kódu:

   • Nie je nikde uvedené, že verejná správa (NASES, resp. MIRRI SR) bude výhradným vlastníkom všetkých zdrojových kódov vzniknutých v rámci projektu.
   • To je povinnosť podľa zákona č. 95/2019 Z. z. (§ 20) a podľa Metodického usmernenia o kvalite zdrojových kódov (č. 024077/2023).

2. ❌ Chýba explicitné vyhlásenie, že dodaný softvér nebude vytvárať vendor lock-in:

   • V texte nie je uvedené, že softvér bude dodaný v otvorenej podobe (napr. ako buildovateľný projekt), nezávislý od proprietárnych prostredí.
   • Chýba informácia, že bude dodržaná povinnosť umožniť budúcu rozvojovú nezávislosť od konkrétneho dodávateľa.

3. ❌ Nie je uvedená licencia:

   • Projekt neuvádza, pod akou licenciou budú zdrojové kódy zverejnené.
   • Minimálny štandard podľa usmernenia je licencia EUPL v.1.2 (Európska verejná licencia) – ak ide o štátom financovaný softvér.

4. ❌ Chýba prepojenie na zmluvnú dokumentáciu (ZoD/SLA):

   • Projekt musí uviesť, že tieto požiadavky budú súčasťou zmluvy a že odovzdanie zdrojových kódov bude viazané na míľniky a fakturáciu.

5. ⚠️ Nie je uvedený spôsob archivácie a technického prebratia (formálne odovzdanie):

   • Chýba opis, ako bude prebiehať odovzdanie, potvrdenie o odovzdaní, verifikačný build, alebo overenie nasaditeľnosti a dokumentácie.

V kontexte historickej skúsenosti so systémom Slovensko.sk, kde nejasné vlastníctvo zdrojového kódu a zmluvné nastavenie so súkromným dodávateľom viedli k praktickému vendor lock-inu, je absolútne neakceptovateľné, že v tomto projekte nie je explicitne deklarované vlastníctvo zdrojových kódov zo strany štátu, ani zadefinovaný režim ich právneho, licenčného a zmluvného zabezpečenia.

Po medializovaných pochybeniach a reputačnom riziku, ktoré poškodzujú dôveryhodnosť štátu v oblasti eGovernmentu, bolo možné očakávať, že vlastníctvo, otvorenosť a dostupnosť zdrojových kódov sa stanú prioritou a základným princípom každého nového IT projektu verejnej správy. Namiesto toho je v tejto kapitole len technický opis vývojových postupov bez právne záväzných vyjadrení o:

• výhradnom vlastníctve MIRRI SR alebo NASES ku všetkým kódom vytvoreným z verejných zdrojov,
• licenčnom režime (napr. EUPL),
• mechanizmoch kontroly a vymáhateľnosti,
• ochrane proti vendor lock-inu,
• previazaní dodania kódu na fakturačné míľniky a zmluvy o dielo.

⚠️ Ide o závažné opomenutie, ktoré môže mať dlhodobé dopady na udržateľnosť riešenia a schopnosť štátu samostatne spravovať a rozvíjať tento centrálny systém.

💡 Odporúčanie:
Je nevyhnutné kapitolu zásadne doplniť o vlastnícke, zmluvné a licenčné ustanovenia v súlade so zákonom č. 95/2019 Z. z. a metodikou MIRRI. V opačnom prípade hrozí, že sa štát opäť vystaví riziku opakovania chýb, ktoré projekt Slovensko.sk učinili symbolom zlyhania IT vo verejnej správe.

Prosím o jednoznačnú deklaráciu, či je závislosť na ostatné ISVS/projekty a vymenovať predmetné ISVS/projekty.

Prosím o deklaráciu v zmysle legislatívy, že  v projekte sú stanovené požiadavky na zdrojové kódy, spôsob ich preberania a spôsob archivácie. Navrhované riešenie je v súlade so zákonom  95/2019 Z.z. o o informačných technológiách vo verejnej správe, § 15, odsek (2) bod d)  EUPL a zabránenie vendor – lock a vyhláškou 78/2020 Z.z. o štandardoch pre informačné technológie verejnej správy, § 31 Centrálny repozitár zdrojových kódov
Zdrojové kódy vytvorené počas projektu sa budú zverejňovať v zmysle § 31 vyhlášky č. 78/2020 Z. z. o štandardoch pre informačné technológie verejnej správy v nadväznosti na § 15 ods. 2 písm. d) prvý bod zákona č. 95/2019 Z. z. o informačných technológiách vo verejnej správe a o zmene a doplnení niektorých zákonov buď  pre verejnosť bez obmedzenia (podľa § 31 ods. 4 písm. a) vyhlášky) alebo s obmedzenou dostupnosťou iba pre orgán vedenia a orgány riadenia (podľa § 31 ods. 4 písm. b) vyhlášky) spolu s odôvodnením v závislosti od jeho charakteru a posúdenia z hľadiska bezpečnosti a súvisiacich okolností.

Konkrétne v zmysle § 15 ods. 2 písm. d) zákona č. 95/2019 Z. z. informačných technológiách vo verejnej správe: 
Vo fáze prípravy a obstarania projektu je správca povinný akceptovať také zmluvné podmienky, podľa ktorých: 
1.    zdrojový kód vytvorený počas projektu bude otvorený v súlade s licenčnými podmienkami verejnej softvérovej licencie Európskej únie podľa osobitného predpisu, a to v rozsahu, v akom zverejnenie tohto kódu nemôže byť zneužité na činnosť smerujúcu k narušeniu alebo k zničeniu informačného systému verejnej správy,
2.    je jediným a výhradným disponentom so všetkými informáciami zhromaždenými alebo získanými počas projektu a prevádzky projektom vytvoreného riešenia vrátane jeho zmien a servisu a
3.    pri zmene dodávateľa pôvodný dodávateľ poskytne správcovi úplnú súčinnosť pri prechode na nového dodávateľa, najmä v oblasti architektúry a integrácie informačných systémov. 
 

Kapitola 4.1.1 je Prehlad koncovych sluzieb. Stotoznovaci modul je koncova sluzba? Plati aj pre dalsie, ako suvisi eForm dizajner s prehladom koncovych sluzieb?

Ako si obcan vsimne zmenu na aplikacnej vrstve? Obcan vnima biznis a front end. Preco ma obcanovi zalezat na aktualizacii komponentu UPVS? V com konkretne spocivaju tieto zmeny pre obcana?

Z akeho dovodu su vytvarane samostatne prilohy pre jednoduche tabulky sablony? 

Prave z tohto dovodu je cela kapitola biznis architektury vnimana ako prilis technicka, matuca a nezohladnujuca koncoveho pouzivatela, procesy a pod.

Vzhladom na rozsah predkladaneho projektu a genezu sucasneho stavu vyplyvajucu z rozvoja UPVS viacerymi projektami povazujem za nutne vsetky sucasne stavy (aj ak bez zmeny) popisat.

Z textacie vobec nie je jasne, ci projekt je alebo nie je zavisly na inych projektoch. Vzhladom na stanovene KPI predpokladam, ze je zavisly od jednotlivych projektov zivotnych situacii

Projekt je typu waterfall, perco sa pozaduje Scrum Master co je pozicia Agilneho projektoveho riadenia? 

Dekompozicia vystupov hlavneho produktu, hlavny produkt nie je dokumentacia

Tieto sluzby su v ramci verejnej casti vladneho cloudu dostupne takmer ihned, bolo navrhovane, bolo navrhovane, ze pre urychlenie implementeacie, adopsie, testovanie je mozne pouzit tieto technologie kedykolvek to je potrebne. 

Tieto sluzby su v ramci verejnej casti vladneho cloudu dostupne takmer ihned, bolo navrhovane, bolo navrhovane, ze pre urychlenie implementeacie, adopsie, testovanie je mozne pouzit tieto technologie kedykolvek to je potrebne. 

Keďže je platforma prioritne rozvíjaná za účelom riešenia konkrétnych životných situácií, je nevyhnutné, aby boli výkonnostné a kapacitné požiadavky rozčlenené podľa jednotlivých životných situácií a systémov, ktorých sa týkajú. Každá z implementovaných životných situácií by mala mať spracovanú analytickú dokumentáciu vrátane procesnej mapy, ktorá identifikuje zapojené interné a externé systémy a ich interakcie.

Tieto analýzy je potrebné predložiť ako prílohu k tejto časti dokumentácie a jednotlivé kapacitné parametre (napr. počet používateľov, transakčná záťaž, sieťová prevádzka) rozbiť na úroveň životných situácií a zapojených systémov. Len tak je možné tieto dáta zmysluplne vyhodnocovať a využiť ich pri návrhu architektúry, dimenzovaní infraštruktúry a zabezpečení výkonnostných cieľov.

Zároveň odporúčame zohľadniť, že nie všetky životné situácie majú rovnaký dopad na infraštruktúru – niektoré budú transakčne náročnejšie, iné zasa vyžadujú vyššiu dostupnosť alebo rýchlosť odozvy. Bez tejto granularizácie nie je možné relevantne posúdiť požiadavky na prevádzku a škálovanie systému.

V uvedenej tabuľke absentuje údaj o počte interných používateľov z radov orgánov verejnej moci (OVM), hoci platforma má byť poskytovaná aj im ako koncovým používateľom. Uvádzajú sa výlučne interní používatelia z NASES, čo je z hľadiska rozsahu projektu a jeho cieľového publika nedostatočné a nezodpovedá predpokladanému využitiu platformy.

Počet interných používateľov z OVM je potrebné samostatne kvantifikovať a doplniť – vrátane odhadu súčasne aktívnych používateľov v špičke. Bez týchto údajov nie je možné korektne dimenzovať prevádzkové prostredie a správne určiť nároky na výkonnosť, škálovateľnosť a dostupnosť služby. Tento nedostatok považujeme za závažný a je potrebné ho bezpodmienečne doplniť.

Uvedené hodnoty externých používateľov vychádzajú výhradne zo súčasného počtu aktívnych schránok fyzických osôb, právnických osôb a orgánov verejnej moci podľa údajov z portálu data.slovensko.sk. Tento prístup považujeme za metodicky nesprávny a z pohľadu dlhodobej udržateľnosti a strategických cieľov projektu za neakceptovateľný.

Platforma je budovaná s cieľom zjednodušiť riešenie životných situácií, podporiť digitalizáciu verejnej správy a zvýšiť mieru jej využívania zo strany občanov aj podnikateľov. Predpokladá sa zvyšovanie digitalizačného indexu Slovenska a aktívne opatrenia na stimuláciu používania digitálnych služieb. Z tohto dôvodu je neprijateľné plánovať výkonnostné a kapacitné parametre len na základe súčasného stavu (AS-IS), bez zohľadnenia očakávaného rastu používateľskej základne v priebehu životného cyklu platformy.

Žiadame preto doplniť realistické predikcie očakávaného nárastu externých používateľov (FO, PO, OVM) v horizonte minimálne 5 až 10 rokov a na základe nich aktualizovať požiadavky na výkon, škálovateľnosť a dimenzovanie infraštruktúry. V opačnom prípade hrozí, že platforma nebude schopná zvládnuť reálnu záťaž v strednodobom horizonte, čo by zásadne ohrozilo naplnenie jej cieľov a efektívnosť investovaných prostriedkov.

Uvedené hodnoty externých používateľov vychádzajú výhradne zo súčasného počtu aktívnych schránok fyzických osôb, právnických osôb a orgánov verejnej moci podľa údajov z portálu data.slovensko.sk. Tento prístup považujeme za metodicky nesprávny a z pohľadu dlhodobej udržateľnosti a strategických cieľov projektu za neakceptovateľný.

Platforma je budovaná s cieľom zjednodušiť riešenie životných situácií, podporiť digitalizáciu verejnej správy a zvýšiť mieru jej využívania zo strany občanov aj podnikateľov. Predpokladá sa zvyšovanie digitalizačného indexu Slovenska a aktívne opatrenia na stimuláciu používania digitálnych služieb. Z tohto dôvodu je neprijateľné plánovať výkonnostné a kapacitné parametre len na základe súčasného stavu (AS-IS), bez zohľadnenia očakávaného rastu používateľskej základne v priebehu životného cyklu platformy.

Žiadame preto doplniť realistické predikcie očakávaného nárastu externých používateľov (FO, PO, OVM) v horizonte minimálne 5 až 10 rokov a na základe nich aktualizovať požiadavky na výkon, škálovateľnosť a dimenzovanie infraštruktúry. V opačnom prípade hrozí, že platforma nebude schopná zvládnuť reálnu záťaž v strednodobom horizonte, čo by zásadne ohrozilo naplnenie jej cieľov a efektívnosť investovaných prostriedkov.

Preco len pre release 1, neprebehol uz nahodou release 1 v momente hodnotenia tejto dokumentacie? 

Vzhľadom na závažné nedostatky v oblasti biznis analýzy a návrhu architektúry životných situácií (vrátane chýbajúcej procesnej granularizácie, nevyhodnotených integračných väzieb a neadresovaného rastu používateľskej základne) nie je v súčasnom stave možné zmysluplne posudzovať ani hodnotiť aplikačnú architektúru.

Bez jasne definovaného biznis kontextu, požiadaviek a prepojení na jednotlivé systémy, nie je aplikačná vrstva ničím viac než technickým rámcom bez väzby na reálne potreby cieľových skupín. Odporúčame túto časť pozastaviť a jej ďalšie spracovanie viazať až na odstránenie zásadných nedostatkov v biznis analýze a architektonickom návrhu riešenia.

Do tohto momentu považujeme akékoľvek ďalšie úvahy o technickej architektúre za predčasné a metodicky nevhodné.