MIRRI Pracovná skupina K9.5 Lepšie služby

Vyhlasujem

NEOBCHODNÚ VEREJNÚ SÚŤAŽ

v rámci projektu ZDRAVÝ ROZUM
v Národnej koncepcii informatizácie verejnej správy (NKIVS) sa používa množstvo akronymov a skratiek, ktorým už nikto asi nerozumie. Preto dochádza k nedorozumeniam medzi odborníkmi v danej oblasti, informatikmi, štátnymi úradníkmi aj OVM. Nerozumie im ani OBČAN a nevie sa orientovať v elektronických službách.

Opatrenie 1. Inovácie - OPERAČNÝ PROGRAM “ABY SME SI ROZUMELI”

  • Predmet dodávky: vytvorenie webu
  • Technické špecifikácie a opis predmetu zákazky: predmetom dodávky má byť slovník, glosár skratiek a pojmov používaných v informatizácii, v ktorom sa dá rýchlo hľadať, triediť, obsahuje aj legislatívne normy a iné štátne dokumenty.

Vo väčšine týchto dokumentov je slovník skratiek a pojmov, ale v každom dokumente sa niektoré skratky opakujú a niektoré sú nové. Dokumenty sú v pdf, niektoré naskenované.

Podklady pracne pripravujem už viac ako pol roka, mám tam asi 600 pojmov, viem už presne definovať ako to má fungovať

  • Rozpočtové náklady: neviem
  • Podmienky súťaže: vyhrá ten, kto ponúkne najnižšiu cenu

Nájde sa tu niekto, kto mi pomôže?

Toto by sa mohlo hodiť: http://www.informatizacia.sk/ext_dok-metodicky_pokyn_glosar_pojmov/3482c

Velmi pekne dakujem, toto uz mame spracovane.

Ak významne početná skupina užívateľov odmietne nefungujúce služby, štát to bude musieť riešiť.

Moc v štáte pochádza od občanov, jednoducho vo voľbách budú voliť tých predstaviteľov, ktorí nenútia občanov používať nefungujúce elektronické služby.

Vazim si kazdeho co sa pusti do citania tychto dokumentov. Napriklad NKIVS (dakujem za upozornenie, preklep opraveny).

Obavam sa v sak, ze v tomto pripade ide len o nepochopenie.

image

Tieto dokumenty nemaju riesit jednotlive sluzby ani nejake ich vylepsovanie. Tu sa riesia vysokourovnove principy/architektura a pripadne z toho vyplyvajuca legislativa. Samozrejme poznamka, ze velmi dolezita skupina su “odbornici”, je na mieste, avsak z pohladu IS je to jednoducho len dalsi typ pouzivatelov systemu. A pre kazdy ISVS musia byt jasne identifikovani v studiach, poziadavkach na softver, atd.

Pridavam zapis zo stretnutia 13.9.2017

  • pracuje sa v dvojiciach - architekt + programovy manazer
  • manazer bude z dokumentov robit portfolio projektov
  • velkou temou je zmena “paradigmy” - uz sa robia podania nie centralne ale decentralizovane
  • ppp: netyka sa to len iomo, ale aj centralny elektronicky priecinok
  • dolezite su aj tradicne kanaly, kamenne pobocky nezomreli ani v komercii
  • co bude autorizacia klikom po novom (ppp nevie co to je, nases sa pyta tiez)
  • zmena egov zakona + referencna arch => znamena to zmenu aj sucasnych systemov (aj centralnych) - je tam rozvoj alebo sa stare projekty zrusia?
  • centralizacia tlace - problem - verifikovalnost (kopec specialnych pripadov)
  • pre kazdy centralny modul - riziko SPOF - aky je postup pre kriticke systemy?
    • to je vec studie
  • buduci tyzden tvorba podani v decentrovanych miestach (IOM!!!)
  • o dva tyzdne - platby - ekolok + statna pokladnica + platba kartou
  • dizajn manual do konca roka - riesi sa na standarizacii

Ak niekto mate nieco na srdci k najblizsim temam tak prosim sem. K IOMO/formularom/centralizacii sa myslim uz dost pisalo tu za zmienku stoji aj assisted digital v UK:

Types of assisted digital support
The support you provide can be either:

  • someone guiding a user through the digital service
  • someone entering the user’s information into the service on their behalf

A dalej tu Designing assisted digital support - Service Manual - GOV.UK

Zapis z dnes. V principe sa velku cast casu hovorilo o IOMO ako to zapada do noveho decentralizovaneho modelu. Bola pekna prezentacia, ktora hovorila preco sa to neda a co vsetko by bolo treba, aby to slo. Ako najvacsie vytky (ktore sa uz neriesia) si pamatam:

  • preco sa to neda zjednodusene
    • auditovanie
    • skenovanie zarucenej konverzie
    • nepodporovanie
  • organizacne hladisko
    • desiatky portalov, rozne sposoby - kto to zaskoli?
    • ak sa nieco zmeni, tak mozno bude musiet zmenit procesy?
  • bezpecnostne hladisko
    • na matrike/poste odmietli IOMO lebo nechcu nejaku tretiu stranu co maju mimo kontroly
    • posta, matrika nechce pustit aplikacie tretich stran (redirect je problem)
    • riesenim by bol bezpecnostny audit poskytovatela
  • KPI
    • v OPISe boli nastavene nejake KPI na IOMO a toto ich nejako kazi (nebolo povedane ake)

Oponovanie:

  • biznis case iomo je velky problem, napriklad to chceli dat do dcom, ale obce to odmietli, ze sa im tam neoplati drzat cloveka
  • pri IOMO treba znizit ocakavania, predstava, ze pridem na hocijaku pobocku a tam hocico za mna spravia je iluzia. Za ovela lepsi koncept povazujem asistovane podanie = bude tam zauceny brigadnik co vie ovladat normalne PC a pomoze vyplnit podanie.

Na zaver sa riesila zlahka pointa registra rozhodnuti

  • centralny register rozhodnuti
  • aby s nedali antidatovat rovnopisy, v zakone je diera
  • problem: bude sa davat ako priloha len rozhodnutie alebo cely obsah rozhodnutia? (mozu tam byt osobne udaje, zdravotne zaznamy, etc
  • problem: aj ked si uradnik bude vediet overit, ze rozhodnutie je validne, asi tazko dohlada, ze medzicasom neprislo ine rozhodnutie, ktore mozno uz meni stav. preto pointa referencnych udajov je ovela schodnejsia cesta. na nejake usecasy by sa vsak register rozhodnuti mohol hodit.

Moje poznamky k tomu pod ciarou:

  • viac krat bolo argumentovane, ze sme v SP Multikanalovy pristup zvolili strategiu 3V = vsetko vsade a teda na IOMO musi byt vsetko. Overoval som to a ta historia je inak. (cc @ret pre osviezenie pamate) Tu na platforme je zaznam, ze povodny zamer bol nie vsetko vsade, ale len tam kde to ma zmysel toto sme v pripomienkovom konani dokonca rozporovali a vo vyslednom dokumente bolo zapracovane upravene znenie.

image

Prosim @michalblazej a @ret ustrazit tento duch vykladu aj v spominanom manuali pre tvorbu koncovych sluzieb VS SR.

  • bezpecnost: Nebolo povedane, aka hrozba vadi poste/matrike ked sa povoli zobrazovanie specializovach portalov. Z mojho pohladu je toto trosku FUD, kedze specializovane portaly predsa tiez musia podliehat nejakym bezpecnostnym standardom. Ak by specializovany kanal ohrozil IOM malwarom, tak v prvom rade ohrozuje aj celu populaciu co ten kanal chce pouzit mimo IOM.

  • IOMO je v pricipe case study na open api. Kedze z neho vypadli usecasy, ktore je potrebne riesti aj pre akekolvek api tretich stran - auditovanie, zastupovanie,…

1 Like

@jsuchal ja som urcite bol proti 3V a tlacil som len tam kde to ma zmysel, ale nakoniec sa politicky pretlacilo vsetko vsade. Tomas vsak este aj na poslednom stretnuti, kde som bol ja, povedal, ze “budeme rozvijat vsetky kanaly rovnomerne, ale tam kde to ma zmysel”. Takze neviem co sa hovorilo dnes, kedze som na stretnuti nebol, ale doposial stale platilo, ze to musi byt zmysluplne.

1 Like

To bola asi moja chyba dnes… Zabudol som ze vlastne sme to takto uzavreli ako napisal Jano. Kazdopadne zaver sme k tomuto nevedeli dat a je potrebne to rozpracovat viac do detailu a vyhodnotit alternativy

Skor vidim problem v tom manualy, ja ho neriesim… a neviem kto ho riesi na urade… jedine co zatial mame je Misova ppt zo standardizacnej komisie a to tiez iba pre HCD procesy tvorby sluzieb. Takze momentalne service-channel fit nevedia nejakym standardnym sposobom poslytovatelia sluzieb vykonat.

1 Like

Bud to dame do uvodu dizajn manualu alebo k tebe do dokumentu.

1 Like

@jsuchal ma poprosil, aby som spravil zapis z dnesnej skupiny. Chyby v zapise su mozne. Nie som dobrym zapisovatelom, nikto ma za to neplati :smiley:

  • Tono Somora (ITAS) / p. Fric sa budu stazovat kvoli deadlineom, ktore stanovil urad na dodanie vystupnych dokumentov, pretoze nie je dost priestoru na spatnu vazbu
  • Tomas Revaj prezentoval riesenie eplatieb cez vystavanie samostatnej platformy podla PS2 (vid. prezi)
    • Najvacsi problem bol neexistencia garancie platby ak by dana banka skrachovala. Mechanizmus musi byt zahrnuty v legislative a do riesenia musi vstupit statna pokladnica.
    • Otazne je, ci je to skutocne najvacsi problem, lebo v dalsej casti diskusie to bolo spochybnene.
  • p. Hettes prezentoval ekolky
    • Tu garancia tiez neexistuje, pretoze peniaze su na zbernom ucte v PABK 30 dni. Cela tema je vraj teraz ovela viac relevantna kvoli tomu, ze skrachovala AG banka (teraz?).
    • dovod pre 30 dnove oneskorenie je aj to, ze sa niekedy musia vratit peniaze (neskor spochybnene)
    • p. Fric chce mat vsetky platby v statnej sprave zjednotene. Otazka je, ci maju vsetci mat ekolky (a defacto teda zmenit zberny ucet zo statnej pokladnice daneho uradu / operatora IOM na kolkovy zberny ucet)
  • p. Blasko prezentoval ako platit online v roku 2017 (ddl od UPVII)
    • navrh je cez ekolky tak, ze po vyzve na UPVS je mi poslany platak smerom do edesku, kde sa musim prihlasit, uhradim a pokracujem dalej v sluzbe.
    • bolo povedane, ze toto je len vizia pre 2017, bude sa riesit neskor tak, aby bol platak zobrazeny priamo v sluzbe
    • za SUXA som apeloval na to, aby bol platak aj virtualny kiosk priamo embednuty v esluzbe a jedine presmerovanie vznikalo smerom na iterminal (dnes riesenie od First Data).
  • Nic sa neuzavrelo, boli len prezentovane rozne koncepty.
  • Buduci tyzden skupina bude trvat cely den, lebo sa meska (resp. deadlines su naozaj sibenicne, az by som povedal “manazerske” :wink:

myslim ze je to skor prvotne riesenie, ktore aj bude implementovane, ale ho mozno neskor rozvijat

ano, potvrdzujem, tak som to myslel.

Ospravedlnujem sa, kedze som bol cely tyzden prec, tak sem davam to co mi medzicasom doslo. Dokument na pripomienkovanie SP Interakcia s verejnou správou, životné situácie a výber služby navigáciou: https://drive.google.com/open?id=0B9NwG_x89B0-U3RmYXFpd2t3MTBjVS1pZlBTYW9NMllMOWpZ

Termin: Do ZAJTRA!

@michalblazej neviem odkial sa tam zobralo Net Promoter Score, ale pozeram voci gov.uk https://www.gov.uk/service-manual/measuring-success/measuring-user-satisfaction a ti odporucaju aspon jednu otvorenu otazku: “ako by ste zlepsili tuto sluzbu.”

Net Promoter Score mi pride velmi limitujuci v tom co vie vlastne povedat.

V celom dokumente sa (opäť) dosť ignorujú malé OVM. Prosím odprezentujte si na PS aktuálny zoznam OVM. Veľmi treba mať na pamäti aj org. typu “materská škôlka”, “Obec Vyšná Boca” (nie je povinné byť v DEUSe - to rovno môžeme zrušiť samosprávu), “centrum voľného času”, “knižnica”, “múzeum” a podobne. Mala by byť možnosť mať aj kompletne vlastnú implementáciu celej interakcie s iba minimálnym použitím centrálnych komponentov - možno nejako kategorizovať pre ktoré OVM/služby to bude povolené?

Riešenie ako je vymyslené stále vyzerá na centralistickú chyméru, ktorá už sa zopárkrát nepodarila realizovať…


Niektoré konania / podania sa dajú vybaviť iba papierovo / osobne / genericky - bude to tak vždy. Je k nim však dobré mať nejakú elektronickú podporu. To v dokumente nevidím. Má byť služba popísaná v centrálnom katalógu? Publikovanie formulára len na tlačenie? (pdf)


Obrázok na str. 19 nie je čitateľný, ale teda z textu sa dá vytušiť zhruba čo popisuje.


Na str.20 sa spomína “spoločný modul FE pre konsolidovaný stav podaní”, ktorý má zachytávať všetky udalosti o zmenách v podaniach. To imho nebude fungovať a nebude to ani efektívne. Aj ak by tento komponent bol hneď zajtra nasadený, najbližších mnoho rokov aj tak nebudú do neho “všetci” vedieť posielať udalosti. Ambícia niekde na jednom mieste evidovať “všetky bežiace konania” každého subjektu je dosť megalománska - a aký má byť efekt? Skôr zmysel dáva, aby každý OVM vytvoril funkciu (presnejšie: pre každý typ konania musí existovať funkcia), ktorá pre zadaný subjekt vráti zoznam rozpracovaných podaní. Táto funkcia môže byť v pohode asynchrónna, môže vrátiť výstup nie naraz, môže bežať povedzme aj niekoľko dní (čo ak je príslušná agenda realizovaná papierovo?), ak treba, pre niektoré agendy môže byť spoplatnená (povedzme v agende kde zistiť stav konaní je objektívne náročné, alebo kapacitne limitované). Toto riešenie je flexibilnejšie, má rýchlejší nábeh, plus ušetríme jeden spoločný komponent a závislosť na ňom.


Ku kap. 4.3: Myslím že celý koncept asistovaných služieb je zrelý na podstatné prehodnotenie. Myšlienka “hocičo nakliká za mňa pracovník IOM” je úplne nereálna.

Že na IOM môžem dostať hocaké potvrdenie / výpis? Áno samozrejme. Že mi vedia pozrieť / exportovať správy v schránke? (napr. ak podnikateľovi ukradnú eID a má iba papierik od polície) Áno samozrejme. Zaručená konverzia? Základné typy samozrejme, exotické (napr. z neštanradného formátu podpisu) vyhodnoťme čo s nimi. Vedia v mojom mene pozrieť do evidencií (napr. My data)? Áno, dáva to zmysel. Pri ostatnom sa pozrime čo dáva zmysel.

Btw. ak máme na IOM zaručenú konverziu, nie je vôbec potrebné aby podanie robil pracovník IOM “za používateľa”. Je to chúlostivá vec, robia sa kvôli tomu krkolomné veci - typu podpis mandátnym certifikátom pracovníka IOM plus el. pečať IOM - a načo? Veď používateľ aj tak na papieri podanie podpíše. Tak nech sa jeho papierové podanie iba následne zaručene skonvertuje. Použijeme štandardný proces a ešte sa ušetrí mrte IOM-špecifických imlpementačných vecí.


Kap. 4.4 - platby: Nebudem do tohto veľmi vŕtať, iba jednu prosbu mám: Zaveďme štandardnú možnosť nastaviť inkasné platby voči banke klienta. Raz sa spraví netriviálny setup, avšak následne netreba žiadne vyberania spôsobov platby, presmerovania, PINy, dokonca ani závislosť na PSD2 API.


Kap. 4.5.1 / proaktívne služby: Nie je mi jasné, prečo by pre proaktívne služby mali existovať ľubovoľné špecializované komponenty. Z pohľadu centrálnej navigácie / prezentácie / spracovania podaní sú to skrátka štandardné služby, prípadne nastavenia. Skrátka mi príde (do schránky, alebo štandardného komponentu portfólia klienta) notifikácia / výzva / informácia o začatí konania. To že nejaká vec je “proaktívna” nesúvisí nijako s jej IT riešením. Z hľadiska procesov aj interakcie nevidím rozdiel medzi “proaktívnym oslovením klienta” keď mi dnes príde exekučný príkaz, predvolanie na políciu, správa o nedoplatku v poisťovni dnes a ak mi zajtra príde predvyplnené daňové priznanie, alebo informácia o začatí konania o zápise do katastra na mojej nehnuteľnosti po skončení kolaudácie.

Prosím nezavádzajme nejaké špeciálne “ponuky o proaktívnych službách”. Čo to akože má byť? Keď pri zmene trvalého bydliska sa táto automaticky premietne do iných agend? Keď na katastri chcem byť notifikovaný o začatí konania na ľubovoľnej parcele ktorú chcem sledovať? Keď chcem poslať notifikáciu týždeň pred tým než mi expiruje na aute STK? Ak chcem nastaviť automatickú platbu pre niektoré očakávané typy príkazov na úhradu? Tieto typy “ponúk” sú natoľko rozdielne, vyžadujúce špecifické nastavenia, a súčasne natoľko nerozlíšiteľné od mnohých ne-proaktívnych služieb, že je zbytočné ich niekde samostatne “konsolidovať”. A ešte ušetríme ďalší špecializovaný centrálny komponent.

Kap. 5.2: Nie je mi jasné, načo je uvedená v dokumente tá siahodlhá tabuľka. Ako napr súvisí nadradený biznis proces Priebeh konania s tým čo táto strategická priorita rieši? Imho nijako.

Čo ja viem, keď je v tej tabuľke riešené “Ustanovenie opatrovníka”, malo by byť skôr všeobecnejšie riešené konania za inú osobu (zákonný zástupca, splnomocnenie, opatrovník atď…), Či to je v inom dokumente?


Naopak, kľúčové kapitoly 5.3, 5.4 a 6 sú prázdne. Takto nie je dokument možné pripomienkovať a ani schváliť.

Nevyvesil si sem náhodou starú verziu dokumentu?

Pozor zmena:

do 17.10.2017 – pošlem návrh kapitol 5.3, 5.4, 6
do 20.10.2017 – členovia PS pošlú pripomienky ku kapitolám vyššie

Ako podla mna NPS vo svojej podstate nie je zle, je nad tym kopec metodiky na vyhodnocovanie. Suhlas ale, ze by tam mohla byt aj jedna otvorena otazka. Tusim som to aj spominal na stretku, ze ked niekto da odpoved 0-6 mali by sme sa ho spytat preco… Dam to do pripomienok za SUXA.

Ale NPS nam dovoluje benchmarkovat voci komercnemu svetu, co je +.

1 Like

UPVII_SP_Interakcia_VS_ZS_v02.pdf (4.4 MB)
Nova verzia na pripomienkovanie tu.

Zaslal som nejake pripomienky za SD. Ak nieco niekto este ma, doplnte sem do diskusie.review_log_SP_IVS_SlovenskoDigital.xlsx (8.9 KB)