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

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

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

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

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.

Dokument je nekompletny, chybaju texty k mnohym bodom v kapitolach 2. - 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

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.

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’.