agendy VS a SS majú presné určené pravidla a požiadavky čo majú robiť. spojenie indetifikovať trendy nie je celkom jasné čo sa tým myslí, preformulovať alebo upresniť tento pojem.
pavol_suja, 2023/05/23 09:40
Upravené.
helena_bystrianova, 2023/04/05 09:53
vysvetliť detailnejšie čo je zvyšovanie kvality života. Z textu to nie je jasné.
pavol_suja, 2023/05/23 09:40
Doplnené.
vladimir_kovac, 2023/06/14 16:50
Akceptované.
helena_bystrianova, 2023/04/05 09:55
služby štátu voči občanovi nemajú byť čo konkurencieschopné. Odstrániť tento pojem alebo detailnejšie vysvetliť čo sa tým myslelo.
helena_bystrianova, 2023/04/05 09:55
zmeniť zdroj financovania aj na karte v MET A IS
pavol_suja, 2023/05/23 09:13
Upravené.
helena_bystrianova, 2023/06/05 10:37
neupravené, ani v META IS. prosím upraviť z ktorého zdroja chcete financovať projekt.
helena_bystrianova, 2023/04/05 09:59
v časti Legislatívna uvádzate, že nie sú potrebné legislatívne zmeny a v tejto časti hovoríte o legislatívnych zmenách. Vysvetliť a zjednotiť.
pavol_suja, 2023/05/23 09:49
Upravené.
helena_bystrianova, 2023/04/05 10:00
ak je myslený Vládny Cloud , tak prosím premenovať
helena_bystrianova, 2023/04/05 10:02
v META IS je evidovaných len 12 KS. Prosím o vysvetlenie.
pavol_suja, 2023/05/23 09:18
14 KS je myslených služieb splnomocnenia 3 agendových systémov (systém 1 - systém 3)
helena_bystrianova, 2023/04/05 10:03
v texte spomínate 14 KS v META IS je 12 KS. Prosím o zosuladenie.
helena_bystrianova, 2023/04/05 10:15
ako sa dá VS inovovať ? Inovácia je skor na aplikačnej a technologickej. vrstve. tu ide o vznik nového ISVS, ktorý sa nedá ešte inovovať.
pavol_suja, 2023/05/23 10:46
Upravené.
helena_bystrianova, 2023/04/05 10:29
uvedené funkcionality, nekorešpondujú s aplikačnou architektúrou.
pavol_suja, 2023/05/23 10:50
Upravené.
helena_bystrianova, 2023/04/05 10:50
prosim doplniť alternatívu na aplikačnej vrstve.
pavol_suja, 2023/05/23 11:56
Doplnené v Prístupe k projektu.
helena_bystrianova, 2023/04/05 10:51
vymenovať minimálne a nutné moduly.
pavol_suja, 2023/05/23 11:51
Uvedené v Prístupe k projektu.
vladimir_kovac, 2023/06/14 17:09
Akceptované zapracovanie.
helena_bystrianova, 2023/04/05 12:27
prosím bližšie popísať náhľad architektúry, popísať evidencie a doplniť a popísať vzťahy v nákrese.
pavol_suja, 2023/05/23 11:57
Dopklnené.
vladimir_kovac, 2023/04/12 08:26
Podľa znenia nákona 305/2013 § 23a ods. 7 a § 23 ods. 6 a 7 by projekt centr. registra mal mať ambíciu vybudovať referenčný, nielen zdrojový register.
pavol_suja, 2023/05/23 09:12
Zapracované
vladimir_kovac, 2023/06/14 16:49
Akceptované.
vladimir_kovac, 2023/04/12 08:33
Treba lepšiu skratku, lebo to znie buď ako ČREP alebo KREP, čo znie zakaždým ako niečo menej cenné a register plnomocenstiev by taký nemal byť.
pavol_suja, 2023/05/23 08:10
Je to len skratka uvádzaná v textoch, projektovej dokumentácii a MetaIS. Nebude viditeľná pre používateľa (splnomocnenca, splnomocniteľa, OVM). Zmena skratky znamená zmenu všade v textoch každého projektového dokumentu a zároveň aj názve projektu resp. ISVS v MetaIS. Zbytočná prácnosť.
pavol_suja, 2023/05/23 12:10
Register je pomenovaný v súlade s § 23a zákona č. 305/2013 Z. z. zákon o e-Governmente a z toho vyplýva aj skratka projektu.
vladimir_kovac, 2023/06/14 16:49
Akceptované.
vladimir_kovac, 2023/04/12 08:39
Efektívnejšiu činnosť by reg. plnomocenstiev mal podporiť nielen v MVSR ale celej VS - všade, kde treba preveriť oprávnenie konať v mene inej osoby - aj na ÚPVS, v systéme moje údaje, centr. API manažment platforma, v procesoch MSSR a iných OVM.
pavol_suja, 2023/05/23 09:46
Doplnené.
vladimir_kovac, 2023/06/14 16:51
Akceptované zapracovanie.
vladimir_kovac, 2023/04/12 08:41
Predmetom projektu by malo byť zavedenie registra plnomocenstiev a nielen vyhodnotenie možností jeho zavedenia. Tak je to nakoniec uvedené aj na konci tejto kapitoly.
pavol_suja, 2023/05/23 09:48
Upravené.
vladimir_kovac, 2023/06/14 16:59
Akceptované zapracovanie.
vladimir_kovac, 2023/04/12 08:44
MIRRI + NASES
pavol_suja, 2023/05/23 09:39
Upravené.
vladimir_kovac, 2023/06/14 16:59
Akceptované zapracovanie.
vladimir_kovac, 2023/04/12 08:45
Správca a prevádzkovateľ spoločných modulov.
pavol_suja, 2023/05/23 09:39
Upravené.
vladimir_kovac, 2023/04/12 08:52
Služby a dáta z registra plnomocenstiev by mali byť sprístupnené buď cez CSRÚ (isvs_5836) alebo CAMP ( isvs_9513). Podľa detailnej analýzy, ktorý systém bude podľa charakteru služieb vhodnejší. Aj systém Manažment Mojich údajov (MOU - isvs_8705) bude ptrebné integrovať a poskytnúť do MOU dáta o poskytnutých plnomocenstvách.
pavol_suja, 2023/05/23 09:39
Doplnené.
vladimir_kovac, 2023/04/12 08:57
Niektoré OVM, u ktorých sa predpokladá intenzívne využívanie alebo majú legislatívnu zodpovednosť za prácu s plnomocenstvami a osvedčovaním dokladov, napr. Notári (notárska komora) a MSSR by mali byť tiež vymenovaní a zapojení do projektu, aby boli zohľadnené aj ich požiadavky a očakávania služieb od centr. registra.
pavol_suja, 2023/05/23 09:23
Spomínané OVM sú do projektu zapojené v roli Užívateľ, pracovník agendy, vlastník procesu, vlastník dát, správca. Požiadavky na register sú definované v zmysle zákona.
vladimir_kovac, 2023/06/14 17:00
Akceptované vysvetlenie.
vladimir_kovac, 2023/04/12 09:05
Prečo by implementovaný register plnomocenstiev mal byť realizovaný ako SaaS a nie nadrezortný ISVS poskytujúci referenčné údaje o evidovaných splnomocneniach? Podľa znenia zákona 305/2013 by to mal byť nadrezortný ISVS a ref. register. Podľa akých kritérií vyhodnotil navrhovateľ projektu, že by bolo treba systém budovať ako SaaS? Bolo by to síce univerzálnejšie riešenie, ale pravdepodbne aj nákladnejšie. Kde vidí navrhovateľ už teraz potrebu vytvárania vlastných registrov splnomocnení pre potreby len príslušného orgánu a prečo by aj tie nemohli byť vedené ako záznam v centrálnom registri?
Podľa diskusie na kick-off mítingu MIRRI a MVSR k tomuto projektu 12.4.2023 je zámerom MVSR implementovať systéme, kde síce svoje služby a podmienky poskytovania splnomocnení a súhlasov k nim spravuje OVM, ale tieto služby a dáta sú súčasťou celkovej databázy registra prístupnej pre dotknuté osoby a konzumentov a nepredpokladá sa nejaké špeciálne funkčné prispôsobovanie systému pre OVM ako tenantov. Podľa týchto znakov ide skôr o ISVS typu spoločný nadrezortný ISVS a nie o spoločný aplikačný blok typu SaaS.
pavol_suja, 2023/05/23 10:02
SaaS a nadrezortný IS sa nevylučujú. SaaS je spôsob realizácie technického a biznisového riešenia. V doterajšej praxi, ak sme zavádzali splnomocnenia "šité na mieru" konkrétnej agendy, tak sa definovali vlastné služby, objekty, ich atribúty a relácie medzi objektami. Cieľom je poskytnúť riešenie, kde bude možné tieto špecifiká konfigurovať samostatne OVM a nie je nutný sprostredkovaný centrálny manažment.
vladimir_kovac, 2023/04/12 09:10
Podľa komentára k návrhu riešiť register ako SaaS by bolo potrebné doplniť aj zdôvodnenie, prečo robiť register ako SaaS a nie spoločný nadrezortný ISVS.
pavol_suja, 2023/05/23 10:49
SaaS a nadrezortný IS sa nevylučujú. SaaS je spôsob realizácie technického a biznisového riešenia. V doterajšej praxi, ak sme zavádzali splnomocnenia "šité na mieru" konkrétnej agendy, tak sa definovali vlastné služby, objekty, ich atribúty a relácie medzi objektami. Cieľom je poskytnúť riešenie, kde bude možné tieto špecifiká konfigurovať samostatne OVM a nie je nutný sprostredkovaný centrálny manažment.
vladimir_kovac, 2023/06/14 17:02
Akceptované vysvetlenie
vladimir_kovac, 2023/04/12 09:12
Rozšíriť popis o možnosť vytvoriť záznam o splnomocnení elektronicky, alebo asistovane, napr. na matrike alebo u notára.
pavol_suja, 2023/05/23 10:51
Doplnené.
vladimir_kovac, 2023/06/14 17:02
Akceptované zapracovanie.
vladimir_kovac, 2023/04/12 09:14
Ohľadne súhlasov si bude treba vyjasniť o aké súhlasy sa jedná, lebo Manažment mojich údajov rieši poskytovanie služby pre zadanie súhlasu na použitie osobných dát v službách tretích strán a aj VS. Aby sme tu nemali kompetenčný spor a duplicitu.
pavol_suja, 2023/05/23 10:51
Nie je možné vopred definovať rozsah služieb, na ktoré je možné poskytnúť súhlas. Ad absurdum aj súhlas, ktorý uvádzate by malo byť možné evidovať v IS.
vladimir_kovac, 2023/04/12 09:16
Mala by byť poskytnutá aj služba konverzie elektronickej verzie plnomocenstva na listinnú.
pavol_suja, 2023/05/23 10:56
Tu navrhujeme využiť štandardný proces zaručenej konverzie spolu so všetkými náležitosťami a neimplementovať vlastnú funkcionalitu. Konverziu môžu vykonať povinné osoby.
vladimir_kovac, 2023/04/12 09:17
Buď tu, alebo v prístupe k projektu by bolo treba rozlišovať integráciu registra splnomocnení ako konzumenta a ako poskytovateľa. Treba doplniť CSRÚ a CAMP ako sprostredkovateľov integrácie na register splnomocnení.
pavol_suja, 2023/05/23 11:26
Doplnené.
vladimir_kovac, 2023/06/14 17:03
Akceptované zapracovanie.
vladimir_kovac, 2023/04/12 09:23
Podľa zák. 305/2013 špeciálne aj podľa § 23a ods. 6 treba zabezpečiť aj integráciu a sprístupnenie formulárov pre splnomocnenia v MEF (isvs_8848) na ÚPVS.
pavol_suja, 2023/05/23 11:45
Doplnené.
vladimir_kovac, 2023/06/14 17:03
Akceptované zapracovanie.
vladimir_kovac, 2023/04/12 09:26
Naozaj treba SaaS? Nie nadrezortný ISVS?
pavol_suja, 2023/05/23 10:58
SaaS a nadrezortný IS sa nevylučujú. SaaS je spôsob realizácie technického a biznisového riešenia. V doterajšej praxi, ak sme zavádzali splnomocnenia "šité na mieru" konkrétnej agendy, tak sa definovali vlastné služby, objekty, ich atribúty a relácie medzi objektami. Cieľom je poskytnúť riešenie, kde bude možné tieto špecifiká konfigurovať samostatne OVM a nie je nutný sprostredkovaný centrálny manažment.
vladimir_kovac, 2023/06/14 17:03
Akceptované vysvetlenie.
vladimir_kovac, 2023/04/12 09:42
Treba zreálniť harmonogram. Realizačná fáza určte nezačne 1.4.2023
pavol_suja, 2023/05/23 12:05
upravené.
vladimir_kovac, 2023/06/14 17:08
Harmonogram bol síce viac zreálnený, keďže realizačná fáza je už plánovaná na 9/2023 ale v texte pred harmonogramom je ešte stále nemožný neaktuálny dátum 1.4.2023. Ak má tabuľka prednosť, dá sa zapracovanie akceptovať.
helena_bystrianova, 2023/04/12 10:21
V manažérskom zhrnutí je uvedené, že budú potrebné legislatívne zmeny a v tejto časti uvádzate, že nebudú potrebné legislatívne zmeny.
pavol_suja, 2023/05/23 12:01
upravené
helena_bystrianova, 2023/04/12 11:04
Prosim per parameter v CBA( hárok parametre agentove systémy) popísať a ako boli napočítané volania. Vysvetliť co je to system 1,2,3... vzhladom k tomu, ze to nekorešponduje s architektúrou
Prosim do CBA- parametre agndové systémy vysvetliť co je interný a externy frontend+ Systém 1,2,3
pavol_suja, 2023/05/23 12:03
doplnené.
helena_bystrianova, 2023/04/12 11:07
boli vykonané merania času spracovania podania, ak áno aký počet.
pavol_suja, 2023/05/23 12:04
doplnené
helena_bystrianova, 2023/06/05 14:50
neevidujem zapracovanu odpoveď. Prosím o vyjadrenie ci boli vykonané meranie a ak áno aký počet.
helena_bystrianova, 2023/04/12 14:32
Pripomienka J.Brtková:
– navrhujem pre predposledný stĺpec uviesť kde bude vykonané nasadenie a vykonanie funkčných testov (testovanie alebo produkčné prostredie)
pavol_suja, 2023/05/23 11:06
Upravené.
helena_bystrianova, 2023/04/12 14:33
Pripomienky J. Brtková
sú tu vymenované vybrané ŽS, úseky a agendy, kedy budú služby dostupné aj pre ostatné OVM?
pavol_suja, 2023/05/23 09:46
Riešenie bude dostupné bezprostredne po nasadení do produkčnej prevádzky. Vybrané IS sú požadované, aby riešenie začalo plniť svoj cieľ a nebolo len dostupným "nástrojom".
vladimir_kovac, 2023/06/14 16:52
Akceptované vysvetlenie. Podľa nižšie uvedeného harmonogramu a obsahu projektu by to malo byť vo fázach 3c a 3d.
helena_bystrianova, 2023/04/12 14:36
Pripomienka J. Brtková
tu by bolo vhodné uviesť aké tri systémy budú integrované – myslím tým, aby neboli predmetom integrácie iba interné systéme MV SR ale aspoň jeden z nich nech je z iného OVM, inak sa nesplní podmienka overenia riešenia
pavol_suja, 2023/05/23 09:45
Konkrétne systémy budú identifikované podľa aktuálneho plánu a potrieb, IS môžu byť z ľubovoľného OVM.
helena_bystrianova, 2023/04/12 14:38
Pripomienka J.Brtková
nie je tu spomenutá funkčnosť notifikácií pričom v náhľade architektúry je
pavol_suja, 2023/05/23 10:50
Upravené.
helena_bystrianova, 2023/04/12 14:39
Pripomienky J. Brtková
prosím spomenúť tieto legislatívne požiadavky:
Referencovanie údajov na referenčné údaje
Formulár vytvára MV SR alebo ústredný orgán štátnej správy
Centrálny register elektronických plnomocenstiev je prístupný prostredníctvom ústredného portálu, a to aj automatizovaným spôsobom.
Správca centrálneho registra elektronických plnomocenstiev sprístupní elektronické formuláre elektronických plnomocenstiev bezodplatne prostredníctvom modulu elektronických formulárov.
pavol_suja, 2023/05/23 11:58
doplnené.
helena_bystrianova, 2023/04/12 14:46
vzhľadom k rozpočtu nad 5 mil Eur, je plánovaný prototyp v zmysle Vyhlášky ? prosim uviesť predmetnú info do kapitoly
pavol_suja, 2023/05/23 12:02
doplnené
helena_bystrianova, 2023/04/13 12:08
prosím doplniť používateľský prieskum v zmysle usmernenia v PZ
Definovať skupiny koncových používateľov elektronických služieb a popísať cieľové skupiny koncových používateľov, vrátane sociodemografických charakteristík cieľových skupín alebo účastníkov používateľského prieskumu. (Vytvoriť prvú “iteráciu” popisu cieľových skupín koncových používateľov, ktorá bude neskôr doplnená o poznatky z používateľského prieskumu. Príklad definície skupín koncových používateľov , tzv. persón nájdete napríklad v metodike pre tvorbu používateľsky kvalitných elektronických služiebalebo v tomto článku).
Potreby resp. ciele koncových používateľov (ideálne formou tzv. používateľského príbehu) ktoré identifikujú to, čo jednotlivé skupiny koncových používateľov od elektronickej služby požadujú (čiže ako k naplneniu potreby pristupujú popísané formou príbehu).
helena_bystrianova, 2023/04/13 12:33
prosím doplniť do rozsahu projektu aj business case ak obcan nemá aktivovaný elektronický podpis, ako bude tento problém riešený
pavol_suja, 2023/05/23 09:44
Doplnené. Možnosť podať splnomocnenie asistovane.
helena_bystrianova, 2023/06/05 10:34
asistované splnomocnenie sa nenachádza v texte, prosím doplniť
helena_bystrianova, 2023/04/14 11:21
Pripomienky BRISK:
1. uviesť do kapitoly Vyhlášku o elektronizácii agendy (UX vyhláška č. 547/2021 Z. z) a Vyhlášku o štandardoch o IDSK a postupovať d podľa nich
2. doplniť mať používateľsky prieskum + prototyp v texte: Špecifikácia potrieb koncového používateľa
pavol_suja, 2023/05/23 10:05
Doplnené. Upravené.
pavol_kopacka, 2023/04/16 11:53
Je to konečný zoznam? Životné situácie popisované v tabuľke nižšie spadajú pod iné úseky VS...
pavol_suja, 2023/05/23 09:52
Upravené.
pavol_kopacka, 2023/04/16 14:05
Prosím upresniť a doplniť ďalšie roly. Užívateľ orgánov verejnej moci nie je vhodné priradenie.
pavol_suja, 2023/05/23 09:24
Upravené
pavol_kopacka, 2023/04/16 14:07
Aktéri MCA by mali byť aktéri podľa tabuľky v časti
Zainteresované strany/Stakeholderi
pavol_suja, 2023/05/23 11:45
Upravené.
pavol_kopacka, 2023/04/16 14:09
Pri náhľade architektúry chýbajú vzťahy. Uvedený náhľad je len zoznam objektov.
pavol_suja, 2023/05/23 11:58
Upravené.
helena_bystrianova, 2023/04/17 11:45
prosím popísať ako alternatívu nákup krabicového softvéru (opensource) na riešenie celého alebo časti scoupu projektu
pavol_suja, 2023/05/23 10:47
Doplnené do Stanovenie alternatív pomocou aplikačnej vrstvy architektúry
agendy VS a SS majú presné určené pravidla a požiadavky čo majú robiť. spojenie indetifikovať trendy nie je celkom jasné čo sa tým myslí, preformulovať alebo upresniť tento pojem.
Upravené.
vysvetliť detailnejšie čo je zvyšovanie kvality života. Z textu to nie je jasné.
Doplnené.
Akceptované.
služby štátu voči občanovi nemajú byť čo konkurencieschopné. Odstrániť tento pojem alebo detailnejšie vysvetliť čo sa tým myslelo.
zmeniť zdroj financovania aj na karte v MET A IS
Upravené.
neupravené, ani v META IS. prosím upraviť z ktorého zdroja chcete financovať projekt.
v časti Legislatívna uvádzate, že nie sú potrebné legislatívne zmeny a v tejto časti hovoríte o legislatívnych zmenách. Vysvetliť a zjednotiť.
Upravené.
ak je myslený Vládny Cloud , tak prosím premenovať
v META IS je evidovaných len 12 KS. Prosím o vysvetlenie.
14 KS je myslených služieb splnomocnenia 3 agendových systémov (systém 1 - systém 3)
v texte spomínate 14 KS v META IS je 12 KS. Prosím o zosuladenie.
ako sa dá VS inovovať ? Inovácia je skor na aplikačnej a technologickej. vrstve. tu ide o vznik nového ISVS, ktorý sa nedá ešte inovovať.
Upravené.
uvedené funkcionality, nekorešpondujú s aplikačnou architektúrou.
Upravené.
prosim doplniť alternatívu na aplikačnej vrstve.
Doplnené v Prístupe k projektu.
vymenovať minimálne a nutné moduly.
Uvedené v Prístupe k projektu.
Akceptované zapracovanie.
prosím bližšie popísať náhľad architektúry, popísať evidencie a doplniť a popísať vzťahy v nákrese.
Dopklnené.
Podľa znenia nákona 305/2013 § 23a ods. 7 a § 23 ods. 6 a 7 by projekt centr. registra mal mať ambíciu vybudovať referenčný, nielen zdrojový register.
Zapracované
Akceptované.
Treba lepšiu skratku, lebo to znie buď ako ČREP alebo KREP, čo znie zakaždým ako niečo menej cenné a register plnomocenstiev by taký nemal byť.
Je to len skratka uvádzaná v textoch, projektovej dokumentácii a MetaIS. Nebude viditeľná pre používateľa (splnomocnenca, splnomocniteľa, OVM). Zmena skratky znamená zmenu všade v textoch každého projektového dokumentu a zároveň aj názve projektu resp. ISVS v MetaIS. Zbytočná prácnosť.
Register je pomenovaný v súlade s § 23a zákona č. 305/2013 Z. z. zákon o e-Governmente a z toho vyplýva aj skratka projektu.
Akceptované.
Efektívnejšiu činnosť by reg. plnomocenstiev mal podporiť nielen v MVSR ale celej VS - všade, kde treba preveriť oprávnenie konať v mene inej osoby - aj na ÚPVS, v systéme moje údaje, centr. API manažment platforma, v procesoch MSSR a iných OVM.
Doplnené.
Akceptované zapracovanie.
Predmetom projektu by malo byť zavedenie registra plnomocenstiev a nielen vyhodnotenie možností jeho zavedenia. Tak je to nakoniec uvedené aj na konci tejto kapitoly.
Upravené.
Akceptované zapracovanie.
MIRRI + NASES
Upravené.
Akceptované zapracovanie.
Správca a prevádzkovateľ spoločných modulov.
Upravené.
Služby a dáta z registra plnomocenstiev by mali byť sprístupnené buď cez CSRÚ (isvs_5836) alebo CAMP ( isvs_9513). Podľa detailnej analýzy, ktorý systém bude podľa charakteru služieb vhodnejší. Aj systém Manažment Mojich údajov (MOU - isvs_8705) bude ptrebné integrovať a poskytnúť do MOU dáta o poskytnutých plnomocenstvách.
Doplnené.
Niektoré OVM, u ktorých sa predpokladá intenzívne využívanie alebo majú legislatívnu zodpovednosť za prácu s plnomocenstvami a osvedčovaním dokladov, napr. Notári (notárska komora) a MSSR by mali byť tiež vymenovaní a zapojení do projektu, aby boli zohľadnené aj ich požiadavky a očakávania služieb od centr. registra.
Spomínané OVM sú do projektu zapojené v roli Užívateľ, pracovník agendy, vlastník procesu, vlastník dát, správca. Požiadavky na register sú definované v zmysle zákona.
Akceptované vysvetlenie.
Prečo by implementovaný register plnomocenstiev mal byť realizovaný ako SaaS a nie nadrezortný ISVS poskytujúci referenčné údaje o evidovaných splnomocneniach? Podľa znenia zákona 305/2013 by to mal byť nadrezortný ISVS a ref. register. Podľa akých kritérií vyhodnotil navrhovateľ projektu, že by bolo treba systém budovať ako SaaS? Bolo by to síce univerzálnejšie riešenie, ale pravdepodbne aj nákladnejšie. Kde vidí navrhovateľ už teraz potrebu vytvárania vlastných registrov splnomocnení pre potreby len príslušného orgánu a prečo by aj tie nemohli byť vedené ako záznam v centrálnom registri?
Podľa diskusie na kick-off mítingu MIRRI a MVSR k tomuto projektu 12.4.2023 je zámerom MVSR implementovať systéme, kde síce svoje služby a podmienky poskytovania splnomocnení a súhlasov k nim spravuje OVM, ale tieto služby a dáta sú súčasťou celkovej databázy registra prístupnej pre dotknuté osoby a konzumentov a nepredpokladá sa nejaké špeciálne funkčné prispôsobovanie systému pre OVM ako tenantov. Podľa týchto znakov ide skôr o ISVS typu spoločný nadrezortný ISVS a nie o spoločný aplikačný blok typu SaaS.
SaaS a nadrezortný IS sa nevylučujú. SaaS je spôsob realizácie technického a biznisového riešenia. V doterajšej praxi, ak sme zavádzali splnomocnenia "šité na mieru" konkrétnej agendy, tak sa definovali vlastné služby, objekty, ich atribúty a relácie medzi objektami. Cieľom je poskytnúť riešenie, kde bude možné tieto špecifiká konfigurovať samostatne OVM a nie je nutný sprostredkovaný centrálny manažment.
Podľa komentára k návrhu riešiť register ako SaaS by bolo potrebné doplniť aj zdôvodnenie, prečo robiť register ako SaaS a nie spoločný nadrezortný ISVS.
SaaS a nadrezortný IS sa nevylučujú. SaaS je spôsob realizácie technického a biznisového riešenia. V doterajšej praxi, ak sme zavádzali splnomocnenia "šité na mieru" konkrétnej agendy, tak sa definovali vlastné služby, objekty, ich atribúty a relácie medzi objektami. Cieľom je poskytnúť riešenie, kde bude možné tieto špecifiká konfigurovať samostatne OVM a nie je nutný sprostredkovaný centrálny manažment.
Akceptované vysvetlenie
Rozšíriť popis o možnosť vytvoriť záznam o splnomocnení elektronicky, alebo asistovane, napr. na matrike alebo u notára.
Doplnené.
Akceptované zapracovanie.
Ohľadne súhlasov si bude treba vyjasniť o aké súhlasy sa jedná, lebo Manažment mojich údajov rieši poskytovanie služby pre zadanie súhlasu na použitie osobných dát v službách tretích strán a aj VS. Aby sme tu nemali kompetenčný spor a duplicitu.
Nie je možné vopred definovať rozsah služieb, na ktoré je možné poskytnúť súhlas. Ad absurdum aj súhlas, ktorý uvádzate by malo byť možné evidovať v IS.
Mala by byť poskytnutá aj služba konverzie elektronickej verzie plnomocenstva na listinnú.
Tu navrhujeme využiť štandardný proces zaručenej konverzie spolu so všetkými náležitosťami a neimplementovať vlastnú funkcionalitu. Konverziu môžu vykonať povinné osoby.
Buď tu, alebo v prístupe k projektu by bolo treba rozlišovať integráciu registra splnomocnení ako konzumenta a ako poskytovateľa. Treba doplniť CSRÚ a CAMP ako sprostredkovateľov integrácie na register splnomocnení.
Doplnené.
Akceptované zapracovanie.
Podľa zák. 305/2013 špeciálne aj podľa § 23a ods. 6 treba zabezpečiť aj integráciu a sprístupnenie formulárov pre splnomocnenia v MEF (isvs_8848) na ÚPVS.
Doplnené.
Akceptované zapracovanie.
Naozaj treba SaaS? Nie nadrezortný ISVS?
SaaS a nadrezortný IS sa nevylučujú. SaaS je spôsob realizácie technického a biznisového riešenia. V doterajšej praxi, ak sme zavádzali splnomocnenia "šité na mieru" konkrétnej agendy, tak sa definovali vlastné služby, objekty, ich atribúty a relácie medzi objektami. Cieľom je poskytnúť riešenie, kde bude možné tieto špecifiká konfigurovať samostatne OVM a nie je nutný sprostredkovaný centrálny manažment.
Akceptované vysvetlenie.
Treba zreálniť harmonogram. Realizačná fáza určte nezačne 1.4.2023
upravené.
Harmonogram bol síce viac zreálnený, keďže realizačná fáza je už plánovaná na 9/2023 ale v texte pred harmonogramom je ešte stále nemožný neaktuálny dátum 1.4.2023. Ak má tabuľka prednosť, dá sa zapracovanie akceptovať.
V manažérskom zhrnutí je uvedené, že budú potrebné legislatívne zmeny a v tejto časti uvádzate, že nebudú potrebné legislatívne zmeny.
upravené
Prosim per parameter v CBA( hárok parametre agentove systémy) popísať a ako boli napočítané volania. Vysvetliť co je to system 1,2,3... vzhladom k tomu, ze to nekorešponduje s architektúrou
Prosim do CBA- parametre agndové systémy vysvetliť co je interný a externy frontend+ Systém 1,2,3
doplnené.
boli vykonané merania času spracovania podania, ak áno aký počet.
doplnené
neevidujem zapracovanu odpoveď. Prosím o vyjadrenie ci boli vykonané meranie a ak áno aký počet.
Pripomienka J.Brtková:
– navrhujem pre predposledný stĺpec uviesť kde bude vykonané nasadenie a vykonanie funkčných testov (testovanie alebo produkčné prostredie)
Upravené.
Pripomienky J. Brtková
sú tu vymenované vybrané ŽS, úseky a agendy, kedy budú služby dostupné aj pre ostatné OVM?
Riešenie bude dostupné bezprostredne po nasadení do produkčnej prevádzky. Vybrané IS sú požadované, aby riešenie začalo plniť svoj cieľ a nebolo len dostupným "nástrojom".
Akceptované vysvetlenie. Podľa nižšie uvedeného harmonogramu a obsahu projektu by to malo byť vo fázach 3c a 3d.
Pripomienka J. Brtková
tu by bolo vhodné uviesť aké tri systémy budú integrované – myslím tým, aby neboli predmetom integrácie iba interné systéme MV SR ale aspoň jeden z nich nech je z iného OVM, inak sa nesplní podmienka overenia riešenia
Konkrétne systémy budú identifikované podľa aktuálneho plánu a potrieb, IS môžu byť z ľubovoľného OVM.
Pripomienka J.Brtková
nie je tu spomenutá funkčnosť notifikácií pričom v náhľade architektúry je
Upravené.
Pripomienky J. Brtková
prosím spomenúť tieto legislatívne požiadavky:
doplnené.
vzhľadom k rozpočtu nad 5 mil Eur, je plánovaný prototyp v zmysle Vyhlášky ? prosim uviesť predmetnú info do kapitoly
doplnené
prosím doplniť používateľský prieskum v zmysle usmernenia v PZ
prosím doplniť do rozsahu projektu aj business case ak obcan nemá aktivovaný elektronický podpis, ako bude tento problém riešený
Doplnené. Možnosť podať splnomocnenie asistovane.
asistované splnomocnenie sa nenachádza v texte, prosím doplniť
Pripomienky BRISK:
1. uviesť do kapitoly Vyhlášku o elektronizácii agendy (UX vyhláška č. 547/2021 Z. z) a Vyhlášku o štandardoch o IDSK a postupovať d podľa nich
2. doplniť mať používateľsky prieskum + prototyp v texte: Špecifikácia potrieb koncového používateľa
Doplnené. Upravené.
Je to konečný zoznam? Životné situácie popisované v tabuľke nižšie spadajú pod iné úseky VS...
Upravené.
Prosím upresniť a doplniť ďalšie roly. Užívateľ orgánov verejnej moci nie je vhodné priradenie.
Upravené
Aktéri MCA by mali byť aktéri podľa tabuľky v časti
Zainteresované strany/Stakeholderi
Upravené.
Pri náhľade architektúry chýbajú vzťahy. Uvedený náhľad je len zoznam objektov.
Upravené.
prosím popísať ako alternatívu nákup krabicového softvéru (opensource) na riešenie celého alebo časti scoupu projektu
Doplnené do Stanovenie alternatív pomocou aplikačnej vrstvy architektúry