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.
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.
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 
- 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”
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
Zaslal som nejake pripomienky za SD. Ak nieco niekto este ma, doplnte sem do diskusie.review_log_SP_IVS_SlovenskoDigital.xlsx (8.9 KB)
Krátky zápis zo stretnutia minulú stredu:
-
Pani z UPVII (zabudol som meno) prezentovala ich pohlad na zivotne situacie:
-
statistiky - ukazala nejaky graf roznych podanii atd (neboli to ZS, lebo to vlastne nikto neeviduje)
-
najviac - dane
-
cla 350k mesacne
-
ide sa skusat - narodenie dietata - pilot
-
proaktivne sluzby - zmena legislativy
-
ak sa prehodi default - aky to bude mat dopad na rozpocet? politicke rozhodnutie
-
startovanie ZS - aka je motivacia napriklad ORSR na seba zobrat dalsie kompetencie? priklad zalozenie sro. Predtym treba toto, ma to zobrat na seba kto?
- zivnostenske opravnenie
- poziadavka na FS
Preco by to robil?
-
balickovanie ZS - 25projektov per ZS je iluzia
-
aka je povinnost sa zapojit do centralnych komponentov? legislativa?
-
navrh ako pokracovat PS - doteraz drivovane uradom, teraz zber problemov/rieseni od participantov
-
centralne moduly - agenda ma riesit hlavne core biznis, preco by mali vsetci robit zber spatnej vazby?
offtopic - skor otazka na skupinu lepsie data cc @Lubor
- kto garantuje referencne data? Ked si tie data stiahnem do svojho IS na vybavenie nejakej agendy. Potom v ORSR nieco spatne zmenia. Mne to v agende uz nesedi.
- ako dokazem ze toto tam bolo?
- gov.uk robi registre ako “immutable log zmien s podpismi” u nas nic take neexistuje.
(Neviem ci to je vobec problem, ale je to zaujimava uvaha.)
Vieš sem tieto údaje zavesiť?
Čo sa ide skúšať?
Čo presne? A prečo?
Čo presne myslíš “garantuje”? Pri ref. údajoch sa určuje aj ref. register - údaje ktoré sú tam, sú pokladané za správne - v každom čase. T.j. ak sa údaje v ref. reg. zmenia, má si ich každý u seba zmeniť. Ideálny stav však samozrejme je, že ref. údaje sú evidované iba v ref. reg. a ostatní ich používajú iba na prezentačné účely.
Čo presne myslíš pod “spätnou zmenou”? Kto a prečo chce niečo dokazovať? Stále hovoríme o G2G samozrejme.
Ak ide o klasickú paranoju, že úradník A použije v konaní údaj získaný od úradníka B (resp. jeho IS) a následne úradník B poprie že takýto údaj existoval, tak dovidenia integrovaný eGov. Bez vzájomnej dôvery sa nikam nepohneme. Presnejšie: údaje získané skrz G2G integráciu (obzvlášť pomocou platformy dátovej integrácie) sú pokladané za dôveryhodné. Samozrejme že úradník A si poznačí aké údaje použil. V prípade sporu preukazuje autenticitu údajov úradník B.
Ad “log zmien” - nepoznám žiadny register, ktorý by si interne neevidoval históriu zmien. Ak je dôvod, štandardným mechanizmom (viď. SP Riadenie údajov) sa dá z registra sprístupňovať aj história. Pozri napr. datasety registra adries, kde máš celú históriu zmien a vidno tam aj komplikovanosť času zmeny / intervalu platnosti / intervalu účinnosti.
Neviem, ale mozno @ret by vedel dovolit tu prezentaciu vyzdielat.
Ak to chapem spravne, tak prvy pilot ZS bude narodenie dietata.
Ak sa dnes napriklad pri narodeni dietata vyzaduje nieco dokladat prikladat, tak aby to bolo uplne automaticke (nie v rezime, ze tuto to mate predvyplnene a podate podanie) tak treba zmenit legislativu = je to na dlho.
Toto tam otvoril @anton-somora, tak nech dovysvetli. Ja som sa nad tym nejako nezamyslal a ani v skupine sa to dalej velmi neriesilo, je to mimo jej scope.
Poznamka pre mna: Pisat podrobnejsie zapisy.