Tema c.1: Pripomienky k navrhu NKIVS v MPK

Elektronicka uloha sa tyka uradnika, ide o pokyn, co ma vyriesit dokedy. Uloha sa da delegovat, odsunut, vyriesit, etc, chceme vytvorit funkcny Task management. V ramci pripadu moze byt viacero uloh. IS sluzba moze generovat elektronicku ulohu.

Len to nie je definovane… Cize povitat mozu skoro cokolvek…

Ale v dokumente, na ktory si dal link uz aktualne hodnoty su…

Ku kapitole: 3.2.1
Biznis princípy, prvý bod
Ako sú/budú organizovaní správcovia?

Ku kapitole: 3.2.4
Technologická interoperabilita - chýba mi odkaz na existujúce štandardy a príslušnú metodológiu

Ku kapitole: 3.3
predposledný odstavec na strane 11
Mechanizmus kontroly a odpočtu dosiahnutia definovaných cieľov na ročnej báze je nedotatočný, interval treba skrátiť. Na tejto báze nie je možné efektívne zachytiť a reagovať na prípadné negatívne udalosti a trendy.

Ku kapitole: 3.3
prvý odstavec na strane 12
Ambícia vytvoriť špeciálne nástroje a služby pre obstarávanie IT…
Doplniť o odkazy na aktuálne aktivity v tejto oblasti.

Ku kapitole: 3.3
prvý odstavec na strane 13
Neuvažuje sa o vytvorenie centrálneho testovacieho tímu?

Ku kapitole: 6.2.4
Obrázok č. 5 na strane 12
Neuvažuje sa o pripojení aj iných ministerstiev (napr. MPSVaR)?

Ku kapitole: 6.2.9
Je nutné, aby sieťové vrstvy (OSI Reference Model) prešli do vlastníctva štátu?

Ku kap. 5:
Toto nie je pripomienka, ale (zatiaľ) otázka na diskusiu: viete mi prosím vysvetliť zmysel tejto kapitoly?

Ku kap. 6:
Vložiť do textu mechanizmus, že súvisiace podrobné dokumenty pre jednotlivé prioritné okruhy (t.j. subkapitoly pod 6) budú vytvorené, záväzné, aká bude ich štruktúra a pri ich tvorbe bude participácia/pripomienkovanie. Každá kapitola má obsahovať určite aj zhodnotenie súčasného stavu, odôvodnenie zvoleného riešenia, harmonogram plánovaných aktivít, plán legislatívneho pokrytia.
Prečo: Na úrovni NKIVS sú iba stručné charakteristiky hlavných tém riešených v jednotlivých kapitolách. Bez detailného popisu častokrát nie je zrejmé čo / ako / prečo má byť robené.

Ku kap. 3.2.1:
Doplniť biznis princíp: Orientácia na klienta (veľkými písmenami) - Verejná správa aktívne pracuje so skupinami klientov s cieľom vytvoriť také služby, ktoré sú klientmi vyžadované alebo preferované, a sú pre klienta jednoducho použiteľné. Verejná správa vzdeláva klientov svojich služieb o tom, aké služby sú vytvorené, ako sa používajú.
Ku kap. 3:
Doplniť samostatnú subkapitolu v ktorej budú popísané mechanizmy, prispievajúce k realizácii biznis princípov Proaktivita, Spätná väzba, Orientácia na klienta, ktoré nie sú súčasťou architektúry VS a ich realizácia nie je podmienená technologickým riešením. Ide najmä o mechanizmy komunikácie VS s verejnosťou, informovanie a vzdelávanie používateľov služieb eGovernmentu, podporu používateľov pri interakcii s VS a prispôsobenie zvolených riešení potrebám používateľov.
Prečo: V súčasnosti práve oblať práce s klientmi služieb - či už predchádzajúca implementácii riešení eGovernmentu, alebo následná - je zásadne nedostatočná. Zatiaľ nie je nijako systematicky rozpracovaná ani v predloženom materiály.

Ku kap. 3.2.3:
Doplniť aplikačný princíp: Modulárnosť - Aplikácie IKT sú členené na menšie samostatné časti, ktoré sú prepojené dobre definovanými rozhraniami s cieľom zvýšiť flexibilitu riešení.

Ku kap. 3.2.4:
Doplniť technologický princíp: Otvorenosť aplikačných rozhraní - Aplikačné rozhrania v IS sú budované spôsobom umožňujúcim ich použitie komukoľvek (po splnení určených podmienok). Špecificky všetky funkcie IS, ktoré sú dostupné grafickým rozhraním majú byť dostupné aj otvoreným aplikačným rozhraním.
Prečo: OpenAPI je dôležitý princíp, ktorý ak bude použitý ako základný architektonický princíp, napomôže aj v realizácii ďalších tém (napr. v oblasti multikanálového prístupu).

Ku kap. 3.3:
Popis aktuálneho stavu žiadame formalizovať do samostatného dokumentu, pre ktorý bude uvedené jeho štruktúra, spôsob participácie/pripomienkovania. Dokument má obsahovať aj popis dôležitých alebo akútnych charakteristík a plán ich riešenia (napr. povinná aktivácia el. schránok pre PO plánovaná na polovicu r.2016 a ako zaistiť aby sa aspoň vedeli prihlásiť do schránky). Dokument má byť aktualizovaný v rovnakej preiodicite ako NKIVS a predkladaný spolu s každoročným vyhodnotením jej plnenia.

Ku kap. 3 a uzneseniam:
Doplniť povinnosť pre správcov IS pri zmene špecializovanej legislatívy zaistiť aj realizáciu princípov potrebných na naplnenie NKIVS, najmä pre OpenAPI, OpenData, 1-krát a dosť, Multikanálový prístup.
Prečo: Keď už sa mení niektorý zákon, nech sa v ňom rovno vyriešiť, aby sa daná doména mohľa ľahko realizovať podľa NKIVS.

Ku kap. 3.3:
V tejto kapitole je stručne načrtnutá problematika VO IKT. Túto oblasť treba rozpracovať na podrobnejšej úrovni.
Prečo: MF aj pri rušení niektorých uznesení z Miklošovho desatora argumentovalo, že v NKIVS sú obsiahnuté záväzné princípy pre oblasť riadenia projektov.

Ku kap. 3.3:
Žiadame z formulácie “budú zverejňované ako otvorené dátaa cez centrálnu platformu” vypustiť slová “cez centrálnu platformu”.
Prečo: Nech si každý publikuje kde je to najvýhodnejšie, napr. ako API u seba. Určite už nie ďalšie centrálne úložiská pod hlavičkou OpenData.

Ku kap. 3.4:
Tento dokument sa týka celej informatizácie, nielen OPII. Žiadame tam popísať, ako sa to bude vzťahovať na všetkých.

Ku kap.4:
Žiadame v samostatnej kapitole popísať postup prechodu od existujúceho stavu k cieľovému, zachytenému v NKIVS. Dôraz musí byť dávaný na potrebné zmenu v už vybudovaných IS a na plán nabiehania nových komponentov. Myslíme si, že postupný prechod by mal obsahovať aj nasledovné kroky: vyhodnotenie inštitúcie, ako spĺňa pripravenosť na prechod k cieľovému stavu podľa podrobnej metodiky, vytvorenie plánu organizácie prechodu k cieľovému stavu, podpora “malých” projektov na úpravu existujúcich riešení, automatická realizácia potrebných riešení v nových projektoch.

Ku kap. 6.1:
V odrážkach ku stavebnému bloku “požívateľ má k dispozícii jednotný konfigurovateľný … komponent (tzv. portfólo klienta)” doplniť požiadavku, že všetky uvedené informácie / služby budú dostupné aj cez OpenAPI.

Ku kap. 6.2.1:
Žiadame uviesť strategické rozhodnutie, koľko budeme mať štátnych portálov / schránok, resp. ako bude zaistené že sa predíde duplicitám a zvolené bude najefektívnejšie riešenie.

Ku kap. 6.2.1:
V žiadame doplniť medzi komunikačné kanály “aplikačné rozhranie / OpenAPI”.

Ku kap. 6.2.5:
Žiadame doplniť do obrázka škatuľku “príručná registratúra / obeh dokumentov”.
Prečo: táto škatuľka je dôležitá pre monitorovanie, čo/kto/ako dlho pri spracovaní podania robí, sledovať termíny.

Ku kap 6.2.6:
Žiadame upresniť vetu “údaje naďalej zostávajú vo vlastníctve povinnej osoby”. Nie je jasné o čo ied

Ku kap. 6.2.6:
Žiadame doplniť špecifické mechanizmy zvyšovania kvality udajov a prepájania údajov medzi povinnými osobami (napr. že niektoré údaje už povinná osoba nebude evidovať, lebo je online dostupná

Ku kap. 6.2.7:
Žiadame doplniť aj body že OpenData majú byť použiteľné na právne účely a aby údaje povine zverejňovnané podľa osobitných predpisov bolo možné použiť ako OpenData.

Ku kap. 6.2.8
Žiadame doplniť možnosť použiť aj (za splnenie určitých podmienok:) privátnu dátovú sieť.

Ku kap. 6.2.9:
Žiadame vylúčiť návrhy na prechod fyzickej vrstvy do vlastníctva štátu.

Ku kap. 7:
…to be continued zajtra

Ku kapitole: celý dokument
Pripomienka: NKIVS pomerne detailne rozpracováva zámery v oblasti architektúry verejnej správy (predmet informatizácie verejnej správy). V dokumente však absentujú koncepčné zámery týkajúce sa procesu informatizácie verejnej správy. Za takú oblasť považujeme aj koncept riadenia informatizácie, prislúchajúce právomoci a rozvoj ľudských zdrojov, nad rámec riadenia architektúry, ktorý je v NKIVS načrtnutý. Navrhujeme dopracovať dokument pre túto oblasť, predovšetkým v kapitolách 2, 3 a 6. Predovšetkým navrhujeme vysporiadať sa s otázkami ako napr. úroveň centralizácie zodpovednosti za informatizáciu versus decentralizovaný model riadenia, rozvoj kapacít na strane verejnej správy vs. outcourcing, waterfall vs. agile prístup k vývoju, zámery pre oblasť spolupráce so širším okolím zainteresovaných strán (neziskový sektor, IT sektor, akadémia).
Odôvodnenie: Domnievame sa, že NKIVS by sa mala venovať aj kontextu, v akom sa má budovať architektúra verejnej správy a stanoviť zámery pre kľúčové oblasti tohto kontextu.

Ku kapitole: celý dokument
Pripomienka: NKIVS pomerne detailne rozpracováva zámery v oblasti architektúry verejnej správy (predmet informatizácie verejnej správy). V dokumente však absentujú koncepčné zámery týkajúce sa procesu informatizácie verejnej správy. Za takú oblasť považujeme aj zámery pre oblasť dosahovania vyššej efektívnosti IT investícií. Navrhujeme dopracovať dokument pre túto oblasť, predovšetkým v kapitolách 2, 3 a 6. Predovšetkým navrhujeme adresovať nasledovné oblasti: zámery v oblasti postupov a metód pri nákupe IT, zámery na podporu konkurencie v sektore IT verejnej správy, zámery v oblasti merania hodnoty za peniaze a aplikácie zahraničných best practice pre hodnotenie prínosov a nákladov IT investícií.
Odôvodnenie: Domnievame sa, že NKIVS by sa mala venovať aj kontextu, v akom sa má budovať architektúra verejnej správy a stanoviť zámery pre kľúčové oblasti tohto kontextu.

Ku kapitole: celý dokument
Pripomienka: NKIVS pomerne detailne rozpracováva zámery v oblasti architektúry verejnej správy (predmet informatizácie verejnej správy). V dokumente však absentujú koncepčné zámery týkajúce sa procesu informatizácie verejnej správy. Za takú oblasť považujeme aj zámery pre procey zvyšovania pridanej hodnoty pre používateľov. Navrhujeme dopracovať dokument pre túto oblasť, predovšetkým v kapitolách 2, 3 a 6. Predovšetkým navrhujeme adresovať nasledovné oblasti: zavedenie mechanizmov pre verejnú participáciu pri zbere požiadaviek na elektronické služby, zavedenie verejného testovania prototypov, zavedenie jednotného dizajn manuálu pre elektronické služby.
Odôvodnenie: Domnievame sa, že NKIVS by sa mala venovať aj kontextu, v akom sa má budovať architektúra verejnej správy a stanoviť zámery pre kľúčové oblasti tohto kontextu.

Ku kapitole: celý dokument
Pripomienka: NKIVS pomerne detailne rozpracováva zámery v oblasti architektúry verejnej správy (predmet informatizácie verejnej správy). V dokumente však absentujú koncepčné zámery týkajúce sa procesu informatizácie verejnej správy. Za takú oblasť považujeme aj zámery pre oblasť transparentnosti procesu (zverejňovanie dokumentácie a rozhodnutí) a obsahu (informačných systémov a rozhraní) informatizácie. Navrhujeme dopracovať dokument pre túto oblasť, predovšetkým v kapitolách 2, 3 a 6. Predovšetkým navrhujeme adresovať nasledovné oblasti: zámery v oblasti zverejňovania kľúčovej dokumentácie na verejné pripomienkovanie, zámery v oblasti transparentných dodávateľských vzťahov, zámery v oblasti sprístupnenia rozhraní ISVS.
Odôvodnenie: Domnievame sa, že NKIVS by sa mala venovať aj kontextu, v akom sa má budovať architektúra verejnej správy a stanoviť zámery pre kľúčové oblasti tohto kontextu.

Ku kapitole: celý dokument
Pripomienka: Z dokumentu nie je jasné, aké ciele sa sledujú z pohľadu hlavných zainteresovaných strán eGovernmentu, t.j. z pohľadu občana a podnikateľa, resp. z pohľadu úradníka. Cieľový stav z pohľadu občana je načrtnutý v kapitole 6.1, ale tá nemá charakter cieľov.
Odôvodnenie: NKIVS popisuje na viacerých miestach zámery, ale chýba konsolidujúci pohľad prínosov pre hlavné zainteresované strany.

Ku kapitole: Celý dokument
Pripomienka: V dokumente absentuje popis procesov riadenia a zodpovedností, ktorými sa NKIVS bude implementovať do praxe - napr. vo vzťahu na aktuálny legislatívny zámer zákona o informačných technológiách verejnej správy, resp. aktuálne platnú legislatívnu úpravu podľa zákona o ISVS.
Odôvodnenie: Domnievame sa, že bez popisov riadiacich procesov je dokument nevykonateľný.

Ku kapitole: Celý dokument
Pripomienka: V dokumente absentuje popis zámerov pre spoluprácu so zainteresovanými stranami ako napr. neziskový sektor, IT sektor, akademická obec, pri dosahovaní cieľov NKIVS. Navrhujeme túto oblasť bližšie rozpracovať.
Odôvodnenie: Domnievame sa, že pre úspech NKIVS je potrebné aktívne riadiť vzťahy s kľúčovými zainteresovanými stranami.

Ku kapitole: 2 a kapitole 3.1
Pripomienka: Požadujeme jednoznačne uviesť merateľné ciele NKIVS, ktoré sa ňou dosiahnu.
Odôvodnenie: Odkaz na ukazovatele pre oblasť rozvoja informačnej spoločnosti 2014-2020 stanovuje len indikátory, ku ktorým NKIVS prispieva, ale nie sú explicitne definované ciele, ktoré má samotná NKIVS naplniť. Navyše, indikátory pre oblasť rozvoja informačnej spoločnosti 2014-2020 nekorešpondujú plne s cieľmi NKIVS.

Ku kapitole: 3.2.1
Pripomienka: Navrhujeme doplniť biznis princíp Efektívnosť - informatizácia verejnej správy sleduje najvyššiu hodnotu za peniaze

Ku kapitole: 3.2.1
Pripomienka: Navrhujeme doplniť biznis princíp Pridaná hodnota - informatizácia verejnej správy prebieha na základe kontinuálneho vyhodnocovania nákladov a prínosov a ich zvažovania pri rozhodovaní

Ku kapitole**: 3.3
Pripomienka: Navrhujeme doplnenie a rozpracovanie úrovne “zdroje”, ktorá by mala pokrývať zámery v oblasti ľudských, finančných a technických zdrojov pre implementáciu NKIVS.
Odôvodnenie: Profesionalizácia kapacít a ľudských zdrojov na strane verejnej správy je predpokladom, bez splnenia ktorého bude dosiahnutie zámerov NKIVS ohrozené. Za rovnako dôležité považujeme ujasnenie zámerov v oblasti financovania informatizácie verejnej správy do roku 2020.

Ku kapitole: 6.1
Pripomienka: Navrhujeme uvedené požiadavky naviazať a zohľadniť v návrhu merateľných cieľov, ktoré sa majú do roku 2020 dosiahnuť.
Odôvodnenie: Požiadavky považujeme za veľmi relevantné, nie je však jasná ich väzba na ciele NKIVS.

Ku kapitole: 6.2
Pripomienka: Nie je jasná väzba cieľov (kap. 3.1), úrovní (kap. 3.3), princípov (3.2) a strategických priorít (kap. 6.2) informatizácie. Navrhujeme tieto kapitoly lepšie logicky previazať. Nie je jasné, z čoho vychádzajú priority informatizácie.
Odôvodnenie: Predpokladom vykonateľnosti koncepcie je podľa nášho názoru jasná väzba medzi cieľmi, prioritami a zámermi, ktoré ich majú naplniť.

2 Likes

Na toto presne slúži Motivation diagram v Archimate. Keď už to obsahuje iné Archimate diagramy, asi by bolo vhodné práve toto demonštrovať aj graficky. Zároveň by to bol aj vzor, lebo jednotlivé štúdie usk. by mali naplňať tie isté ciele a princípy ako NKIVS, resp. ich podmnožinu + Ďalšie rezortné, odvetvové, či agendové ciele …

Slovo zámer mi tu neštimuje, ináč výborný postreh. Asi by som foruloval: V dokumente chýba popis spôsobu spolupráce, resp. participácie s ďalšími zainteresovanými stranami ako napr. neziskový sektor, IT sektor, akademická obec, ktoré sa na plnení cieľov NKIVS prirodzene podieľajú , alebo môžu podieľať.

Toto by som neriešil. Vedie to k otázke kde je hranica modulu … .a toto je na akademickú diskusiu. Modulárnosť sa musí dosiahnuť dobrým návrhom (ak sa obstaráva na zelenej lúke). Už vypísanie samotného obstarania môže determinovať hranice modulárnosti … Sú aj iné znaky dobrej architektúry … ako napríklad Continuous Refactoring, resp. continuous Integration … a tie si nevypichol … Skôr by som sa zamyslel ako znaky dobrej architektúry dostať do hodnotiacich kritérii verejného obstarania a znížiť váhu ceny … Lebo projekty môžu dopadnúť ako poľská dialnica za eurofondy, kde čínska firma ponúkla najnižšiu cenu, ale potom zistila že to nie je schopná vytvoriť … (u softvéru je ešte to nebezpečie, že furt “niečo” vyrobiť pôjde … ale nemusí to fungovať, resp. bude to vyzerať hrozne)

Váhu ceny (kritérium) je možné “znížiť” vybratím iného postupu VO. Prečo však aplikovať iné postupy VO, keď môžeme dekomponovať predmet (resp. dostať to do koncepcie a potom z toho ťažiť) a tento dekomponovaný/atomický predmet obstarávať v menších súťažiach, ktoré nebudú mať také nároky na záujemcov/uchádzačov. Stále tu zostáva “problém” s integráciou takýchto obstarávaní, resp. ich výsledkov ale to sa deje už dnes, keď prime si vyberá subconov. Preto táto pripomienka. Môžeme pracovať na jej formulácii ale zámer je predpokladám tento.

Konsolidovane pripomienky k NKIVS z celej platformy su tu: https://docs.google.com/document/d/1osKeaMejoENaCZT_7IoWS125riiBHz3OqiVsaFPTv_4/edit?usp=sharing

Zajtra rozbiehame podpisovanie hromadnej pripomienky

3 Likes

ešte ma napdalo, či nepridať do NKIVS povinnú preferenciu tej europskej otvorenej licencie pre všetky custom kody dodávané pre OVM …
Zatiaľ to všade visí len ako odporúčanie, čo je iba iné slovo pre “ignorovateľné” …

1 Like

:slight_smile: jeeej na zive.sk ich EUPL zaujalo :slight_smile:

2 Likes

Ak by doslo k nejakym diskusiam… Pridal by som to medzi Principy, ktore musi architektura splnat. Podobne ako je princip statny cloud prednostne, moze byt aj eupl prednostne.
To bude nutit akvs (uvo) toto kontrolovat v obstarkach, ci pripravovanych zmluvach.

ako toto pripomienkovanie pokračuje ?

Stále čakáme na reakciu MF, ktoré by malo zvolať stretnutie. Ponúkli sme,
že si radi pripomienky prejdeme aj mimo oficiálneho procesu. Čakáme :slight_smile:

1 Like

ale takymto tempom … vsetko co sa tu chce urobit bude relevantne az od roku 2020 :slight_smile:

1 Like

To je zakladna taktika hrat o cas :slight_smile: oficialne spolupracuju ale len na oko. Ved tak dopadli vsetky tie komisie a pracovne skupiny na MF…

ale momentalne sa caka aj na urcite organizacne zmeny a mozno aj personalne zmeny, tak uvidime ako to dopadne…

2 Likes

Rozporové konanie bude 10.5. od 13:30, viď. aj

Informacie k tomu ako nakoniec skoncil proces s NKIVS su tu: Materiály k národnej koncepcii informatizácie verejnej správy

Dakujem vsetkym v pracovnej skupine, ktori prispeli pripomienkami. Nasa snaha o yasadne vylepsenie tohto dokumentu teda pokracuje dalej.