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

Pracovné skupiny
1

Na ÚPVII bola zriadená pracovná skupina Lepšie služby, ktorej cieľom je “Naplánovať postupnosť aktivít, vďaka ktorým sa dosiahnu ciele NKIVS”.

Skupina sa má venovať nasledovným témam: (naše chápanie draftu UPVII)

  • Odstraňovanie bariér pri používaní služieb
  • Prístup orientovaný na klienta
  • Životné situácie
  • Interakcia s verejnou správou
  • Navigácia a procesné mapy
  • Mobilný government
  • Open API

Ako výstupy tejto PS sú plánované dokumenty:

  • Strategická priorita: Multikanálový prístup
  • Strategická priorita: Interakcia s verejnou správou, životné situácie a výber služby navigáciou
  • Strategická priorita: Integrácia a orchestrácia

Vedúci skupiny je Tomáš Révaj.

Za Slovensko.Digital členom tejto PS bude @jsuchal. Ak máš záujem tiež byť jej členom za S.D, daj nám vedieť. Rovnako dôležité -a možno aj viac- však bude zapojiť sa do prípravy návrhov a komentárov k týmto témam, tu na platforme. Z našich pracovných skupín k tejto téme majú najbližšie @ps-ux, ak vieš o ďalších čo majú záujem, daj im vedieť.

Prvé zasadnutie PS bude v stredu 16.11. 14-16:00. Cieľom je upresniť čo/ako/dokedy sa má riešiť, aké vstupy sú očakávané, aký je proces transparentnej komunikácie. Na základe toho čo sa v stredu dohodne zozbierame a predisktutujeme tu na platforme návrhy k týmto témam.

Účasť zástupcu Slovensko.Digital v tejto pracovnej skupine je financovaná z projektu Lepšie riešenia eGovernmentu v SR (viac info tu: https://slovensko.digital/projekty/lepsi-egovernment).

1 Like
2

Existujúce dokumenty a diskusie k téme:

3

Ja mam zaujem pomoct. Ak budete nieco potrebovat, tak dajte vediet.

Budu vsetky materialy verejne, alebo musim byt clenom skupiny, aby som sa dostal ku vsetkemu? Ak budu verejne, tak clenom nemusim byt. Ak nie, tak pro forma ma tam pls zaradte, aby sme mohli potom komunikovat.

4

Veducemu skupiny som dnes hovoril, ze silne odporucame caste zverejnovanie materialov a co naotvorenejsiu diskusiu aspon tu na platforme. Zdalo sa, ze s tym problem nema. Ja sa budem snazit davat sem maximum. Konkretne detaily sa dohodnu na prvom stretnuti.

5

ja by som sa rad pripojil k tomu mobilnemu governemntu, teda aspon ako pesiacik za iOS.
Dajte potom vediet, kde sa to 1. stretnutie tejto nasej pracovnej skupiny slovensko.digital bude konat. resp. planujete vsetko preberat iba tuto online na platforme?
Dik

1 Like
6

Po novom je za organizaciu len jeden clovek, cize to budeme musiet vymysliet inak. Nie je cielom, aby tam chodilo vela ludi, gro prace sa aj tak bude diat uplne inde. Podnety a diskusiu sa budeme snazit “externalizovat” sem.

2 Likes
7

Agenda:

  • Kick-off pracovnej skupiny (nominacie, system prace, harmonogram a vystupy)
  • Multikanalovy pristup – uvodny workshop k strategickej priorite

Sfinalizovane podklady Vam zasleme v priebehu Pondelka 14.11.2016.

9

ja budem zastupovat nakoniec stat

1 Like
10

Chcela by som sa zapojiť do práce tejto skupiny.

1 Like
11

Oznam. Za Slovensko.Digital som v skupine ja, @peter_k ide na koniec za stat, @michalblazej ide za SUXA. V principe nic to na situacii nemeni. Diskutovat sa bude najma tu, sledujte tuto temu pre pripadne ulohy. V stredu sa dozvieme viac.

12

K stretnutiu PS 16.11.

Veduci skupiny Tomas Revaj pripravil prezentaciu UPVII_PS_sluzby_v03.pptx (825.5 KB) (dostal som povolenie ju zverejnit)

Vystupmi tejto skupiny by mali byt tieto dokumenty v tejto casovej naslednosti:

blob.jpg1574×867 222 KB

Dostali sme prislub, ze cca o dva tyzdne budeme mat prvy draft na pripomienkovanie. Vitame tuto otvorenost.

Potrebujeme zozbierat navrhy na:

  • co ma byt v scope tychto dokumentoch? Aby sa na nic podstatne nezabudlo.
  • ake alternativy su nepokryte? Aby boli slusne vyargumentovane vsetky moznosti.

Primarne v oblastiach strategickych dokumentov:

  • multikanalovy pristup (riesi sa ako prvy)
  • integracia a orgestracie
  • interakcia s VS, Zivotne situacie a navigacia

Co sa preberalo na stretnuti a moje postrehy k tomu napisem neskor. Akekolvek navrhy piste sem, konsolidaciu spravime potom.

13

Moje osobne poznamky a uvahy zo stretnutia 16.11.2016

Zhrnutie:

Prve zasadnutie pracovnej skupiny. Pracovna skupina sa bude zaoberat nasledujucimi strategickymi prioritami NKIVS:
multikanalovy pristup,
integracia a orchestracia,
interakcia s verejnou spravou, zivotne situacie, navigacia v ramci zivotnych situacii.

Predstavil sa harmonogram stretnuti, milniky. Dolezite milniky su:
14.12.2016 - vznik 1. verzie a zaciatok pripomienkovania dokumentu k multikanalovemu principu
11.01.2017 - vznik 1. verzie a zaciatok pripomienkovania dokumentu k integracii a orchestracii
01.03.2017 - vznik 1. verzie a zaciatok pripomienkovania dokumentu k zivotnym situaciam

Veduci skupiny presiel uvodnu prezentaciu, v ktorej sa nacrtli jednotlive temy. Nizsie spisujem postrehy, co som zachytil.

Negativa, rizika:

  1. nesedi mi poradie v akom sa idu spracovat jednotlive temy - osobne by som zacinal zivotnymi situaciami a z toho by vypadavali poziadavky na zostavajuce priority a dokonca aj na konkretne projekt, projektove zamery.

  2. popisuje sa ToBe stav a iba na papieri, bez reflexie existujuceho stavu a existujuich skusenosti. Ako Jano S. poznamenal, chybaju kroky ako sa k ToBe stavu dostat. Toto je jeden z najklucovejsich prvkov a mal by byt zapracovany do rohodovania a definovani high level architektury.

  3. multikanalovost by som bral velmi light, aktualne nemame vyrieseny poriadne ani jeden kanal (ani osobny styk) a zrazu sa chce mat vsetko a vsade - ako Miso B. poznamenal adopcia takychto sluzieb je otazna, prepis nehnutelnosti a pod. clovek asi nebude chciet robit elektronicky a dokonca nie prostrednictvom mobilu a pod. Nie je potreba mat autosave formularu, t.j. nieco si rozpracujem na mobile a potom dokoncim na pocitaci

  4. multikanal - kanal mobilne zariadenia - padla otazka, ze ake odporucania dat pre budovanie tohto kanalu, ci nativne app, alebo responzivny dizajn webovych aplikacii, alebo nieco ine? Ake su trendy v zahranici? Kde sa vidi potencial? Co je uz za hranicou a vieme z inych segmentov, ze nefunguje alebo sa vobec neodporuca? K tejto otazke treba pristupovat velmi konstruktivne a agilne. Vraj uz v ramci aktualnych projektovych zamerov sa pocita s vyvojom mob. aplikacii. Mob. aplikacie su velmi specificka zalezitost, ktora musi vychadzat jednoznacne z potrieb pouzivatelov a proces vyvoja by mal byt extremne agilny. Osobne si myslim, ze nema byt cielom vyvinut kopec mob. aplikacii, ktore kopiruju napr. webove aplikacie. OpenAPI umozni sukromnemu sektoru taketo aplikacie budovat a keby sa to nechytilo a bola by potreba pouzivatelov, tak potom by sa malo ist do zvazovania, ci nativna mob. aplikacia alebo nejaky hybrid. Mob. aplikacie maju specificky sposob riadenia vyvoja a teda malo by sa to riesit v metodikach pre projektove riedenie. Plus obstaranie takejto sluzby/diela by malo byt samostatne.

  5. OpenAPI - osobne mam pocit, ze niektori clenovia si tento pojem zamienali s OpenData API. Potrebne klast doraz na vysvetlenie, ze nejde len o citanie udajov z API, ale aj o zapis a pod. V tejto suvislosti sa hovorilo o govtech firmach a o potrebe riadenia cyklu pre pristup k OpenAPI. OpenAPI je zatial vnimane v rovine “sandboxu”.

  6. mam pocit, ze sa velmi rychlo, bez analyzy existujuceho stavu, definuju uz vizie dalsich velkych projektov, ktore su duplicitne/do velkej miery rovnake s uz existujucimi IS VS alebo ich castami, napr. bol spominany centralny komponent pre notifikacie. Nemame uz niekde taketo nieco? UPVS? Nie je moznost, aby sa uz existujuce riesenie spristupnilo pre ine IS VS a takto bolo zakomponovane do navrhovanej architektury alebo malymi upravami taketo riesenie dosiahnut? Cielom by nemalo byt budovat nieco simultanne s existujucim stavom, ale do max. miery prepouzit/upravit uz existujuce riesenia. Moze pomoct zverejnenie kodu?

  7. navrhuje sa extremne centralne riesenie, cim sa zvysuje riziko single point of failure. Centralizacia sa tyka ci uz datovej roviny (napr. MyData) alebo aj technologickej, aplikacnej roviny. Opat teda hrozi riziko aj vendor lockinu.

  8. integracia a orchestracia sa nacrtla mierne. Toto si ani zatial neviem predstavit na zaklade aktualnych skusenosti. Ma toto vobec vyznam? Ma to riesit stat alebo ked bude OpenAPI, neporiesia sa tie najdolezitejsie veci mimo statu a lepsie v prospech obcanov? Bolo spominane aj nejake narodne integracne centrum, ak som to dobre zachytil. Zatial neviem co by to konkretne malo byt. Tema bude este predmetom debaty, cize urcite sa k nej este vratime.

Pozitiva:

  1. Viacero clenov si rychlo adoptovalo myslienku OpenAPI, napr. MV SR, ITAS.
2 Likes
14

Pridavam moje postrehy zo strenutia + navrh toho ako vidime situaciu za Slovensko.Digital. Dokument je otvoreny na komentovanie, pripadne piste navrhy sem.

Momentalne otvorene temy: Su orchestracna platforma, mobilne aplikacie a open api.

Zatial je “kontroverznejsia” otazka orchestracnej platformy. Tam nie je zrejma pridana hodnota centralneho riesenia, ktore prinasa svoje velmi velke rizika.

Stale plati, ze pokial nieco v dokumente chyba, teraz je cast doplnit scope.

15

Pridavam vyjadrenie za SUXA, ktore sme si interne schvalili:

2 Likes
16

Neskory, ale predsa zapis zo stretnutia minuly tyzden. Chcem pochvalit Tomasa, urobil si domace ulohy a spracoval podnety co dosli tu na platforme aj od SUXA. Ma to zmysel.

  • riesili sa ciselniky zivotnych situacii - su v metais, ale len stara verzia

  • MV ma nejake velmi dobre rozpracovane ZS - zatial nie v metais

  • architektura skupina - caka sa ci zo strategickych architektur vyjde nieco co z architektury co sa v roku 2014 (?) navrhla bude v protiklade

  • diskusia o tom kedy vlastne zacina a konci zivotna udalost (pred podanim, zistit vytazenost, registracia terminu)

  • zivotne situacie pre podnikatelov

  • diskusia preco mobilne aplikacie ano a nie, v nkvis su mobilne aplikacie - co s tym? prehlasit ze responzive je mobilna aplikacia

  • diskusia o tom aky bude mat dopad neimplementacia

  • vysledok - obmedzit mobilne appky len na to co je naozaj nutne (spravit whitelisting) - na toto treba dohliadnut v dokumente

  • openapi - ake objekty evidencie? (read / write)

  • poznamka backend musi kontrolovat aj to, ze podpis na ukone je v nejakom vztahu k tomu co chce menit/vidiet (logicke - nemozem podpisat, ze chcem prepisat auto niekoho ineho)

  • diskusia o limitoch open api - legislativa, formulare

  • existuje nieco ine ako api (write) na formulare? - vsetko vznika na zaklade podania (legis)

  • problemy schranok - DCOM robi polling (maju sluzbu co vrati pre 50 schranok naraz, problem ak statutar nieco do schranky sam prida, etc)

  • folder - opravnenie na folder (vraj je), opravnenie na podanie (malo byt v scope, vyzera ze neexistuje)

  • diskusia orchestracie - varianty

  • schranky - push notifikacie chybaju na urovni api

  • schranky - correlation id institucia nevidi (oni si to posielaju do schranok)

  • diskusia o umiestneni udajov pre open API - ci centralne alebo nie

  • developer portal pre API

  • kompetecne centrum, co bude tlacit na integracie a buchat do stola ak nieco pojde mimo to

  • diskusia o projekte csru - viaceri to videli ako zbytocny medzikus, integracia napriamo je pre producentov jednoduchsia. pre konzumentov je naopak fajn mat jeden endpoint a menej byrokracie.

  • diskusia o zivotnej situacii - co to je a ci tam vobec moze vzniknut viac krokov

  • bolo povedane, ze sa budu robit projekty per zivotna situacia - toto si treba treba ustriehnut. vsetci suhlasne prikyvovali

  • orchestracna platforma bude (lebo v cloude sa s tym rata)

  • diskusia - nove gui pre ZS nebude duplicita voci opis projektom?

  • argumenty za orch. platformu - procesy su mimo hlav vendora a diskusia o tom, ze prechod na novy proces je vzdy bolestivy.

  • viac krat som upozornil, ze toto by mala asi riesit ina skupina - PS architektura, ktora este nenastartovala.

Vysledkom je, ze ako kanal budu preferovane responzivne aplikacie (mimo velmi obmedzenych pripadov, kde by mohla mobilna aplikacia davat zmysel, napr. podpisovanie, autentifikacia)

Open API - z tohto mam zatial pocit, ze nie vsetci chapu uplne co sa tymto mysli a nemozeme to zredukovat len na podania na urovni formularov.

Orchestracna platforma - zatial vyzera, ze bude jedna centralna (v cloude), pricom vyhody prezentovane (centralizacia procesov a monitoring) nevidim ako velky dovod to robit takto. Tomas vsak odkazal, ze nami navrhovana alternativa (propagacia domenovych eventov) bude vhodnejsia ak sa da spravit.

Na tohtotyzdnovom stretku 1.decembra bude:

  • Mobilná aplikácia pre autentifikáciu
  • Asistovaný prístup k elektronickým službám (koncept IOM v navrhnutej architektúre)

Ak mate navrhy alebo nieco co by sa malo prebrat dajte vediet. Bol tu navrh venovat sa centralnemu dizajn manualu.

17

1.) Zbierat, vyhodnocovat a implementovat podnety (bugy, zlepsenia)

Do dokumentu navrhujem pridat poziadavku na zbieranie podnetov k aplikaciam a ich pouzitelnosti (public issue tracker? odborna komunita?) a definovane procesu, co sa s tymito podnetmi bude robit.

Specialna kategoria su male/lacne opatrenia “low hanging fruits”, ktorymi je mozne za relativne male naklady zlepsit pouzitelnost existujucich aplikacii. Ak sa podnet vyhodnoti ako opodstatneny a “low cost/jednoduchy”, tak by sa mal implementovat ASAP. Bud cez 2., 3. alebo “standardne” ako samostatny projekt alebo ako sucast projektu riesiaceho viacej podnetov naraz.

Priklad: Pri elektronickom vybavovani nevyzadovat od pouzivatela vyber poskytovatela podla lokality, ak to nie je nevyhnutne (napr. pri sluzbe konkretnej obce). Priklad: Ak ziadam o rodicovsky prispevok, tak mi je jedno, ci to vybavi pobocka v Bratislave alebo Humennom, takze v zozname sluzieb na slovensko.sk chcem pri sluzbe “Rodičovský príspevok pre zverené dieťa” uplne preskocit krok “Zvoľte poskytovateľa služby”.

2.) Vyuzitie reklamacii na opravy chyb v aplikaciach a ich pouzitelnosti

Ako je to so zarukou na existujuce projekty? Su dodovatelia povinni opravovat vyargumentovane vady? Do kedy? Toto by mohol byt sposob ako zapracovat zlepsenia “zadarmo” v ramci reklamacii. Navrhujem poziadavku na verejny zoznam projektov, dodavatelov a datumov dokedy su v zaruke.

3.) Statom organizovane hackathony a sposob financovania malych mikroprojektov na zlepsovaky UI/UX

Ludia generuju vela zaujimavych navrhov na zlepsenie, ktore by sa dali zrealizovat bud ako dobrovolnicke aktivity alebo nejakou formou financovane mikroprojekty (max. par tisic eur). Navrhujem pridat poziadavku na vytvorenie mechanizmu ako umoznit zapojenie ludi s mikroprojektami. Jedna moznost je napr. zapojenie studentov cez bakalarske a diplomove prace. Zadania by mohli plynut aj z podnetov z bodu 1.

Priklady: browser plugin, asistencny system, info o dostupnosti, napady z hackathonu, atd.

1 Like
18

Principy

  • navrhujem pridat “Eat your own dog food”

Kanaly a pristupove miesta

  • Kanaly “osobne”, “listinne”, “telefonicky”, “email” by mali byt len proxy k primarnemu kanalu (web?), cize uradnik by mal byt v ulohe asistenta, ktory moze v mene obcana pouzit webovy kanal. “Eat your own dog food” Otazka: Ako to robia napr. operatori alebo banky?
  • suhlasim s ostatnymi, ze mobilne aplikacie nie

Servisna vrstva:

  • Autosave je jedna z mnohych “drobnosti”, ktore zlepsuju pouzivatelsku skusenost, ale nedaval by som to do dokumentu
  • Vyhladavanie ZS a predvyplnanie udajov su zasadne veci. Su tieto dve veci vsetky zasadne veci? Podla mna nie.
  • K vyhladavaniu jeden detail a to, ze by mal byt budovany slovnik synonymickych pojmov (zalozenie sro = ziadost o zapis do orsr = zalozenie firmy, atd.).
  • Ja za zasadne povazujem aj:
  • “plynulost procesu” (nenapada mi teraz vystiznejsi pojem), cim mam na mysli to, aby sluzby boli implementovane tak, ze ich pouzivatel dokaze cele zrealizovat v jednom prostredi/aplikacii a nemusel napr. po vyplneni formulara v aplikacii ist do schranky a tam ho este podpisat. Iny priklad roztriestenosti je nemoznost prepinat medzi uctami po prihlaseni sa na slovensko.sk.
  • “jednotny vizual”, rovnako vyzerajuce komponenty (zoznamy, formulare, typografia, atd.), SUXA to popisala podrobnejsie, suhlas.
1 Like
19

Suhlasim tiez s tym, ze sa zase buduju to-be patrocnice a minimalne sa reflektuje sucasny stav.

Podla mna by bolo dobre vybrat zopar realnych sluzieb a popisat cely proces, ktorym musi pouzivatel (aj uradnik) prejst a na tomto ukazat principialne/systematicke chyby, kozmeticke veci (napr. nejednotny vizual, roztriestenost, zle vyhladavanie, nezrozumitelnost textov, z kozmetickych napr. autosave) a navrh ako sa dostat k lepsiemu stavu.

Druhy podklad by mal byt pohlad na metaproces zavadzania novych sluzieb, ktore este neexistuju elektronicky, identifikovat systematicke a kozmeticke chyby v tomto procese a navrh ako ich odstranit, aby vysledkom boli kvalitnejsie implementovane sluzby (tam je napr. rozhodnutie nerobit mobilne aplikacie, jeden krat a dost, eat your own dog food, atd.).

Tiez by bolo dobre najst a ukazat dobre priklady, kde fungoval proces tvorby a mame aj funkcny vysledok (napr. ITMS?).

20

Sorry ze sa zapajam aj bez vyzvania. Toto je mozno najvacsi oriesok. Z vlastnej skusenosti viem ze vytvorit nejaky Change request procesneho typu napriklad na MiFi bolo dost organizacne narocne.
Dovod. Vela systemov a kazdy pod inou zmluvou u ineho dodvatela. Iný projektak z MiFi a JEDNOTNA Orchestracna platforma v Datacentre ponizena z BPMN procesneho stroja na file exchanger. Potom ak mas zmenu , ktora je v primarnom systeme, musis cakat, alebo niekedy na vlastnu past jednat aj so systemami (dodavatelmi) kde ma dopad a s firmou co sedi na SAP NW PI (bpmn orchestracia). Oni musia na zakalde inych zmluv dostat Change requesty. Tento proces v podstate nema pana, a tak to tlaci obycajen dodavatel, ktoremu to najviac hori. A viac clovekohodin sa vybuicha na schodzkach a pri pisani zapisnic a mailov, nez programovanim.
… A bojim sa, ze takto by dopadli aj microprojects … (co je inac pattern velmi progresivny).
A to MiFi je na tom najlepsie co sa tyka procesov a vzdelania ludi pri Informatickych projektoch.

2 Likes
21

asi skor pracovna skupina delivery