Správa o stave eGovernmentu a čo ďalej?

Čo je nové v Slovensko.Digital
1

Keďže doterajšie hodnotenia stavu eGov sa nám nezdali dosť dobré (najmä správa o plnení NKIVS), a keďže nie sme kritici čo iba frflú, máme vlastný dokument, kde štruktúrovane hodnotíme dnešný stav. A navrhujeme čo ďalej, najmä aké sú priority.

Tu je celý dokument, budeme radi za každé pripomienky:

Zopár poznámok:

  • je to dokument vo vývoji - viaceré časti úmyselne nie sú doriešené (nechceme čakať)
  • toto chceme dlhodobo ťahať, čiže aktualizovať a dopĺňať
  • ak sa niekto cíti obzvlášť zdatný v niektorej z tém - najmä na niektorý program eGov (viď. kap.2) - ozvite sa, prípadne môžete túto kapitolu spolu s nami napísať
  • že sa teraz najbližšie mesiace bude hovoriť o rôznych programoch, tak toto je náš pohľad na vec - nechceme pomáhať niekomu písať jeho program, ale radi vysvetlíme čo považujeme za priority, čo nie a prečo

Tento dokument sme vytvorili v rámci projektu Lepšie riešenia e-Governmentu v SR , ktorý je finančne podporený z Európskeho sociálneho fondu.

2

ciste pre poriadok, najvacsia prekazka pri hybridnom cloude je financovanie, z fondov sa da kupit HW alebo to nasadit do vladneho cloudu. Hybridny cloud je riesenie pre financovanie zo statneho rozpoctu a ten sa brani.
a rovnako pri teme ludskych zdrojov nie je spravne urceny vlastnik problemu, tym nie je UPVII ale Sekcia štátnej služby a verejnej služby, neda sa problem zuzit len na IT, ide o sirsi problem a zdaleka sa netyka len IT.
K deleniu zakazok sa nechcem vracat, ale zjavne ide len agendu SD z dokumentu sa zda ze ide o problem eGov co nie je korektny popis situacie, vyznamovo by mala na tejto urovni len VO a teda kapitoly 2.5 a 2.6 by mali byt spojene do jednej, a dalsim problemom je ze priprava projektu s VO presiahla niekolko rokov a debata ci vyvijat agilne alebo nie je mierne tragikomicka v tomto kontexte.

A OpenApi je celkom dobra ukazka ake rizika hrozia centralnym koncepciam a ich “razantnemu presadzovaniu”. Miesto niekolkych vybranych rieseni sa koncepcne idu vytvarat desiatky OpenApi kde je ich vyuzitelnost blizka nule ( podobnost s podobnym tlakom v OPISE na tvorbu sluzieb je ciste nahodna, heslo vtedy znelo co najviac sluzieb a tak ich mame tisice). A bude trvat dalsie roky kym sa nieco spravi a dalsie kym sa to usadi a bude to pouzitelne.

3

Nie je pravda. Momentalne sa identifikuju prave prioritne OpenApi, ktore maju jasnych konzumentov. Zaciname zdola.

Tie desiatky Open API si rad pozriem. Specialne poreferujem, zo skupiny pondelok, kde naposledy ked padla otazka na OVM, ze ake API idu publikovat, zavladlo hlboke ticho niektori odvazlivci dokonca povedali, ze ziadne API nemaju (aj ked uz teraz maju, len o tom asi nevedia).

Inak je to vlastne cele uplne naopak, minimalne za SD sme vzdy “torpedovali” snahy o vytvaranie OpenAPI, pokial nebol jasny konzument a pridana hodnota. Odkial prosim ta beries tieto veci co tu pises?

4

nuz skus si precitat schvalene studie, niekedy je dobre zistit co sa deje vonku

5

Ale nie. Tragikomické je, že stále sa robia megalomanské VO celé nové systémy od analýzy po x-ročnú prevádzku. Kebyže sa spraví menšie zadanie, kde aj dodávatelia a škodiči budú mať menej krvavé oči, aj VO bude trvať kratšie.

Čítal som. Kde sú tie “desiatky zbytočných OpenAPI”?
Btw. ak vlastníkovi projektu je kvalita výsledku tak jedno ako to bolo viackrát v OPISe, tak nezáleží aké sú centrálne koncepcie, ba vlastne ani na zadaní, garbage in - garbage out, niekde sa už tie peniaze upichnú.

6

Velmi sa mi paci ten Havlov vyrok na zaciatku. Ale aj cely dokument je fajn, za mna klobuk dole :cowboy_hat_face:
Par mojich postrehov
OpenAPI - k tomuto by som ja pridal, ze chyba jednotna instrukcia kde sa maju API jednotlivych ISVS zverejnovat, idealne by bolo povedat, nech sa to zverejni bud centralne, alebo nech si kazdy to zverejni na nejakej standardnej adrese, kde si to potom budem moct najst.

Co este chyba, je vsetky UPVII instrukcie, resp. vystupy z pracovnych skupin by mali byt spracovane vo forme nejakej centralnej wiki, nieco na sposob Service Standard - Service Manual - GOV.UK. Lebo takto je to naozaj vela dokumentov v ktorych sa iba malokto vyzna.

K rozdelovaniu zakaziek - podla mna tu chyba nieco, co by urady motivovalo tento institut vyuzivat. Lebo z pohladu uradnika je to navyse vela prace (dalsie VO, potom manazovanie viacerych dodavatelov) a rizika ze niektore VO sa zrusi, oneskori atd (aj ked teraz ciastocne beriem spat, vidim to popisane v casti 4). Vase odporucania si myslim ze su dobre, ale pokial niekto velmi vysoko nebude mat KPI aby boli IT obstaravania mensie, tak to bude mat iba obmedzeny ucinok. Ale nie som odbornik.

K kapitole 4

  1. riadenie - tu by som spomenul este riadenie architektury, najma vytvaranie vzorov ako co ma byt, monitoring nielen rizik, ale aj stavu projektov a priebezne zverejnovanie/aktualizacia ich dokumentacie a sluzieb. Teraz sa to najst neda, vid aj vasa diskusia vyssie.
    V ramci architektury by sa tiez mali dizajnovat zivotne situacie a high level procesy toku dat.
    Taktiez tu chyba spomenuty datovy model.
  2. pridal by som meranie sluzieb ako piaty bod. Ked nic nemeriam, tak to neviem riadit.
2 Likes
7

Planovanym cielom je API GW, kde vystavis open api 3.0 subory - ale suhlas, ze medzicasom by sa mohla urobit nejaka stranka hocikde, kde by bol trebars aspon ich zoznam.

8

Myslím že práve Ty vieš ako toto bolo plánované: M e t a I S
A súhlasím že wiki by stačila. Zatiaľ je tu však skôr opačný trend, ešte aj informatizacia.sk sa zrušila a každá org. jednotka, ktorá sa má k svetu, si robí vlastný portál, dokonca s vlastným dizajnom.

Jasné, s tým súhlasím. Akurát že technických tém, kde je potrebné centrálne riadenie je asi tak sto - povedzme ref. registre, kde sa zdá že sa začalo niečo opäť rozbiehať. “Centrálna architektúra eGovernmentu” je aj v pláne že k tomu bude samostatná kapitola (v 2).

Áno, o monitorovaní služieb sa píše v časti Elektronické služby.
Ináč pozri si ten benchmark / správu BRISKu, vcelku zaujímavé.

9

Kedze tu sme vo vsetkom suhlasili, tak este som mal jeden napad, ktory sa tyka ludi a konzultacnych firiem :slight_smile:
Paci sa mi napad obstaravat ludske zdroje cez EKS.
Kym (ak) sa to stane skutocnostou, tak vyzera ze sa to zatial robi cez velke konzultacne zmluvy. Tie su zvacsa napisane vseobecne, ale ja si myslim, ze by bolo prinosom, ak by sa pri vacsich zakazkach konzultacky dotlacili k tomu, aby verejne prevzali zodpovednost za to co idu dodavat (napr. deklaraciou co idu zlepsit) a robili to transparentne. Nie pri kazdom pripade to bude davat zmysel, ale pri niektorych urcite ano.

10

ale ved to tam všetko je na wiki, predpokladal som že členovia s.d chodia na skupiny a vedia o wiki, tu je napr. PS1:

Všetky adresáre sú tu:

11

všetky rozhrania, ktoré sú určené na integráciu sú zverejnené v META IS, pri aplikačnej službe (ak je určená na externú integráciu) ešte niekde ich treba? vieš vysvetliť, čo konkrétne by si ešte potreboval zverejniť?

12

teda myslíte OpenDataAPI, nie OPEN API … lebo v zmysle usmernenia UPPVII je OpenAPI štandard pre rozhranie medzi systémami a OpenDataApi pre publikovanie verejných dát…
Teda ktorého sa to týka? teraz je veľa dopytoviek, kde sa riešia nové alebo modifikované rozhrania, priritne pre referenčné dáta, moje dáta ale povinnosť je aj všetky OpenData.

13

“Vidíme viacero príčin, ktoré súčasný stav spôsobujú. Významným spôsobom sa na tomto stave podpisuje rigídny prístup k vytváraniu služieb – kde najčastejšie zaužívaným mechanizmom je vývoj vo veľkom eGov projekte pomocou tzv. vodopádového modelu (viď. viac v kapitole Projekty eGovernmentu).”

Chcelo by to hlbšiu analýzu, prečo nie sú agilné metódy… Nie len rigídny prístup, ale aj to, že RUP je predpísaná metodika EŠIF OPII a tiež preto, lebo VO definuje fixný scoop projektu a teda agilný ho nemusí vždy dosiahnuť …

14

"Za hlbšiu príčinu však považujeme systematický plošný nezáujem verejnej správy o používateľov a ich potreby. Na mnohých úradoch stále prevláda prístup, kedy „občan má nejakú povinnosť“, ktorú si má splniť, pričom už len poskytnutie elektronickej služby je považované za akoby bonusovú službu samo o sebe. Dlhodobo sa diskutuje o potrebe zmeny prístupu verejnej správy k používateľom na tzv. pro-klientský prístup, táto zmena však systematicky ani nezačala prebiehať, nie sú v tejto oblasti stanovené žiadne konkrétne ciele, úlohy a plány, stav nie je ani centrálne monitorovaný a vyhodnocovaný.

Pritom zo skúsenosti v Slovensko.Digital vieme, že mnohí používatelia majú reálne problémy s používaním elektronických služieb. Tieto problémy sa častokrát týkajú základných tém, napr. schopnosť nájsť správnu elektronickú službu, porozumieť „čo treba zadať do okienka“, otvoriť/prečítať, alebo podpísať dokument. Najvypuklejšie problémy vznikajú pri prechode medzi službami viacerých OVM, napr. použitie dokumentov z jedného úradu na inom úrade, keďže používatelia narážajú na vzájomnú nekompatiibilitu vizuálneho vzhľadu a slovníka služieb, logiky ich používania, ale stále aj na problémy prenositeľnosti používaných formátov (najmä formáty elektronického podpisu), kde prístup úradov je niekedy až za hranicou legálnosti. Problémy a podnety používateľov sú iba málokedy systematicky zbierané a riešené. Obvykle pri „prevádzke a údržbe“ elektronických služieb ich správca zaisťuje iba ich bežnú dostupnosť a opravu chýb"

Možno príliš je zamerané hodnotenie na samotné technické riešenie vytvorené, ktoré prevádzkuje služby. Pritom chýba v tejto časti možno doplnenie, že sú problémom aj zložité štandardy pre klúčové komponenty - eFormuláre, podpisovanie, eID sú zložité, no user friendly, často proprietárne štandardy … ktoré odrádzajú bežných ľudí od použitia.

dalšou vecou je absorbčná schopnosť verejnosti, t.j. absencie školení aj pre verejnosť - laby, eLearning kurzy, semináre … zvyšovanie motivácie, prezentácia dobrých príkladov úspor pre úrady … chýba platforma pre úradníkov na výmenu BestPractice pri aplikácií eGOV …

Tiež chýba prístup simply user - t.j. zjednodušovať veci, zamerať sa na služby najčastejšie používané v papierovom svete a po ich odladení dalšie a dalšie ladiť voči používateľom.

15

Bohuzial, slovenska verzia eGovernmentu je nepochopenim jeho klucoveho principu, ktory neni o elektronizacii postupov (papier vymenime za obrazovku PC), ale o odburavani nadbytocnych ukonov, ktore musi obcan urobit…Inak povedane, ide o presun povinnosti nieco vykonat z obcana na štátne institucie…

Nasa verzia eGovernmentu priniesla elektronizaciu papiera…
Takze dnes, ak kupim nehnutelnost do ktorej sa planujem aj nastahovat, tak vacsinu povinnych ukonov, ktore s tym suvisia (ohlasovna pobytu, evidencia vozidiel ak mam auto, spravca, elektrika, plyn, socialka a zdravotka), sice dokazem urobit elektronicky (aj ked o tom sa da pochybovat), ale cas zabijam inak, napr. studovanim prirucky ako spravne vyplnit elektronicky formular, pripadne ak je pre nejaky ukon pozadovany original tak navsteve uradu sa nevyhnem…

Skutocny eGovernment mal odburat vsetky nadvazujuce ukony a preniest ich z obcana na štát…

16

Myslim Open API. Ak to nebolo zrejme, tak open api 3.0 subormi som myslel definicie rozhrani, napriklad takto Swagger UI

Problem pojmu Open API je to, ze je “overloaded”:

  • Open API je v prvom rade iniciativa otvarania rozhrani statnych systemov sukromnemu sektoru a vlastne celemu vesmiru
  • v druhom rade je to oficialny standard vymenneho formatu OpenAPI Specification - Version 3.0.3 | Swagger
  • OpenDataAPI je oznacenie API, ktore sa zacalo pouzivat pouzivat na pristup k open data (t.j. verejnych/read-only dat). - tato cast je podla mna v tejto diskusii nie velmi podstatna.
17

Ano, metais je miesto, kde by to malo byt, ale podla mna to tam nie je, kedze:

  • ludia si pod aplikacnou sluzbou nepredstavuju API, ale nejake ine abstraktne a vzdy rozne veci
  • aj keby si to predstavili ako API, chyba tam miesto kde ulozit dokumentaciu (ak neratam ako prilohu).
    A pod spravnou definiciou rozhrania urceneho na integraciu si predstavujem presne definiciu podla OpenAPI 3.0, t.j. napr. uz uvedeny https://generator.swagger.io/?url=https://govbox.slovensko.digital/openapi.yaml
18

To je hypoteza a da sa overit na datach UVO, nevyzera ale ako pravdiva.
Ale tu nejde len o priebeh VO, kazdy projekt prechadza dlhymi pripravnymi fazami a to trva roky este pred samotnym VO. A medzi tym sa zmeni situacia, technologie, usmernenia, aktualne buzzwordy atd. Agilny vyvoj je v takomto prostredi je mierne mimo, ci nie ? Ostane jedine nejako hacknut to co bolo schvalene a urobit co treba v danom case. Alebo aj nie, kedze sa zrejme zmenilo aj politicke zadanie, ludia a pod. A novy vlastnik nie vzdy prijme stare zadanie.

Tak ja som sice necital vsetky ale namatkou som si pozrel studie kdezatial kazda slubuje pre nove sluzby open api a tak budeme mat open api pre uznavanie hnojiv a pod. Raz sa to dostalo do koncepcie a tak to uz zije vlastnym zivotom.

19

Vidim, ze tvoja viera v sluby v studiach je naozaj neoblomna.

Inak minimalisticky rezim Open API (napr. pre podania) je tento:

  • ked robis podanie musis spravit formular (xml, html/txt vizualizaciu) - toto musis robit kvoli slovensko.sk aj tak
  • validacna sluzba
  • sluzba na ciselniky (resp. podporne sluzby na vyplnenie formulara datovymi prvkami)

Ja mam za to, ze pri drvivej vacsine projektov toto musis spravit tak ci onak. Cize neviem uplne coho sa bojis. Taktiez v inych strategickych dokumentoch (napriklad multikanal) sa pise o chanel-fit a tak, co v preklade znamena, ze pokial nemas na to konzumenta, tak to robit nemas. Zase tu nerobme z open api nejakeho strasiaka.

20

nebojim:) to je skor ukazka ako dobre napady mozu skoncit zle. studie sa dostanu do podkladov vo a to bude niekto kontrolovat, a to ci je to publikovane v centralnom module sa kontroluje velmi lahko takze to bude urobene, a ci to bude mat konzumenta uz bude jedno ale bude sa to lahko kritizovat. to je kuzlo podobnych dokumentov.