IS ROM bude konzumovať služby, ktoré nie sú vypublikované na CPDI (napr. zmenové dávky IS RFO). Prostredníctvom IS CPDI budú konzumované služby napr. UPSVaR.
MPSVaR aktuálne pripravuje nový OE obsahujúci dávky poskytované občanom, ktorý bude dostupný na IS CPDI v 4Q2025 v rámci riešenia životných situácií.
V súčasnosti má MH SR naintegrované RFO (medzi inými aj integračnú väzbu Získavanie zmenových dávok RFO), RA, RPO.
V rámci projektu sú identifikované konkrétne integrácie pre informačné systémy OVM. Projekt predpokladá získavanie (konzumovanie) údajov priamo zo zdrojových informačných systémov, nie získavanie údajov prostredníctvom IS CPDI (spoločný eGov komponent), i keď ide o údaje, ktoré je možné prostredníctvom IS CPDI získavať. Vzhľadom na uplatňovanie princípu zákazu priamych integrácií (integračný princíp MIRRI SR), Centrálna dátová kancelária nepodporuje vytváranie priamych integrácií na zdrojový informačný systém – projekt je potrebné upraviť tak, aby boli údaje získavané prostredníctvom IS CPDI (doplniť existujúce integrácie o novo konzumované objekty evidencií a integračné väzby). Priama integrácia je možná iba pri OE, ktoré na IS CPDI nie sú a neuvažuje sa v tomto období na ich doplnení. Aj pri takých uprednostňujeme integráciu na IS CPDI, nakoľko sa v budúcnosti môžu stať predmetom konzumovania inými OVM.
V tejto súvislosti je treba zdôrazniť povinnosť OVM poskytovať údaje prostredníctvom IS CPDI uloženú § 12 ods. 1 písm l) 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.
IS ROM bude konzumovať služby, ktoré nie sú vypublikované na CPDI (napr. zmenové dávky IS RFO). Prostredníctvom IS CPDI budú konzumované služby napr. UPSVaR.
Metaúdaje k datasetom je potrebné katalogizovať na portáli otvorených dát data.slovensko.sk podľa aktuálneho metaúdajového štandardu DCAT AP-SK/resp. zároveň ku projektu vytvoriť lokálny katalóg otvorených dát, resp. OpenApi a tú/ten zaregistrovať na portál data.slovensko.sk
Dáta je potrebné v rámci dátovej kvality stotožňovať a referencovať voči referenčným registrom, používať identifikátori ako IČO, identifikátor adresy, resp. fyzickej osoby, zaviesť biznis pravidlá/metodiku ku dátovej kvalite, obmedzenia pre dáta (hodnoty, formáty, rozsahy...) keďže sa plánuje zlučovanie dát z rôznych registrov a IS
koľkým subjektom sa budú údaje poskytovať, resp. ak je to cieľ, nie je vhodné na to vytvoriť KPI napr. počet subjektov, ktorým sú poskytované anonymizované údaje?
podľa informácií v projekte sú v projekte aj elektronické služby pre občana. Podľa § 8 vyhlášky 401/2023 Z. z. je potrebné zrealizovať používateľský prieskum už v prípravnej a iniciačnej fáze a spracovať z neho výsledky v projekte. Prebehol takýto prieskum?
Ak je súčasťou projektu alebo zmenovej požiadavky v prevádzke vytvorenie alebo zmena elektronickej služby s grafickým používateľským rozhraním slúžiacej koncovým používateľom, vytvorenie alebo zmena elektronickej služby s aplikačným rozhraním, spôsoby a postupy elektronizácie agendy verejnej správy podľa osobitného predpisu sú realizované v týchto projektových fázach, kde jedna je používateľský prieskum, ktorý je výstupom prípravnej a iniciačnej fázy projektu a predmetom ďalšieho spracovania v realizačnej fáze projektu. https://www.slov-lex.sk/ezbierky-fe/pravne-predpisy/SK/ZZ/2023/401/20231115#paragraf-8.nadpis
V opačnom prípade konštatujeme porušenie § 8 písm. a) vyhlášky MIRRI č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy v nadväznosti na § 24 ods. 2 zákona č. 95/2019 Z. z.o ITVS
prínosy prosím aj vysvetliť a popísať. V CBA sú akési údaje, ale nie sú vysvetlené. Na záložke parametre agendové sú pre jednotlivé moduly uvedené časy pre spracovanie (čas úradníka) a následne po implementácii projektu nie je nič - dôjde k automatizácii? Z čoho vyplývajú časy? Taktiež to vyzerá, že máte rovnaký prínos využitý pri viacerých moduloch a tiež prínosy začínajú plynúť ešte v čase realizácie projektu, čo nezodpovedá realite.
Áno výstupom je automatizácia a keďže výstupy projektu začnú byť dostupné v prvom roku a s cieľom porovnať voči AS/IS stavu, ktorý reprezentuje rovnaké množstvo podaní manuálne spracovaných tak sa uvádzajú pre prvý rok.
Prosím v texte v tejto kapitole vysvetliť a popísať prínosy projektu, na ktorých je postavená CBA. Odkiaľ pochádzajú vstupné údaje, na základe čoho sú v CBA vstupy....
Prosím - podstatné - CBA, ktorú ste použili, ktorá bola zverejnená na QA stránke, nie je určená pre iné projekty okrem tých z výzvy 617, ktorá je už uzavretá. Prosím o použitie správnej CBA
V projektovom tíme absentuje pozícia UX dizajnér, ktorá má byť súčasťou projektového tímu podľa vyhlášky 401/2023 Z. z.. Kto vo vašom projekte zastreší oblasť UX?
Absentuje legislatíva: zákon o ITVS 95/2019 Z. z., vyhláška o elektronizácii agendy verejnej správy 547/2021 Z. z., vyhláška o o štandardoch pre informačné technológie verejnej správy 78/2020 Z. z.
Váš projekt sa nachádza v realizačnej fáze, no podľa 401/2023 používateľský prieskum má byť súčasťou a výstupom prípravnej a iniciačnej fázy projektu. Prosím o zosúladenie.
tuto je to trochu inak popísané, ako sa spomínalo na úvodnom stretnutí k projektu. Tam bolo spomenuté, že legislatíva nie je rizikom, ale z tohto textu vyplýva celkom veľké riziko, ak by neexistoval právny základ na adresnú energo pomoc
Stále platí, že celý systém IS ROM môže byť vybudovaný na základe zákona č. 71/2025 Z.z. o poskytovaní údajov na účel adresnej pomoci. Zmienený odstavec len poukazuje na riziko, že nebudú definované legislatívne podmienky na vyplácanie energopomoci, čo však pri súčasnom stave rozpracovania legislatívy nepredpokladáme.
čiže vznikajú tieto nové koncové služby pre občana - viete nám v texte popísať, na čo jednotlivé služby slúžia?
Zároveň v rámci názvov odporúčame pri tvorbe dodržiavať princípy § 26 v vyhlášky 78/2020 Z. z., ale aj z Príručky k MetaIS
Odporúčame teda použitie slovesného podstatného mena ako "podávanie sťažnosti..." alebo "Nahlasovanie zmeny údajov odberného miesta").
Taktiež z názvov by malo byť jasné, o čo ide. Napr. Udelenie adresnej pomoci je nešpecifické a je písané z pohľadu OVM, lebo OVM niečo udeľuje, ale občan o niečo žiada.
nižšie popisujete 1 proces, ale vychádzajúc z prínosov aj koncových služieb pre občana, zmení sa toho na biznis úrovni teda dosť. Pýtam sa teda:
1. aké zmeny nastanú na biznis úrovni, ktoré spôsobia to, že sa ušetrí toľko času úradníka, koľko píšte v prínosovej časti CBA (Parametre agendové)?
2. čo celý projekt znamená pre občana - tu sa pýtam ako občan - čo bude vlastne výsledkom projektu ako celok, ako to budem môcť použiť? Čo to pre mňa znamená? Ako zistíte, či som vhodný kandidát pre energopomoc? Viete popísať v jednoduchosti celý proces/výsledok tohto projektu?
AS/IS proces znamená, že občania by dokumenty a žiadosti o adresnú pomoc museli nosiť na úrady. TO/BE stav znamená, že adresná energopomoc bude poskytovaná proaktívne, na základe existujúcich údajov z ISVS. V prípade nezrovnalostí môže občan podať reklamáciu.
No ale čo teda spôsobí ušetrenie času úradníka? Z vysvetlenia vyplýva úspora pre občana. Táto otázka súvisí aj s otázkou/pripomienkou ohľadom vysvetlenia prínosov
Potreba monitoringu je vždy. V Kat. požiadaviek máte požiadavku na integráciu na prevádzkový monitoring, tak prečo je tu len možnosť? Keď robíte takýto projekt, treba riešiť aj monitoring funkčnosti a dostupnosti systému a kvôli citlivosti spracovávaných dát aj bezpečnostný monitoring a integráciu na SIEM.
V katalógu požiadaviek máte síce odpovedajúce funkčné požiadavky ale kvôli sledovaniu realizácie KS si dajte k príslušným požiadavkám na realizáciu KS kódy METAIS aj do katalógu požiadaviek.
Neplánujete obstarať žiadne licencie SW. V CBA máte uvedené licencie na Power BI. Tie ste neplánovali do rozpočtu zaradiť? Tieti licencie na Poer BI máte v CBA uvedené so zaradením do "A1 - Manažment osobných údajov" príčom v popise projektu píšete, že oblasť Mojich údajov (dát) nie je v projekte riešená. Zosúlaďte CBA, katalóg požiadaviek a popis projektu s textom I-02 Proj. zámer.
Nebudete potrebovať licencie na operačný systém alebo databázový systém, keďže v projekte uvažujete s vybudovaním DB clusterov. Plánujete všetok systémový SW riešiť len pomocou open source? Nebude potrebovať licencovať Oper. systém na HW? Privátny vládny cloud poskytuje len voľne dostupný Linux. V prípade, že by ste chceli použiť napr. RedHat alebo inú platenú distribúciu, bude ju musieť obstarať. Nepotrebujete si an takéto investície dať nejakú alokáciu finančných prostriedkov do rozpočtu?
Prosím vložiť obrázok a najlepšie aj odkaz do Architektonického modelu (názov pohľadu), ktorý ste nahrali a po úprave nahráte novú verziu do METAIS k proj. dokumentácii.
V náhľade celkovej architektúry uveďte pre dodávané komponenty evidované v METAIS aj ich kódy v názve komponentu napr. do zátvorky, aby vrcholový model a jeho hlavné dodávané komponenty odpovedali ich evidencii v METAIS.
Obrázok vložený. Prosíme zvážiť pridanú hodnotu zapracovania kódov META IS do obrázkov, pretože by obrázky boli neprehľadné (z dôvodu formátovania zobrazovaných reťazcov).
V architektoncikom modeli, ktorý ste nahrali uveďte pri plánovaných koncových službách aj kód služby v METAIS (napr. tak, že za názov služby dáte do zátvorky kód METAIS). Zosúlaďte model s evidecniou v METAIS minimálne na vrcholových pohľadoch na systém, kde sú uvedené eGovernement komponenty evidované v METAIS. Z názvu všetkých koncových služiev v modeli odstráňte zbytočný text "Životná situácia - " - zneprehľadňuje to model. Modelovaný vzťah rola "Správca adresnej pomoci" je kompozíciou biznis rozhrania "Energoportál" je dosť divný. Dalo by sa síce nájsť vysvetlenie a interpretácia takéhoto vzťahu, ale asi ste skôr chceli povedať, že Energoportál buď slúži alebo je obsluhovaný pracovníkom MHSR v roli správca adresnej pomoci, nie? Týka sa to aj ďalších podobných vzťahov v modeli a náhľade biznis vrstvy. Taktiež odporúčam pre sprehľadnenie náhľadu usporiadať súvisiace komponenty k sebe do vrstiev (pracovníci, role, rozhrania, služby, biznis dáta).
Prosíme zvážiť pridanú hodnotu zapracovania kódov META IS do obrázkov, pretože by obrázky boli neprehľadné (z dôvodu formátovania zobrazovaných reťazcov).
Zvážili sme už dávnejšie a preto sme to dali aj do Usmernenie na hodnotenie realizácie výstupu M-06 a A-09 orgánom vedenia podľa vyhlášky MIRRI č. 401/2023 Z.z. v znení vyhlášky č. 46/2025 Z.z., ktorý je uvedený na stránke https://mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/ (súbor: https://mirri.gov.sk/wp-content/uploads/2023/11/M-06-Evidencia-eGov-komponentov-a-modelov-v2.0.docx). Pridanie krátkeho reťazca METAIS kódu do pomenovania komponentu, ktorý by mal byť evidovaný v METAIS pomáha jednoducho skontrolovať súlad textu proj. zámeru, evidencie v METAIS, obrázkov a modelu. V prípade príliš veľkého obrázku je možné urobiť reorganizáciu štruktúry obrázkov a viac náhľadov na model tak, aby boli prehľadné.
API odberné miesta nie je vhodný názov pre aplikačnú službu. Pozrite príručku METAIS s usmernením pre názov koncových služieb a podobný vzor treba použiť aj pre aplikačné služby. API je rozhranie, nie služba. Pre KS ks_381391, ks_381392, ks_381393 by vhodným názvom AS bolo napr. "Evidovanie (alebo aj "Evidencia") odberných miest". Pre ks_381389 a tiež aj pre ks_381390 a ks_381386 aplikačná služba s názvom "Poskytnutie údajov o adresnej pomoci" pre zisťovaciu časť procesu. Pre spracovanie žiadostí a sťažností (ks_381387, ks_381388, ks_381390) napr. aplikačná služba "Spracovanie žiadostí". Pre generovanie šekov s adresnou pomocou aplikačnej služby "Generovanie (výpočet) dát adresnej pomoci". Lepšie poznáte problematiku a tak môžete prpraviť lepšie názvy aplikčných služieb. pripomínam tiež, že jedna aplikačná služba (AS) môže slúžiť viacerým KS a žiadna KS by namala byť bez aspoň jednej obsluhujúcej AS. Doplňte a opravte tiež evidenciu v METAIS (nezmyselné viacnásobné evidovanie aplik. služieb s rovnakým názvom eGov API, "API Odberné miesta") Do tejto tabuľky v dokumente I-02 doplňte kódy METAIS aplikačných služieb.
Tu má byť uvedený kód a názov aplikčnej služby, ktorá realizuje integráciu na strane konzumenta služby spoločného modulu a nie kód modulu poskytujúceho službu. V poslednom stĺpci má byť uvedená služba (služba spol. modulu), na ktorú bude AS uvedená v prvom stĺpci integrovaná.
Uveďte si požiadavku na dodávku Bezpečnostného projektu aj do Katalógu požiadaviek. A taktiež do požiadavky doplňte, že v dodávanom systéme budú aplikované opatrenia identifikované bezpečnostným projektom a že bezpečnostný projekt bude priebežne počas projektu altualizovaný podľa skutočnej realizácie a nasadenia systému.
Požiadavku na konkrétnu úroveň dostupnosti si dajte aj do katalógu požiadaviek. Taktiež s do katalógu dajte požiadavku na parametre RTO a RPO. Z katalógu požiadaviek odstráňte zbytočné duplicitné nekonkretizované požiadavky na zálohovanie a dostupnosť pre jednotlivé podmoduly. Buď k nim uveďte konkrétne parametre, alebo ich vyriešte jednou spoločnou požiadavkou. Nepotrebujete nafukovať počet požiadaviek zbytočnými duplicitami.
Chýbajúce obrázky nižšie pre znázornenie uvedených procesov: Overenie získania energopomoci, Podanie sťažnosti pre nezískanie energopomoci, Podanie sťažnosti o nesprávnej energopomoci, Žiadosť o vylúčenie z energopomoci
V arch. modeli (súbor rom 1.archimate) máte pekný obrázok plánovaného nasadenia s názvom "Architektúra". Môžete ho tu uviesť. V modeli mu ale zmeňte názov, lebo je to skôr náhľad plánovaného nasadenia systému ako všeobecný názov "Architektúra"
Pre overovanie stíhania budete asi potrebovať nejakú aplikačnú službu pre Lustrácie, lebo asi tieto dáta Vám MVSR neposkytne hromadne. Pre overenie registra trestov zvážte použitie IS CPDI namiesto priamej integrácie na Gen. prokuratúru.
Pre potenciálnu integráciu systémov, ktoré používajú plánované pracoviská spolupracujúcich OVM (úrady práce, Slov. pošta, CallCentrum MVSR, atď.) budete asi potrebovať samostatnú sadu služieb pre takúto integráciu, ak tieto orgány budú chcieť implementovať vlastné používateľské rozhranie do svjich systémov namiesto použitia web rozhrania systému ROM pre sprostredkovateľov energopomoci.
V biznis architektúre vám chýba aktér pracovník sprostredkovania energopomoci a príslušná rola a distribučný kanál ( napr. nejaká špecializovaná podčasť Energoportálu alebo API pre integráciu systému sprostredkovateľa pomoci) a tomu odpovedajúca aplikačné časti - web rozhranie a API pre integráciu sprstredkovateľov pomoci.
Dajte si do katalógu požiadaviek, že vám má dodávateľ dodať návrh testovacích scenárov pre otestovanie plnej funkčnosti dodávaného systému a tiež že má podľa definovaných scenárov vykonať a protokolárne zdokladovať automatizované otestovanie funkčnosti systému podľa navrhnutých testovacích scenárov.
V modeli a obrázku aplikačnej architektúry uveďte aj METAIS kódy znázornených ISVS, ich modulov a tiež aplikačných služieb (napr. do zátvorky k názve komponentu). Plánované podmoduly systému ROM radšej modelujte ako funkčné bloky, ak nebudú samostatne nasadzované a evidované v METAIS ako podmoduly. Samostatne nasadzované podmoduly, ako je napr. web portál, analytický systém, samostatnú integračnú platformu by bolo lepšie uviesť ako podmoduly systému ROM a zaevidovať ich tiež v METAIS buď ako podmoduly systému ROM alebo ako súčasne dodávané systémy v tomto projekte.
Prosíme zvážiť pridanú hodnotu zapracovania kódov META IS do obrázkov, pretože by obrázky boli neprehľadné (z dôvodu formátovania zobrazovaných reťazcov).
1. záložka moduly CBA - pre moduly 17 až 20 máte zle nastavené productivity faktory, ktoré ponúkajú možnosti len 15, 20, 25 a 30. Tu to dotiahol excel nejak chbyne, prosíme opraviť
2. záložka UAW - prosím, vysvetlite používateľov:
3 typy používateľov typu občan
3 typy používateľov typu zamestnanec inštitúcie verejnej správy
11 systémov verejnej správy - tu je aj zle nastavená zložitosť (má byť 2 alebo 1 podľa Metodiky k CBA - 1 = používateľ je systém s definovaným aplikačným programovým rozhraním, 2 = systém interagujúci prostredníctvom protokolu (napr. Transmission control protocol/Internet protocol)
4 isvs mimo verejnej správy - tiež je tu zle nastavená zložitosť
3. v celej CBA pravdepodobne nie je aktualizovaná sadzba DPH na 23% - vyriešite vyplnením správnej CBA
4. ak financujete projekt z Programu Slovensko , tak na záložke pozície interné v CBA v bunke Q2 nepoužívate odmeny - tie sú zahrnuté v sadzbách
5. prínosy na záložke Parametre agendové sa vám rátajú od 1. roku, ale v realite nastanú v podstate až v roku 3.
6. záložka ECF - tu ste zadávali hodnoty? Všade sú 1ky.
7. záložka Pozície interné - v prípade projektov z Programu Slovensko sa neuplatňujú odmeny - bunka Q2
1. záložka moduly CBA - pre moduly 17 až 20 máte zle nastavené productivity faktory, ktoré ponúkajú možnosti len 15, 20, 25 a 30. Tu to dotiahol excel nejak chbyne, prosíme opraviť
2. záložka UAW - prosím, vysvetlite používateľov:
3 typy používateľov typu občan
3 typy používateľov typu zamestnanec inštitúcie verejnej správy
11 systémov verejnej správy - tu je aj zle nastavená zložitosť (má byť 2 alebo 1 podľa Metodiky k CBA - 1 = používateľ je systém s definovaným aplikačným programovým rozhraním, 2 = systém interagujúci prostredníctvom protokolu (napr. Transmission control protocol/Internet protocol)
4 isvs mimo verejnej správy - tiež je tu zle nastavená zložitosť
3. v celej CBA pravdepodobne nie je aktualizovaná sadzba DPH na 23% - vyriešite vyplnením správnej CBA
4. ak financujete projekt z Programu Slovensko , tak na záložke pozície interné v CBA v bunke Q2 nepoužívate odmeny - tie sú zahrnuté v sadzbách
5. prínosy na záložke Parametre agendové sa vám rátajú od 1. roku, ale v realite nastanú v podstate až v roku 3.
6. záložka ECF - tu ste zadávali hodnoty? Všade sú 1ky.
7. nie je vyplnená záložka Zdroje financovania
8. máte aktualizovanú záložku Faktory?
9. nastavte prosím odvody na záložke pozície interné na 0,3595 - bunka Q1
uvedené ID/názvy cieľov nezodpovedajú tým, čo ste si nastavili. Vyzerá to tak, že ciele a ukazovatele sú oddelené. Tieto kapitoly a ich tabuľky sú prepojené z dôvodu, aby si OVM nastavilo ciele projektu a následne k nim v ďalšej tabuľke priradilo merateľné ukazovatele, na základe ktorých sa meria ich naplnenie.
nechápem, ako toto môže byť merateľný ukazovateľ projektu. Nesúvisí vôbec s projektom ako takým a je závislý čisto od faktorov, ktoré nie sú projektom ovplyvnené - subjektívnu spokojnosť neviete garantovať.
Alebo očakávate, že sťažnosti budú chodiť vo väčšej miere oprávnene?
Ak sa jedná o službu, ktorú nepoužíva a nespúšťa občan/podnikateľ, ale zamestnanec OVM, tak sa jedná o typ G2E .
Zároveň som sa v inom komentári pýtala na popis služieb a bola som odkázaná na kapitolu 3.6, ale tu nie sú popísané všetky služby, a tak nie je možné určiť, čo je pre občana a čo pre zamestnanca OVM
predpokladám, že ak sú služby komplet elektronické, tak úroveň 4. Dokonca pri proaktívnych je to úroveň 5. Čiže ak napr. proaktívne poskytujete energopomoc, tak je to 5
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.
Všetky integrácie sú plánované napriamo? Prečo nevyužiť IS CPDI pre konzumáciu registrov, ktoré sú už na IS CPDI naintegrované?
IS ROM bude konzumovať služby, ktoré nie sú vypublikované na CPDI (napr. zmenové dávky IS RFO). Prostredníctvom IS CPDI budú konzumované služby napr. UPSVaR.
Nesúhlasím s uvedeným tvrdením, ktoré podľa môjho názoru zodpovedá neznalosti integračného manuálu prístupného na Detail položky ISVS, IS Centrálna platforma dátovej integrácie (IS CPDI) | MetaIS, IM _ISCSRU_v3.0.1.rar (RAR, 8.43 MB). V prílohe č. 2 sú popísané objekty evidencií prístupné na IS CPDI vrátane integračných väzieb. Uvedený príklad zmenové dávky IS RFO je popísaný na str. 17, bod 64. Int.M. - príloha č. 2.
MPSVaR aktuálne pripravuje nový OE obsahujúci dávky poskytované občanom, ktorý bude dostupný na IS CPDI v 4Q2025 v rámci riešenia životných situácií.
V súčasnosti má MH SR naintegrované RFO (medzi inými aj integračnú väzbu Získavanie zmenových dávok RFO), RA, RPO.
V rámci projektu sú identifikované konkrétne integrácie pre informačné systémy OVM. Projekt predpokladá získavanie (konzumovanie) údajov priamo zo zdrojových informačných systémov, nie získavanie údajov prostredníctvom IS CPDI (spoločný eGov komponent), i keď ide o údaje, ktoré je možné prostredníctvom IS CPDI získavať. Vzhľadom na uplatňovanie princípu zákazu priamych integrácií (integračný princíp MIRRI SR), Centrálna dátová kancelária nepodporuje vytváranie priamych integrácií na zdrojový informačný systém – projekt je potrebné upraviť tak, aby boli údaje získavané prostredníctvom IS CPDI (doplniť existujúce integrácie o novo konzumované objekty evidencií a integračné väzby). Priama integrácia je možná iba pri OE, ktoré na IS CPDI nie sú a neuvažuje sa v tomto období na ich doplnení. Aj pri takých uprednostňujeme integráciu na IS CPDI, nakoľko sa v budúcnosti môžu stať predmetom konzumovania inými OVM.
V tejto súvislosti je treba zdôrazniť povinnosť OVM poskytovať údaje prostredníctvom IS CPDI uloženú § 12 ods. 1 písm l) 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.
RFO? RA? Prečo nevyužiť už existujúce poskytovateľské integrácie?Postup na IS Centrálna platforma dátovej integrácie | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR
IS ROM bude konzumovať služby, ktoré nie sú vypublikované na CPDI (napr. zmenové dávky IS RFO). Prostredníctvom IS CPDI budú konzumované služby napr. UPSVaR.
rovnaká pripomienka ako o bod vyššie
OK VYRIEŠENÉ
bolo by vhodné doplniť
OK vyriešené
tieto pomôcky je vhodné vymazať
OK VYRIEŠENÉ
v súčasnosti je prípravná a iniciačná fáza spolu
Metaúdaje k datasetom je potrebné katalogizovať na portáli otvorených dát data.slovensko.sk podľa aktuálneho metaúdajového štandardu DCAT AP-SK/resp. zároveň ku projektu vytvoriť lokálny katalóg otvorených dát, resp. OpenApi a tú/ten zaregistrovať na portál data.slovensko.sk
Anonymizovaný dataset reklamácií/sťažností? Štatistické údaje ku poskytnutej pomoci?
Považujeme za nerelevantný údaj.
Prečo považujete štatistické údaje ku poskytnutej pomoci za irelevantný údaj?
Dáta je potrebné v rámci dátovej kvality stotožňovať a referencovať voči referenčným registrom, používať identifikátori ako IČO, identifikátor adresy, resp. fyzickej osoby, zaviesť biznis pravidlá/metodiku ku dátovej kvalite, obmedzenia pre dáta (hodnoty, formáty, rozsahy...) keďže sa plánuje zlučovanie dát z rôznych registrov a IS
Všetko čo sa dá refencovať bude referencované ako napr. adresa, R.Č. vo referenčným registrom.
NEZAPRACOVANÉ
Prosím o uvedenie priority a špecifického cieľa z Programu Slovensko
Priorita 2P1 - energetická efektívnosť a dekarbonizácia
Špecifický cieľ RSO2.3 - vývoj inteligentných energetických systémov, sietí a uskladnenia mimo Transeurópskej ener. siete (TEN-E)
Prosím uviesť aj do textu
na toto nie je KPI? automatizácia akých procesov? Neprinesie automatizácia urýchlenie procesov a úsporu času?
Uvedené v 3.4, 3.5 a 3.6
ktorý ukazovateľ teda patrí k cieľu ID č4?
OK VYRIEŠENÉ
koľkým subjektom sa budú údaje poskytovať, resp. ak je to cieľ, nie je vhodné na to vytvoriť KPI napr. počet subjektov, ktorým sú poskytované anonymizované údaje?
Ide o otvorené a analytické údaje a počet konzumentov nie je možné momentálne určiť.
OK VYRIEŠENÉ
podľa informácií v projekte sú v projekte aj elektronické služby pre občana. Podľa § 8 vyhlášky 401/2023 Z. z. je potrebné zrealizovať používateľský prieskum už v prípravnej a iniciačnej fáze a spracovať z neho výsledky v projekte. Prebehol takýto prieskum?
Neprebehol, pretože elektronické služby sú nevyhnutné pre reklamačný proces.
Bez ohľadu na to, či sú služby nevyhnutné, platí:
Ak je súčasťou projektu alebo zmenovej požiadavky v prevádzke vytvorenie alebo zmena elektronickej služby s grafickým používateľským rozhraním slúžiacej koncovým používateľom, vytvorenie alebo zmena elektronickej služby s aplikačným rozhraním, spôsoby a postupy elektronizácie agendy verejnej správy podľa osobitného predpisu sú realizované v týchto projektových fázach, kde jedna je používateľský prieskum, ktorý je výstupom prípravnej a iniciačnej fázy projektu a predmetom ďalšieho spracovania v realizačnej fáze projektu. https://www.slov-lex.sk/ezbierky-fe/pravne-predpisy/SK/ZZ/2023/401/20231115#paragraf-8.nadpis
V opačnom prípade konštatujeme porušenie § 8 písm. a) vyhlášky MIRRI č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy v nadväznosti na § 24 ods. 2 zákona č. 95/2019 Z. z.o ITVS
Nemali ste v rámci príprave nejaký výstup, ktorý by mohol nahradiť klasický používateľský prieskum? Nejaké spätné väzby od občanov alebo čokoľvek, čo by sa dalo napasovať na https://www.slov-lex.sk/ezbierky-fe/pravne-predpisy/SK/ZZ/2021/547/#paragraf-5.nadpis
Doplnené v bode 3.6.5
OK VYRIEŠENÉ
prínosy prosím aj vysvetliť a popísať. V CBA sú akési údaje, ale nie sú vysvetlené. Na záložke parametre agendové sú pre jednotlivé moduly uvedené časy pre spracovanie (čas úradníka) a následne po implementácii projektu nie je nič - dôjde k automatizácii? Z čoho vyplývajú časy? Taktiež to vyzerá, že máte rovnaký prínos využitý pri viacerých moduloch a tiež prínosy začínajú plynúť ešte v čase realizácie projektu, čo nezodpovedá realite.
Áno výstupom je automatizácia a keďže výstupy projektu začnú byť dostupné v prvom roku a s cieľom porovnať voči AS/IS stavu, ktorý reprezentuje rovnaké množstvo podaní manuálne spracovaných tak sa uvádzajú pre prvý rok.
Prosím v texte v tejto kapitole vysvetliť a popísať prínosy projektu, na ktorých je postavená CBA. Odkiaľ pochádzajú vstupné údaje, na základe čoho sú v CBA vstupy....
OK VYRIEŠENÉ
Prosím - podstatné - CBA, ktorú ste použili, ktorá bola zverejnená na QA stránke, nie je určená pre iné projekty okrem tých z výzvy 617, ktorá je už uzavretá. Prosím o použitie správnej CBA
správna:
CBA bola preklopená do správnej šablóny.
Vychádza vaša špecifikácia potrieb používateľa z používateľského prieskumu?
Doplnené v bode 3.6.5
V projektovom tíme absentuje pozícia UX dizajnér, ktorá má byť súčasťou projektového tímu podľa vyhlášky 401/2023 Z. z.. Kto vo vašom projekte zastreší oblasť UX?
Doplníme.
OK
Absentuje legislatíva:
zákon o ITVS 95/2019 Z. z.,
vyhláška o elektronizácii agendy verejnej správy 547/2021 Z. z.,
vyhláška o o štandardoch pre informačné technológie verejnej správy 78/2020 Z. z.
Doplníme do kapitoly 4.
OK
Váš projekt sa nachádza v realizačnej fáze, no podľa 401/2023 používateľský prieskum má byť súčasťou a výstupom prípravnej a iniciačnej fázy projektu. Prosím o zosúladenie.
Projekt sa nachádza v prípravnej a incializačnej fáze harmonogram bude aktualizovaný. Prieskum v realizačnej fáze je zameraný na testovanie UX.
OK
Neuvažujete nad tým, že by ste šli v súlade s jednotným dizajnovým manuálom elektronických služieb a webových sídel - IDKS? https://idsk.gov.sk/co-je
Dielo bude v súlade s IDSK 3.0
OK
OK vyriešené
tuto je to trochu inak popísané, ako sa spomínalo na úvodnom stretnutí k projektu. Tam bolo spomenuté, že legislatíva nie je rizikom, ale z tohto textu vyplýva celkom veľké riziko, ak by neexistoval právny základ na adresnú energo pomoc
Stále platí, že celý systém IS ROM môže byť vybudovaný na základe zákona č. 71/2025 Z.z. o poskytovaní údajov na účel adresnej pomoci. Zmienený odstavec len poukazuje na riziko, že nebudú definované legislatívne podmienky na vyplácanie energopomoci, čo však pri súčasnom stave rozpracovania legislatívy nepredpokladáme.
OK Vyriešené
prosím len o skontrolovanie nahratia obrázkov v projekte, nakoľko ich nikde nevidíme.
Vyriešené.
Všeobecná pripomienka. Po úpravách v XWIKI je vždy potrebné aktualizovať verziu dokumentácie aj v MetaIS stlačením
čiže vznikajú tieto nové koncové služby pre občana - viete nám v texte popísať, na čo jednotlivé služby slúžia?
Zároveň v rámci názvov odporúčame pri tvorbe dodržiavať princípy § 26 v vyhlášky 78/2020 Z. z., ale aj z Príručky k MetaIS
Odporúčame teda použitie slovesného podstatného mena ako "podávanie sťažnosti..." alebo "Nahlasovanie zmeny údajov odberného miesta").
Taktiež z názvov by malo byť jasné, o čo ide. Napr. Udelenie adresnej pomoci je nešpecifické a je písané z pohľadu OVM, lebo OVM niečo udeľuje, ale občan o niečo žiada.
KS podporujú proces priznávania a reklamácií v rámci poskytovania energopomoci. Popis KS je v bode 3.6
nevyriešené - v kapitole 3.6 nie je popis pre všetky služby
nižšie popisujete 1 proces, ale vychádzajúc z prínosov aj koncových služieb pre občana, zmení sa toho na biznis úrovni teda dosť. Pýtam sa teda:
1. aké zmeny nastanú na biznis úrovni, ktoré spôsobia to, že sa ušetrí toľko času úradníka, koľko píšte v prínosovej časti CBA (Parametre agendové)?
2. čo celý projekt znamená pre občana - tu sa pýtam ako občan - čo bude vlastne výsledkom projektu ako celok, ako to budem môcť použiť? Čo to pre mňa znamená? Ako zistíte, či som vhodný kandidát pre energopomoc? Viete popísať v jednoduchosti celý proces/výsledok tohto projektu?
AS/IS proces znamená, že občania by dokumenty a žiadosti o adresnú pomoc museli nosiť na úrady. TO/BE stav znamená, že adresná energopomoc bude poskytovaná proaktívne, na základe existujúcich údajov z ISVS. V prípade nezrovnalostí môže občan podať reklamáciu.
No ale čo teda spôsobí ušetrenie času úradníka? Z vysvetlenia vyplýva úspora pre občana. Táto otázka súvisí aj s otázkou/pripomienkou ohľadom vysvetlenia prínosov
NEVYRIEŠENÉ
v prípade, ak využívate spoločné moduly, resp. idete vytvárať na ne integrácie, prosíme o postup podľa Príručky k MetaIS kapitola 2.4
Áno budeme.
k projektu máte evidované 3x aplikačná služba eGOV APi - je to omyl?
OK VYRIEŠENÉ
prosíme v texte o vyjadrenie k možnostiam použitia open source SW alebo krabicových riešení v projekte
Neexistuje komerčne dostupný SW, pre čiastkové moduly budú využité open source platformy.
prosíme o doplnenie k napĺňaniu NKIVS 2021 - ktorú prioritnú os a jej cieľ projekt napĺňa/prispieva k ich naplneniu
OS 2 Digitálna a dátová transformácia. 2.4 dobudovať digitálne prostredie založené na zdieľaní údajov vo VS
Prosím uviesť aj do textu projektu
OK
táto časť je nevyplnená zo šablóny
Doplníme odsek 4.
V prípade nasadenia do privátnej časti vládneho cloudu v správe MVSR by mala byť namiesto "Infra_sluzba_6" služba "infra_sluzba_509".
Opravené.
Duplicita s Tabuľka 11. Navrhujem odstrániť.
Písané podľa šablóny je nutná zmena?
Potreba monitoringu je vždy. V Kat. požiadaviek máte požiadavku na integráciu na prevádzkový monitoring, tak prečo je tu len možnosť? Keď robíte takýto projekt, treba riešiť aj monitoring funkčnosti a dostupnosti systému a kvôli citlivosti spracovávaných dát aj bezpečnostný monitoring a integráciu na SIEM.
Uvedený komponent bude použitý aj pre aplikačný monitoring. Zmena bude zapracovaná v texte.
V katalógu požiadaviek máte síce odpovedajúce funkčné požiadavky ale kvôli sledovaniu realizácie KS si dajte k príslušným požiadavkám na realizáciu KS kódy METAIS aj do katalógu požiadaviek.
Bude doplnené.
Neplánujete obstarať žiadne licencie SW. V CBA máte uvedené licencie na Power BI. Tie ste neplánovali do rozpočtu zaradiť? Tieti licencie na Poer BI máte v CBA uvedené so zaradením do "A1 - Manažment osobných údajov" príčom v popise projektu píšete, že oblasť Mojich údajov (dát) nie je v projekte riešená. Zosúlaďte CBA, katalóg požiadaviek a popis projektu s textom I-02 Proj. zámer.
Aktualizujeme podľa upravenej CBA.
Nebudete potrebovať licencie na operačný systém alebo databázový systém, keďže v projekte uvažujete s vybudovaním DB clusterov. Plánujete všetok systémový SW riešiť len pomocou open source? Nebude potrebovať licencovať Oper. systém na HW? Privátny vládny cloud poskytuje len voľne dostupný Linux. V prípade, že by ste chceli použiť napr. RedHat alebo inú platenú distribúciu, bude ju musieť obstarať. Nepotrebujete si an takéto investície dať nejakú alokáciu finančných prostriedkov do rozpočtu?
OS budú IaaS v rámci VC a pre DB bude použitý open source.
Dáta do analytickej databázy (BI) by mali byť tiež anonymizované a pseudonymizované. Požiadavku máte v kat. požiadaviek.
Bude doplnené v kap 5.2.
Prosím vložiť obrázok a najlepšie aj odkaz do Architektonického modelu (názov pohľadu), ktorý ste nahrali a po úprave nahráte novú verziu do METAIS k proj. dokumentácii.
V náhľade celkovej architektúry uveďte pre dodávané komponenty evidované v METAIS aj ich kódy v názve komponentu napr. do zátvorky, aby vrcholový model a jeho hlavné dodávané komponenty odpovedali ich evidencii v METAIS.
Obrázok vložený. Prosíme zvážiť pridanú hodnotu zapracovania kódov META IS do obrázkov, pretože by obrázky boli neprehľadné (z dôvodu formátovania zobrazovaných reťazcov).
Odpoveď k návrhu na zváženie v ďalšom komentári.
V architektoncikom modeli, ktorý ste nahrali uveďte pri plánovaných koncových službách aj kód služby v METAIS (napr. tak, že za názov služby dáte do zátvorky kód METAIS). Zosúlaďte model s evidecniou v METAIS minimálne na vrcholových pohľadoch na systém, kde sú uvedené eGovernement komponenty evidované v METAIS. Z názvu všetkých koncových služiev v modeli odstráňte zbytočný text "Životná situácia - " - zneprehľadňuje to model.
Modelovaný vzťah rola "Správca adresnej pomoci" je kompozíciou biznis rozhrania "Energoportál" je dosť divný. Dalo by sa síce nájsť vysvetlenie a interpretácia takéhoto vzťahu, ale asi ste skôr chceli povedať, že Energoportál buď slúži alebo je obsluhovaný pracovníkom MHSR v roli správca adresnej pomoci, nie? Týka sa to aj ďalších podobných vzťahov v modeli a náhľade biznis vrstvy. Taktiež odporúčam pre sprehľadnenie náhľadu usporiadať súvisiace komponenty k sebe do vrstiev (pracovníci, role, rozhrania, služby, biznis dáta).
Prosíme zvážiť pridanú hodnotu zapracovania kódov META IS do obrázkov, pretože by obrázky boli neprehľadné (z dôvodu formátovania zobrazovaných reťazcov).
Zvážili sme už dávnejšie a preto sme to dali aj do Usmernenie na hodnotenie realizácie výstupu M-06 a A-09 orgánom vedenia podľa vyhlášky MIRRI č. 401/2023 Z.z. v znení vyhlášky č. 46/2025 Z.z., ktorý je uvedený na stránke https://mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/ (súbor: https://mirri.gov.sk/wp-content/uploads/2023/11/M-06-Evidencia-eGov-komponentov-a-modelov-v2.0.docx). Pridanie krátkeho reťazca METAIS kódu do pomenovania komponentu, ktorý by mal byť evidovaný v METAIS pomáha jednoducho skontrolovať súlad textu proj. zámeru, evidencie v METAIS, obrázkov a modelu. V prípade príliš veľkého obrázku je možné urobiť reorganizáciu štruktúry obrázkov a viac náhľadov na model tak, aby boli prehľadné.
Tak ako steto uviedli pre niektoré z ISVS, aj pre ostatné integrované ISVS treba uviesť ich METAIS kódy.
API odberné miesta nie je vhodný názov pre aplikačnú službu. Pozrite príručku METAIS s usmernením pre názov koncových služieb a podobný vzor treba použiť aj pre aplikačné služby. API je rozhranie, nie služba. Pre KS ks_381391, ks_381392, ks_381393 by vhodným názvom AS bolo napr. "Evidovanie (alebo aj "Evidencia") odberných miest".
Pre ks_381389 a tiež aj pre ks_381390 a ks_381386 aplikačná služba s názvom "Poskytnutie údajov o adresnej pomoci" pre zisťovaciu časť procesu. Pre spracovanie žiadostí a sťažností (ks_381387, ks_381388, ks_381390) napr. aplikačná služba "Spracovanie žiadostí". Pre generovanie šekov s adresnou pomocou aplikačnej služby "Generovanie (výpočet) dát adresnej pomoci". Lepšie poznáte problematiku a tak môžete prpraviť lepšie názvy aplikčných služieb. pripomínam tiež, že jedna aplikačná služba (AS) môže slúžiť viacerým KS a žiadna KS by namala byť bez aspoň jednej obsluhujúcej AS. Doplňte a opravte tiež evidenciu v METAIS (nezmyselné viacnásobné evidovanie aplik. služieb s rovnakým názvom eGov API, "API Odberné miesta") Do tejto tabuľky v dokumente I-02 doplňte kódy METAIS aplikačných služieb.
Trváme na pôvodnom názvosloví.
Podľa inštrukcií v príručke METAIS, kap. 2.4, doplňte aj AS pre integráciu s modulom otvorené údaje.
Doplníme
Tu má byť uvedený kód a názov aplikčnej služby, ktorá realizuje integráciu na strane konzumenta služby spoločného modulu a nie kód modulu poskytujúceho službu. V poslednom stĺpci má byť uvedená služba (služba spol. modulu), na ktorú bude AS uvedená v prvom stĺpci integrovaná.
Doplníme
Dajte si túto požiadavku aj do katalógu požiadaviek.
Doplníme
Uveďte si požiadavku na dodávku Bezpečnostného projektu aj do Katalógu požiadaviek. A taktiež do požiadavky doplňte, že v dodávanom systéme budú aplikované opatrenia identifikované bezpečnostným projektom a že bezpečnostný projekt bude priebežne počas projektu altualizovaný podľa skutočnej realizácie a nasadenia systému.
Doplníme
Požiadavku na konkrétnu úroveň dostupnosti si dajte aj do katalógu požiadaviek. Taktiež s do katalógu dajte požiadavku na parametre RTO a RPO. Z katalógu požiadaviek odstráňte zbytočné duplicitné nekonkretizované požiadavky na zálohovanie a dostupnosť pre jednotlivé podmoduly. Buď k nim uveďte konkrétne parametre, alebo ich vyriešte jednou spoločnou požiadavkou. Nepotrebujete nafukovať počet požiadaviek zbytočnými duplicitami.
Upravíme
Chýbajúce obrázky nižšie pre znázornenie uvedených procesov: Overenie získania energopomoci, Podanie sťažnosti pre nezískanie energopomoci, Podanie sťažnosti o nesprávnej energopomoci, Žiadosť o vylúčenie z energopomoci
Doplnené
V arch. modeli (súbor rom 1.archimate) máte pekný obrázok plánovaného nasadenia s názvom "Architektúra". Môžete ho tu uviesť. V modeli mu ale zmeňte názov, lebo je to skôr náhľad plánovaného nasadenia systému ako všeobecný názov "Architektúra"
Zapracujeme
Pre overovanie stíhania budete asi potrebovať nejakú aplikačnú službu pre Lustrácie, lebo asi tieto dáta Vám MVSR neposkytne hromadne. Pre overenie registra trestov zvážte použitie IS CPDI namiesto priamej integrácie na Gen. prokuratúru.
Očakávame AS pre Lustrácie.
V prípade GP SR zvážime, v prípade dostupnosti využijeme IS CPDI.
Pre potenciálnu integráciu systémov, ktoré používajú plánované pracoviská spolupracujúcich OVM (úrady práce, Slov. pošta, CallCentrum MVSR, atď.) budete asi potrebovať samostatnú sadu služieb pre takúto integráciu, ak tieto orgány budú chcieť implementovať vlastné používateľské rozhranie do svjich systémov namiesto použitia web rozhrania systému ROM pre sprostredkovateľov energopomoci.
Toto bude definované v štádiu analýzy a návrhu.
V biznis architektúre vám chýba aktér pracovník sprostredkovania energopomoci a príslušná rola a distribučný kanál ( napr. nejaká špecializovaná podčasť Energoportálu alebo API pre integráciu systému sprostredkovateľa pomoci) a tomu odpovedajúca aplikačné časti - web rozhranie a API pre integráciu sprstredkovateľov pomoci.
Neočakávame využívanie sprostredkovateľov.
Dajte si do katalógu požiadaviek požiadavku na to, že Vám má dodávateľ dodať dokumentáciu systému podľa vyhlášky 401/2023.
Doplníme
Dajte si do katalógu požiadaviek, že vám má dodávateľ dodať návrh testovacích scenárov pre otestovanie plnej funkčnosti dodávaného systému a tiež že má podľa definovaných scenárov vykonať a protokolárne zdokladovať automatizované otestovanie funkčnosti systému podľa navrhnutých testovacích scenárov.
Doplníme
V modeli a obrázku aplikačnej architektúry uveďte aj METAIS kódy znázornených ISVS, ich modulov a tiež aplikačných služieb (napr. do zátvorky k názve komponentu). Plánované podmoduly systému ROM radšej modelujte ako funkčné bloky, ak nebudú samostatne nasadzované a evidované v METAIS ako podmoduly. Samostatne nasadzované podmoduly, ako je napr. web portál, analytický systém, samostatnú integračnú platformu by bolo lepšie uviesť ako podmoduly systému ROM a zaevidovať ich tiež v METAIS buď ako podmoduly systému ROM alebo ako súčasne dodávané systémy v tomto projekte.
Prosíme zvážiť pridanú hodnotu zapracovania kódov META IS do obrázkov, pretože by obrázky boli neprehľadné (z dôvodu formátovania zobrazovaných reťazcov).
CBA:
1. záložka moduly CBA - pre moduly 17 až 20 máte zle nastavené productivity faktory, ktoré ponúkajú možnosti len 15, 20, 25 a 30. Tu to dotiahol excel nejak chbyne, prosíme opraviť
2. záložka UAW - prosím, vysvetlite používateľov:
3 typy používateľov typu občan
3 typy používateľov typu zamestnanec inštitúcie verejnej správy
11 systémov verejnej správy - tu je aj zle nastavená zložitosť (má byť 2 alebo 1 podľa Metodiky k CBA - 1 = používateľ je systém s definovaným aplikačným programovým rozhraním, 2 = systém interagujúci prostredníctvom protokolu (napr. Transmission control protocol/Internet protocol)
4 isvs mimo verejnej správy - tiež je tu zle nastavená zložitosť
3. v celej CBA pravdepodobne nie je aktualizovaná sadzba DPH na 23% - vyriešite vyplnením správnej CBA
4. ak financujete projekt z Programu Slovensko , tak na záložke pozície interné v CBA v bunke Q2 nepoužívate odmeny - tie sú zahrnuté v sadzbách
5. prínosy na záložke Parametre agendové sa vám rátajú od 1. roku, ale v realite nastanú v podstate až v roku 3.
6. záložka ECF - tu ste zadávali hodnoty? Všade sú 1ky.
7. záložka Pozície interné - v prípade projektov z Programu Slovensko sa neuplatňujú odmeny - bunka Q2
8. nie je vyplnená záložka Zdroje financovania
9. máte aktualizovanú záložku Faktory?
CBA je v štádiu prerábky do nového formuláru a požiadavky zapracujeme.
CBA - zeleným je vyriešené a zvyšok nedoriešené
2. záložka UAW - prosím, vysvetlite používateľov:
3 typy používateľov typu občan
3 typy používateľov typu zamestnanec inštitúcie verejnej správy
11 systémov verejnej správy - tu je aj zle nastavená zložitosť (má byť 2 alebo 1 podľa Metodiky k CBA - 1 = používateľ je systém s definovaným aplikačným programovým rozhraním, 2 = systém interagujúci prostredníctvom protokolu (napr. Transmission control protocol/Internet protocol)
4 isvs mimo verejnej správy - tiež je tu zle nastavená zložitosť
4. ak financujete projekt z Programu Slovensko , tak na záložke pozície interné v CBA v bunke Q2 nepoužívate odmeny - tie sú zahrnuté v sadzbách
5. prínosy na záložke Parametre agendové sa vám rátajú od 1. roku, ale v realite nastanú v podstate až v roku 3.
8. máte aktualizovanú záložku Faktory?
9. nastavte prosím odvody na záložke pozície interné na 0,3595 - bunka Q1
uvedené ID/názvy cieľov nezodpovedajú tým, čo ste si nastavili. Vyzerá to tak, že ciele a ukazovatele sú oddelené. Tieto kapitoly a ich tabuľky sú prepojené z dôvodu, aby si OVM nastavilo ciele projektu a následne k nim v ďalšej tabuľke priradilo merateľné ukazovatele, na základe ktorých sa meria ich naplnenie.
nechápem, ako toto môže byť merateľný ukazovateľ projektu. Nesúvisí vôbec s projektom ako takým a je závislý čisto od faktorov, ktoré nie sú projektom ovplyvnené - subjektívnu spokojnosť neviete garantovať.
Alebo očakávate, že sťažnosti budú chodiť vo väčšej miere oprávnene?
OK VYRIEŠENÉ
V súčsnosti je v MetaIS evidovaných aj pár služieb, ktoré tu nie sú uvedené a sú zrejme typu G2E - teda služby alebo skôr funkcionality systému, ktoré obsluhuje zamestnanec OVM. Napr. Detail položky Koncová služba, Sprostredkovanie poskytnutia adresnej pomoci | MetaIS
Ak sa jedná o službu, ktorú nepoužíva a nespúšťa občan/podnikateľ, ale zamestnanec OVM, tak sa jedná o typ G2E .
Zároveň som sa v inom komentári pýtala na popis služieb a bola som odkázaná na kapitolu 3.6, ale tu nie sú popísané všetky služby, a tak nie je možné určiť, čo je pre občana a čo pre zamestnanca OVM
prosím aktualizovať harmonogram
kde sú zvyšné alternatívy?
tu boli nejaké alternatívy?
v projekte - CBA - nie sú žiadne ďalšie náklady, iba licencie
úroveň elektronizácie určite nie 1 - pozrite si https://www.slov-lex.sk/ezbierky-fe/pravne-predpisy/SK/ZZ/2020/78/#paragraf-34.odsek-1.pismeno-a
predpokladám, že ak sú služby komplet elektronické, tak úroveň 4. Dokonca pri proaktívnych je to úroveň 5. Čiže ak napr. proaktívne poskytujete energopomoc, tak je to 5
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.
https://www.slov-lex.sk/ezbierky-fe/pravne-predpisy/SK/ZZ/2019/95/#paragraf-15.odsek-2