Ppripomienkovanie: Strategická priorita “multikanálový prístup“

Pripomienkovanie
1

Strategická priorita “multikanálový prístup “ - veci čo sú podľa nás v tejto oblasti dôležité + pripomienky k dokumentu - http://informatizacia.sk/ext_dok-01_ea_sp_multikanalovy_pristup_v01/22723c

2

Vyhodit alebo zdovodnit pouzitie socialnych sieti ako komunikacneho kanalu, lebo v mojom ponimani je to len ina forma specializovaneho portalu. A technologia je rovnaka ako webovy prehliadac.
Kapitola 1.2

3

Zjednodusenie tvorby elektronickych formularov

Sucastny stav: nutna reimplementacia vyplnaca formularov v roznych systemoch OVM a nejednotne datove struktury.
Navrh: Pripravit jednotny format vyplnacov alebo vyuzit existujuci napr XForms. Pripravit zakladne datove formaty spolocne data a vyuzivat eixstujuce medzinarodne normy (napr pre datum je iso 8601). Publikovat zoznam datovych formatov dostupny pre vsetkych
Vyhody: Nizsia narocnost pri implementacii produkcnych systemov a jednotne formaty zakladnych dat, tym padom jednoduchsie zverjenenie a prelinkovanie dat

4

Zjednodusenie pristupu k elektronickym sluzbam
Sucastny stav: moznost komunikvoat iba cez eid a iba na pc
Navrh: zjednodusit pristup k eletronickym sluzbam cez ine technologie navrhnutim a implementovanim alternativ k eid, ktore budu mat obmedzenu funkcionalitu. Priklady, cez telefony/tablety pouzivate HOTP (https://tools.ietf.org/html/rfc4226) alebo TOTP (https://tools.ietf.org/html/rfc6238) a aktivovali sa podobne ako ma tatrabanka citacku. Dalo by sa pouzit pre telefonicky kanal.
Zaroven identifikovat sluzby statu ktore vyzaduju autentifikaciu a autorizaciu ale nie az taku aby bol vyzadovany uradne overeny podpis(notar) alebo zep. Tieto sluzby by sa mali dat autorizovat podobnym sposobom ako vyssie spomenuta autentifikacia.

5

Dokument je nekompletny, chybaju texty k mnohym bodom v kapitolach 2. - 6.

6

cely multi pristup je v dokumente viac menej redukovany na elektronicke formulare. (az na kapitolu 1.2, kde to je v poriadku)

ostatne kanaly nie su vobec rozpracovane bud je dokument zle scopovany alebo ma k dokonceniu veeelmi daleko.

inak vzhladom na stav dokumentu tam asi nie je velmi co vycitat

7

Neviem ci to patri sem, ale ako temu by som navrhol aj zjednodusenie technickeho pristupu k upvs, zjednudusenie procesu vytvarania technickych pouzivatelov, lebo pisanie a spracovananie integracnych zamerov je komplikovane a zdlhave pre pravnicke osoby a hadam aj nemozne pre fyzicke osoby.

8

Chapem, ze je to len prva pracovna verzia dokumentu, takze vela veci tam este chyba.
Tu je vsak niekolko mojich postrehov:

  • V uvode nieje dobre vysvetlene aky je ucel dokumentu a akej cielovej skupine je urceny.

Mozno to znie ako banalna pripomienka, ale kym to nieje jasne, tak sa da len velmi tazko vyjadrovat k obsahu dokumentu.
Predpokladam, ze dokument vychadza z dokumentu ‘Narodna Koncepcia Informatizacie Verejnej Spravy’ (NKIVS) a jeho cielom je dalej rozpracovat strategicku prioritu ‘Multikanalovy Pristup’ a predstavit technicky koncept ako ma byt tato priorita realizovana.
Cize dokument je urceny pre technicke publikum ako su architekti jednotlivych OVM, integracni testeri ale aj projektovi manazeri atd. a ma im pomoct aplikovat tuto prioritu na ich urovni.

Ak je moje chapanie ucelu dokumentu spravne, tak dokument sa v sucasnej forme zameriava na popis high-level poziadaviek, cize CO treba urobit, ale bohuzial obsahuje len velmi malo informacii o tom AKO sa to ma urobit. Podla mna by bolo dobre, ak by to bolo dopracovane v dalsich verziach dokumentu.

Napr. pre ilustraciu skusim detailnejsie rozobrat kapitolu ‘2 Prvok Inteligentne elektronicke formulare’.
(podobne pripomienky by sa vsak dali aplikovat aj na ostatne ‘prvky’)

2.1.1 Architektonicky ciel:
• Vytvorenie predpokladov pre pouzivanie inteligentnych elektronickych formularov.

Ciel znie velmi abstraktne. Ocakaval by som, ze bude specifikovany trocha konkretnejsie a ze bude tiez konkretnejsie adresovat niektore architektonicky relevantne poziadavky, ktore su specifikovane v NKIVS v kapitole ‘3.2 Principy informatizacie verejnej spravy’.

Napr. nieco v zmysle, ze cielom je vytvorit referencny design (metodiku) elektronickeho formulara, ktory:

  • umozni jednotlivym OVM jednotnym sposobom vytvarat, publikovat a udrziavat ich vlastne formulare.
  • bude vyuzivat schvaleny standard na komunikaciu s backendovymi servismi.
  • bude mat pri komunikacii s backendovymi servismi pozadovanu rychlost.
  • poskytne ochranu citlivych udajov.
  • …

2.3.3 Strategicky pristup k rieseniu:
V sucasnej verzii dokumentu sa tu len velmi strucne popisuje, ze riesenim je zavedenie moznosti definovat priamo vo formulari ze ake backendove sluzby bude formaular vyuzivat.
V tejto kapitole by som v dalsich verziach dokumentu ocakaval detailnejsi popis AKO bude formular technicky realizovany (stacia hlavne principy) a tiez AKO bude fungovat v hlavnych use-cases. To znamena, ‘vytvorenie noveho formulara’, ‘publikovanie formulara’ a ‘komunikacia s backendovymi servismi’.