Merateľné ukazovatele vychádzajú z podmienok výzvy, konkrétne bod 2 Podmienka splnenie kritérií pre výber projektov, časť B, odsek b) a sú definované v prílohe výzvy č. 4 „Priloha_4_Meratelne ukazovatele a_ine_udaje.pdf“ a tie sú definované ako povinné na splnenie vylučujúceho kritéria č. 3. Ak by boli uvedené aj iné, nebude ich v rámci ITMS21 možné zadať do ŽoNFP. Uvedené bolo doplnené k popisu kapitoly 3.5 Merateľné ukazovatele (KPI).
Predpokladáme prípravy na VO ešte pred podpisom Zmluvy o NFP, ešte počas ŽoNFP, v zmluve o dodávke bude odkladacia podmienka o účinnosti zmluvy až po podpise Zmluvy o NFP. Avšak pre istotu predlžujeme dobu na 6 mesiacov. Infpormácia dopnená do poznámky pre nákup HW.
V zmysle riadenia projektov vychádzajúc z vyhlášky je potrebné zabezpečiť zástupcov kľúčových používateľov a v rámci tohto druhu projektu to môže byť práve MKB. Rola bude ale predmetom nominácie, kde sa predpokladá navrhnutie práve MKB. Info doplnené do tabuľky, stĺpec pozícia.
Vymenovaný projektový tím sa skladá z rolí, ktoré môžu byť obsadené rôznymi osobami s rôznou pracovnou pozíciou, v rámci návrhu je uvedená v zmysle podmienky výzvy projektová rola „Odborný zamestnanec IT“, ktorú je možné obsadiť systémovým, sieťovým alebo DB administrátorom prípadne inou IT expertnou pozíciou. Projektový tím je v zmysle vyhlášky, ktorá z časti vychádza z metodiky PRINCE 2 len dočasnou organizačnou štruktúrou a v rámci nej sa členovia tímu budú zodpovedať Tím manažérovi s rolou Manažér kybernetickej a informačnej bezpečnosti a Tím manažér sa zodpovedá roly Projektový manažér. Následne projektový manažér sa bude zodpovedať Riadiacemu výboru. Uvedené doplnené do popisu pod tabuľku projektového tímu.
Žiadateľ v rámci projektu plánuje zabezpečiť: Implementáciu nástrojov pre zavedenie viacfaktorovej autentifikácie – Aktivita Bezpečnosť siete a XDR, kde sa plánuje zavedenie dvojfaktorovej (2FA) autentifikácie pre VPN prístup". Zabezpečiť 2FA voči čomu ? VPN prístup kam ?
Uvedená podkapitola 3.2.3 predstavuje len zhrnutie vykonávaných aktivít a ich mapovanie, ktoré sú definované a podrobnejšie popísané v podkapitole 3.2.1. Zhrnutie vychádza a je v súlade s podmienkami výzvy, konkrétne bod 2 Podmienka splnenie kritérií pre výber projektov, časť B, odsek e), uvedené v prílohe č. 8 Výzvy „Minimálne náležitosti manažérskych produktov“. Pre odstránenie nejasností doplníme bližší popis ohľadom VPN prístupov a využitia 2FA, ako aj iné.
Z dokumentácie je jasné, že ide o obnovu infraštruktúry HW/SW (rozpočet z Excelu I_02), ale nie je jasné na čo konkrétne chcete použiť niektoré HW prvky (licencie) a to vzhľadom na všeobecný popis v projektovom zámere. Napr. koľko zariadení má slúžiť ako záloha v prípade výpadku.
Po technickej stránke je uvedené nedostatočne popísané, v podstate všeobecný popis. Je to správne z hľadiska projektu ? Prípadne by bolo vhodné, ak to je možné zapracovať viacej miery detailu k opisu technickej stránky.
Kapitola 3.2.2Súlad projektu predstavuje súhrn opatrení, ktoré sú detailnejšie vysvetlené napr. v kapitole 3.2.1 a jedná sa o zhrnutie k akým opatreniam a cieľom PSK a NKIVS projekt prispieva. Uvedené je v zmysle výzvy povinné, keďže predpisuje konkrétny špecifický cieľ a opatrenie a pre naplnenie súladu s podmienkami výzvy, konkrétne bod 2 Podmienka splnenie kritérií pre výber projektov – vylučujúce kritéria (nie bodovacie), uvedené v prílohe č. 8 Výzvy „Minimálne náležitosti manažérskych produktov“ a zároveň pre preukázanie súladu podmienky výzvy č. 3 Podmienka oprávnenosti aktivít projektu, konkrétne súlad s predpísaným typom akcie a hlavnej aktivity. Uvedené je potrebné uvádzať v projektovom zámere ako aj priamo v ŽoNFP. Informácia doplnená aj do popsiu kapitoly 3.2.2.
V zmysle šablóny PZ Niektoré (nie všetky) kritériá môžu byť označené ako KO kritériá. KO kritériá označujú biznis požiadavky na riešenie, ktoré sú z hľadiska rozsahu identifikovaného problému a motivácie nevyhnutné pre riešenie problému a všetky akceptovateľné alternatívy ich tak musia naplniť.
Pracovné dni predstavujú konzervatívny prístup k odhadu, kde vstupujú krátke útoky v hodinách ako napr. DDoS až po rozsiahlejšie ako Ransomware kde sa zotavenie z útoku pohybuje od niekoľkých dní až po niekoľko mesiacov. Priemerne v zmysle štatistík napr. (https://www.cigent.com/blog/ransomware-and-recovery-time-what-you-should-expect) sa uvádza priemerná hodnota 21 dní. Pre potreby preukázania prínosov ktoré sú založené čisto len na čase a základnej škode, ktorá nepočíta napríklad úradom digitalizované diela v hodnotách v desiatkach až stovkách miliónov, nám postačuje hodnota 3 dni, pri už ktorej je vidieť dlhodobý význam projektu.
V CBA z dna 21.1.25 nie su v Katalogu poziadaviek stlpce I a J vyplnene. Znamena to, ze funkcne poziadavky nevstupuju do investicnych nakladov projektu? Pokial je to zamerne, je to nestandardne, ale akceptujeme, vyzadujeme vsak potvrdenie.
Stĺpce boli doplnené, avšak na výpočet odhadovaných nákladov nevyužívame UCP analýzu ale PHZ, z ktorej vyšli priamo ceny jednotlivých implementačných a konfiguračných prác. Vysvetlenie bolo doplnené aj do dokumentu v kapitole 7.1.
V zmysle legislatívnych požiadaviek by každý projekt/veľký projekt mal byť realizovaný inkrementálne. Prosíme o doplnenie zdôvodnenia, prečo to v tomto prípade nie je možné resp. o rozdelenie projektu na inkrementy
V rámci vyhlášky 401/2023 (https://www.slov-lex.sk/ezbierky-fe/pravne-predpisy/SK/ZZ/2023/401/#paragraf-4.odsek-5.pismeno-b) sa uvádza, že „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“ kde z charakteru projektu, kde sa neplánuje štandardne vývoj softvéru ale jedná sa o nákup HW a licencovaného a OS softvéru by rozdelení spôsobovalo problémy pri samotnej implementácii, kedy sa jedná o osadenie a konfiguráciu HW, ktorá môže prebiehať súbežne v dohodnutých časoch odstávok a vzájomne sa nijako neovplyvňuje. Nasadenie zálohovania sa neovplyvňuje s implementáciou nových FW a bolo by kontraproduktívne takto rozdeľovať infraštruktúrne úpravy. Samozrejme je dôležité aby sa nevykonávali všetky kritické zmeny v tom istom čase ale v logickom slede, ale nie až vždy po úplnom ukončení nejakej aktivity v rámci iného inkrementu. Vysvetlenie doplnené pod sumarizáciu nákladov a prínosov.
v CBA na karte TCO uvádzate, že v t1 nakupujete hardware ale prevádzka bude až v roku t3. Prosim o objasnenie, čo bude v roku t2? Prečo už nebude HW v prevádzke v t2?
Pre vylúčenie pochybností o prínosoch počas t2, kedy bude ešte prebiehať projekt a jeho záverečné fázy sme hodnoty prínosov pôvodne zahrnuli až od roku t3. Vzhľadom na otázku sme sa rozhodli a prehodnotili prístup a to najmä na fakt, že HW bude obstaraný a implementačná fáza skončí do končí v 11. mesiaci je možné celý rok t2 predpokladať, že HW a SW už bude plniť hlavnú funkčnosť. Prínosy sme v CBA a vo vyhodnotení upravili od t2.
V komentari sme adresovali otázku prevádzkovych vydavkov, nie prinosov. V roku T1 obstaravate HW a licencie, T2 je z pohladu investicie bez nakladov a prevadzkove vydavky su planovane az od T3. Predpokladame, ze SW licencie a HW kupujete ako bundle vratane minimalnej podpory po dobu T2 a realne za prevadzku zacnete platit az od T3. Prosime odpoved zapracovat aj do projektovej dokumentacie, nie len do komentara.
Náklady na obstaranie a prevádzku aktualizujeme na základe vykonanej PHZ. V rámci nej sa na všetok obstarávaný HW a SW vyžaduje 3 ročná podpora. Náklady na prevádzku tak započítavame až od t4, vzhľadom na plán implementácie všetkého HW a SW v t1. Uvedené doplnené a jdo dokumentu v kapitole 7.1.
KPI sa javia až príliš zjednodušené. Je to tak správne?
Merateľné ukazovatele vychádzajú z podmienok výzvy, konkrétne bod 2 Podmienka splnenie kritérií pre výber projektov, časť B, odsek b) a sú definované v prílohe výzvy č. 4 „Priloha_4_Meratelne ukazovatele a_ine_udaje.pdf“ a tie sú definované ako povinné na splnenie vylučujúceho kritéria č. 3. Ak by boli uvedené aj iné, nebude ich v rámci ITMS21 možné zadať do ŽoNFP. Uvedené bolo doplnené k popisu kapitoly 3.5 Merateľné ukazovatele (KPI).
Nákup technických prostriedkov je na 3 mesiace, keďže to zahŕňa aj VO, tak je to dosť krátky časový interval.
Predpokladáme prípravy na VO ešte pred podpisom Zmluvy o NFP, ešte počas ŽoNFP, v zmluve o dodávke bude odkladacia podmienka o účinnosti zmluvy až po podpise Zmluvy o NFP. Avšak pre istotu predlžujeme dobu na 6 mesiacov. Infpormácia dopnená do poznámky pre nákup HW.
Manažér kybernetickej bezpečnosti nie je zahrnutý v riadiacom výbore (9). Je to správne?
V zmysle riadenia projektov vychádzajúc z vyhlášky je potrebné zabezpečiť zástupcov kľúčových používateľov a v rámci tohto druhu projektu to môže byť práve MKB. Rola bude ale predmetom nominácie, kde sa predpokladá navrhnutie práve MKB. Info doplnené do tabuľky, stĺpec pozícia.
V projekte nie je žiaden sieťový špecialista/architekt, pričom projekt na to je priamo zameraný.
Nie sú popísané vzájomné vzťahy v rámci projektového tímu, teda kto pod koho spadá (9).
Vymenovaný projektový tím sa skladá z rolí, ktoré môžu byť obsadené rôznymi osobami s rôznou pracovnou pozíciou, v rámci návrhu je uvedená v zmysle podmienky výzvy projektová rola „Odborný zamestnanec IT“, ktorú je možné obsadiť systémovým, sieťovým alebo DB administrátorom prípadne inou IT expertnou pozíciou. Projektový tím je v zmysle vyhlášky, ktorá z časti vychádza z metodiky PRINCE 2 len dočasnou organizačnou štruktúrou a v rámci nej sa členovia tímu budú zodpovedať Tím manažérovi s rolou Manažér kybernetickej a informačnej bezpečnosti a Tím manažér sa zodpovedá roly Projektový manažér. Následne projektový manažér sa bude zodpovedať Riadiacemu výboru. Uvedené doplnené do popisu pod tabuľku projektového tímu.
Žiadateľ v rámci projektu plánuje zabezpečiť: Implementáciu nástrojov pre zavedenie viacfaktorovej autentifikácie – Aktivita Bezpečnosť siete a XDR, kde sa plánuje zavedenie dvojfaktorovej (2FA) autentifikácie pre VPN prístup". Zabezpečiť 2FA voči čomu ? VPN prístup kam ?
Uvedená podkapitola 3.2.3 predstavuje len zhrnutie vykonávaných aktivít a ich mapovanie, ktoré sú definované a podrobnejšie popísané v podkapitole 3.2.1. Zhrnutie vychádza a je v súlade s podmienkami výzvy, konkrétne bod 2 Podmienka splnenie kritérií pre výber projektov, časť B, odsek e), uvedené v prílohe č. 8 Výzvy „Minimálne náležitosti manažérskych produktov“. Pre odstránenie nejasností doplníme bližší popis ohľadom VPN prístupov a využitia 2FA, ako aj iné.
Podpora prevádzky (SLA) nemá definovaný rozsah, len začiatok.
Ďakujeme za upozornenie, SLA doplníme na min 5 rokov v zmysle podmienok výzvy.
Z dokumentácie je jasné, že ide o obnovu infraštruktúry HW/SW (rozpočet z Excelu I_02), ale nie je jasné na čo konkrétne chcete použiť niektoré HW prvky (licencie) a to vzhľadom na všeobecný popis v projektovom zámere. Napr. koľko zariadení má slúžiť ako záloha v prípade výpadku.
V rámci kapitoly 3.2.1 boli doplnené bližšie slovné popisy využitia HW a licencií.
Po technickej stránke je uvedené nedostatočne popísané, v podstate všeobecný popis. Je to správne z hľadiska projektu ? Prípadne by bolo vhodné, ak to je možné zapracovať viacej miery detailu k opisu technickej stránky.
Kapitola 3.2.2Súlad projektu predstavuje súhrn opatrení, ktoré sú detailnejšie vysvetlené napr. v kapitole 3.2.1 a jedná sa o zhrnutie k akým opatreniam a cieľom PSK a NKIVS projekt prispieva. Uvedené je v zmysle výzvy povinné, keďže predpisuje konkrétny špecifický cieľ a opatrenie a pre naplnenie súladu s podmienkami výzvy, konkrétne bod 2 Podmienka splnenie kritérií pre výber projektov – vylučujúce kritéria (nie bodovacie), uvedené v prílohe č. 8 Výzvy „Minimálne náležitosti manažérskych produktov“ a zároveň pre preukázanie súladu podmienky výzvy č. 3 Podmienka oprávnenosti aktivít projektu, konkrétne súlad s predpísaným typom akcie a hlavnej aktivity. Uvedené je potrebné uvádzať v projektovom zámere ako aj priamo v ŽoNFP. Informácia doplnená aj do popsiu kapitoly 3.2.2.
V CBA uvádzate len funkčné požiadavky, prosíme zosúladiť.
Ďakujeme za upozornenie, doplnená informácia o ich možnom využití v úvodnej fáze realizácie projektu.
prosime o doplnenie výhod a nevyhod pri všetkých alternatívach a ich vyhodnotenie
Výhody boli doplnené v rámci popisu alternatív.
V zmysle šablóny PZ Niektoré (nie všetky) kritériá môžu byť označené ako KO kritériá. KO kritériá označujú biznis požiadavky na riešenie, ktoré sú z hľadiska rozsahu identifikovaného problému a motivácie nevyhnutné pre riešenie problému a všetky akceptovateľné alternatívy ich tak musia naplniť.
kritéria sa javia ako simplexné a všeobecné.
Boli doplnené a vyhodnotené ďalšie kritériá.
Alternatíva 1 ma 2x NIE vo vyhodnotení.
Ďakujeme za upozornenie, jedná sa o chybu, opravené na správnu alternatívu.
V CBA na karte Faktory, A21 uvádzate vypadok systému 3 pracovné dni, prečo uvádzate práve len 3 dni? Výpadok može trvať len niekoľko hodín.
Pracovné dni predstavujú konzervatívny prístup k odhadu, kde vstupujú krátke útoky v hodinách ako napr. DDoS až po rozsiahlejšie ako Ransomware kde sa zotavenie z útoku pohybuje od niekoľkých dní až po niekoľko mesiacov. Priemerne v zmysle štatistík napr. (https://www.cigent.com/blog/ransomware-and-recovery-time-what-you-should-expect) sa uvádza priemerná hodnota 21 dní. Pre potreby preukázania prínosov ktoré sú založené čisto len na čase a základnej škode, ktorá nepočíta napríklad úradom digitalizované diela v hodnotách v desiatkach až stovkách miliónov, nám postačuje hodnota 3 dni, pri už ktorej je vidieť dlhodobý význam projektu.
V CBA na karte katalóg požiadaviek nie su vyplnené stplce F, G, H a ďalej. Ziadame o doplnenie.
Ďakujeme za upozornenie, informácie boli doplnené.
V CBA z dna 21.1.25 nie su v Katalogu poziadaviek stlpce I a J vyplnene. Znamena to, ze funkcne poziadavky nevstupuju do investicnych nakladov projektu? Pokial je to zamerne, je to nestandardne, ale akceptujeme, vyzadujeme vsak potvrdenie.
Stĺpce boli doplnené, avšak na výpočet odhadovaných nákladov nevyužívame UCP analýzu ale PHZ, z ktorej vyšli priamo ceny jednotlivých implementačných a konfiguračných prác. Vysvetlenie bolo doplnené aj do dokumentu v kapitole 7.1.
V zmysle legislatívnych požiadaviek by každý projekt/veľký projekt mal byť realizovaný inkrementálne. Prosíme o doplnenie zdôvodnenia, prečo to v tomto prípade nie je možné resp. o rozdelenie projektu na inkrementy
V rámci vyhlášky 401/2023 (https://www.slov-lex.sk/ezbierky-fe/pravne-predpisy/SK/ZZ/2023/401/#paragraf-4.odsek-5.pismeno-b) sa uvádza, že „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“ kde z charakteru projektu, kde sa neplánuje štandardne vývoj softvéru ale jedná sa o nákup HW a licencovaného a OS softvéru by rozdelení spôsobovalo problémy pri samotnej implementácii, kedy sa jedná o osadenie a konfiguráciu HW, ktorá môže prebiehať súbežne v dohodnutých časoch odstávok a vzájomne sa nijako neovplyvňuje. Nasadenie zálohovania sa neovplyvňuje s implementáciou nových FW a bolo by kontraproduktívne takto rozdeľovať infraštruktúrne úpravy. Samozrejme je dôležité aby sa nevykonávali všetky kritické zmeny v tom istom čase ale v logickom slede, ale nie až vždy po úplnom ukončení nejakej aktivity v rámci iného inkrementu. Vysvetlenie doplnené pod sumarizáciu nákladov a prínosov.
v CBA na Karte Rozpočet HW a licencie v bunke A22 nemáte uvedený Modul
Ďakujeme za upozornenie, modul sme doplnili.
v CBA na karte TCO uvádzate, že v t1 nakupujete hardware ale prevádzka bude až v roku t3. Prosim o objasnenie, čo bude v roku t2? Prečo už nebude HW v prevádzke v t2?
Pre vylúčenie pochybností o prínosoch počas t2, kedy bude ešte prebiehať projekt a jeho záverečné fázy sme hodnoty prínosov pôvodne zahrnuli až od roku t3. Vzhľadom na otázku sme sa rozhodli a prehodnotili prístup a to najmä na fakt, že HW bude obstaraný a implementačná fáza skončí do končí v 11. mesiaci je možné celý rok t2 predpokladať, že HW a SW už bude plniť hlavnú funkčnosť. Prínosy sme v CBA a vo vyhodnotení upravili od t2.
V komentari sme adresovali otázku prevádzkovych vydavkov, nie prinosov. V roku T1 obstaravate HW a licencie, T2 je z pohladu investicie bez nakladov a prevadzkove vydavky su planovane az od T3. Predpokladame, ze SW licencie a HW kupujete ako bundle vratane minimalnej podpory po dobu T2 a realne za prevadzku zacnete platit az od T3. Prosime odpoved zapracovat aj do projektovej dokumentacie, nie len do komentara.
Náklady na obstaranie a prevádzku aktualizujeme na základe vykonanej PHZ. V rámci nej sa na všetok obstarávaný HW a SW vyžaduje 3 ročná podpora. Náklady na prevádzku tak započítavame až od t4, vzhľadom na plán implementácie všetkého HW a SW v t1. Uvedené doplnené a jdo dokumentu v kapitole 7.1.
v CBA Karta zdroje financovania sa javi ako nespravne vyplnená. Zdroje financovania je správne vyplnená? Rozpočtové opatrenie ?
Ďakujeme, karta bola doplnená.
Ďakujeme za všeobecny popis a prosime o doplnenie motivacie a rozsahu konkretne za MK SR.
Doplnená motivácia v súlade s motivačným diagramom a s prepojením na aktivity projektu.
projektový tím zosúladiť s CBA
Projektový tím bol zosúladený s CBA.