Generický register


#23

Jano zober ako príklad ten nový RPVS. Je to relatívne malý register, s jednoduchou štruktúrou údajov. Väčšina štruktúr údajov sú dávno známe veci - adresa, fyzická osoba, právnická osoba.

Čo to u nich obnášalo:

  • nový zákon, resp. zavedenie nového registra v zákone
  • určenie (v tom zákone), aké údaje sú predmetom registra
  • definovanie procesov, ako sa tam ktoré údaje dostanú, zmeny, kto zapisuje
  • riešenie okrajových prípadov, odvolania, opravy

Obraz týchto vecí sa potom implementoval.

A pokaziť sa to môže hocikde po ceste, napr. v tom RPVS nieje poriadny identifikátor fyzickej osoby (nie je tam RČ ani ekvivalent).

Databázová časť v tomto skutočne nie je problém…


#24

Ak to nie je problem, je pre mna zahadou preco nieco taketo davno nemame a platime za registre desiatky milionov eur za kus. A nie tam sa neplati za novy zakon, ake udaje su predmetom registra, definovanie procesov a ani riesenie okrajovych pripadov. Vsetko toto by totiz malo vstupovat do zadania. Cize suhlasim, ze analyticka faza a pripravna faza je ovela dolezitejsia, ale pointa prispevku je prave v tej technologickej casti.

Je mi jasne, ze vsetko toto vchadza do zadania[quote=“peterk, post:22, topic:2495”]
Treba vsetky tri casti osobitne riesit a nie hned napisat “drupal”…
[/quote]

Ach. Prosim aspon sa snazme citat s porozumenim. To bol priklad, nie navrh, ze robme to v Drupale. Niekedy mam pocit, ze si tu vyberieme jedno slovicko z celeho textu uplne mimo kontextu.

Suvisi to, ale nie.

Takze skusme sa posunut.

Lebo presne to som ja (asi nesikovne) hned v uvode urobil. Tocime sa v kruhu s takymito radami.


#25

Tak teda aké časti to potrebuje pokryť: - úvodný draft, doplňte

  1. spisová služba / DMS / príručná registratúra (pracovne to nazvime JIRA*)
  • nástroj na modelovanie procesného modelu
  • predpripravené GUI komponenty
  • prepojenie na vstup/výstup dokumentov, overovanie platnosti, autorizáciu - minimálne el. podateľňa
  • riadenie prístupu používateľov - prepojenie na IAM (zamestnancov VS)
  • dlhodobé riadenie dokumentov - prepojenie na archív, dlhodobé úložisko
  1. báza údajov registra (pracovne to nazvime MariaDB)
  • založené na RDBMS
  • vstup/výstup údajov z/do iných evidencií/orgánov - pripojenie na platformu zdieľania údajov

Pri vytváraní inštancie generického registra:

  • určiť a implementovať procesný model z pohľadu spisu / dokumentov
  • priradiť role
  • pripraviť el. formuláre a iné typové dokumenty, šablóny
  • definované údajové štruktúry a zavedené do DB
  • iniciálne naplnenie údajmi
  • konfigurácia pripojenia komponentov okolo

*) = úmyselná provokácia


#26

preco je tu registratura spominana? je to stale k tomu generickemu registru, alebo je to ta referencna architektura?


#27

Generický register. Práve tá DMS časť je zložitejšia a pre vedenie registra podstatná.


#28

Sprava registra je vacsinou specializovana agenda (zvlast modul/system) a je integrovana na registraturu na prijmanie ziadosti/ich spracovanie a nasledne vytvorenie rozhodnutia o zapise. Niekedy je to riesene dakym procesom v ramci SOA.
Je to viac modulov spolu by som ich neriesil, aj ked an dakej vyssej urovni tam daky medzimodulovy biznis proces bude. V tomto sa prelinaju hranice aplikacii.


#29

ja to skor vidim takto:

ucastnici

  • spravca platformy
  • spravca dat - gestor
  • konzument dat
  • ziadatelia/obcania/firmy

procesy

  • data registrov:

  • ziadost o zapis do registra

  • ziadost o zmenu v registroch

  • ziadost o vyranie z registra

  • automaticke vyradenie z registra - casom/inym vstupom v medzirezornom procese

  • automaticke zaradenie do registra - napr v ramci vacsieho medzirezortneho procesu

  • metadata registrov:

  • ziadost o vytvorenie registra

  • ziadost o pridanie/odstranenie/presun autorizacie k registru

  • ziadost o rozsirenie cudzieho registra?

  • ziadost o pridelenie procesov spracovania registru

  • ziadost o sledovanie zmien dat registra

funkcionalita

  • bezpecnost:

  • autentifikacia gui - integracia na iam - ad/upvs iam

  • autentifikacia ws - integracia na pki/oauth/sts?

  • sprava pristupov

  • autorizacia na urovni registrov - citanie/zapis

  • autorizacia na urovni atributov dat registov - citanie/zapis

  • integracie autorizacii na existujuce systemy - ldap?

  • gui rozhranie na vsetky ukony

  • ws rozhranie na vsetky ukony

  • metadata registrov:

  • sprava registrov

  • pridelovanie prav ucastnikom

  • gui rozhranie na vsetky ukony

  • ws rozhranie na vsetky ukony

  • data registrov:

  • vytvaranie/aktualizacia dat registrov

  • vyhladavanie dat registrov

  • publish/subscribe model - online, formou dennych davok

  • verzionovanie?

  • gui rozhranie na vsetky ukony

  • ws rozhranie na vsetky ukony

  • spracovanie ziadosti:

  • prijatie elektronickej ziadosti cez ws - z registratury (nie je ulohou spravy registra sa starat o spravne dorucenie v orgarnizacii a archivovanie)

  • prepis ziadosti z papierovej podoby

  • vytvorenie rozhodnutia + podpisanie rozhodnutia?

  • odoslanie rozhodnutia cez registraturu (nie je ulohou registra starat sa o podpisovanie, obalkovanie, odosielanie a spracovanie dorucovania, archivovanie, atd…)

  • procesy - toto by tu nemuselo byt, ak by boli vsetky interaface dosutpne cez ws, tak riadenie/spustanie procesov sa da riesit na dakej uz existujucej platforme (soa/esb)

  • spustanie procesov spracovania ziadosti

  • definovanie procesu spracovania ziadosti

  • sprava procesov

  • gui rozhranie na vsetky ukony

  • ws rozhranie na vsetky ukony

  • monitoring:

  • logovanie zmien

  • logovanie vytazenosti

  • varovanie pred pretazenim

poziadavky na data

  • historicky dohladatelne
  • relacie medzi registrami - semanticky?

#30

Ja si myslím, že to tu príliš komplikujeme v tomto kroku. Na začiatok by úplne stačilo vytvoriť ten register. V zásade všetko v tomto štáte je viazané na niekoľko objektov (fyzická osoba, právnická osoba - akákoľvek (veď typ je len príznak), adresa, nehnuteľnosť, automobil, …). Potom je to už len o dopĺňaní stĺpcov do databázy a vzájomných závislostí. Súhlasím s @Lubor aj @jsuchal že doplniť ďalší stĺpec nevyžaduje úplne novú databázu ako sa nám to tu úradníci s ich poradcami snažia nahovoriť. Problém ale asi je v tom, nikto to takto nechce, lebo sa nepredajú ďalšie licky na sql, or, db2,… Ono by sa to úplne kludne dalo vytvoriť z nejakej existujúcej databázy, registra. Napr. z RFO príp. dátovo uprataného RPO


#31

no ano, technicky je to jednoduche…ale tej byrokracii okolo sa vyhnut podla mna neda, rozne organizacie, rozne poziadavky na registre. Najvacsi problem je vzdy zodpovednost, kto bude za co zodpovedny, to musi byt jednozacne. Ci uz za data alebo prevadzku. To ze je to len v inej db alebo to bude ako dalsie stlpce tak to nema velky vplyv an finalnu narocnost a celkovo cenu. Nuz Enterprise svet ma uplne ine pravidla:)


#32

IMHO toto bude bez nejakej konsolidacie v case viest k “bordelu”. Velmi skoro sa pride na to, ze niektore urady si pridaju svoje atributy, ktore by v danej domene “mali byt” referencne co znemozni napr. jeden krat a dost. Takato funkcionalita by IMHO mala sluzit na rychle/docasne prototypovanie s tym, ze to nastartuje proces standardizacie, ktoreho vysledkom bude bud, ze dany atribut zostane, tak ako si ho urad “nakodil” alebo sa “povysi” na referencny, pripadne inaksie sa refactorne do existujucich systemov.


#33

Páni,
trochu sa opýtam, nakoľko už tu dlhšie nič nepribudlo,
ale nesmerujete teraz vlastne k tomu, čo je technicky MUK dátová časť? teda zdielaná služba SaaS MUK?
ktorý by pokryla biznisové procesy potrebné na jeho manažovanie.

Tak ako ste ale už skôr písali viacerí, čo však s evidenciami, ktoré predchádzajú CRUD operáciám do generického registra? Otázne je potom aj prínos oddelenie defacto “databazy” od samotných evidencií a procesov, ako sa “databáza” naplňuje.

Teda možno späť, čo vnímame ako register - biznisovo ja to vnímam ako komplexný procesnú blok, súvisiaci s dátovo jedinečným údajom vo VS (v ponímaní, že teda referenčný register, lebo iný ani neviem, prečo sa má volať register, asi to je potom len evidencia).

Lebo zvyčajne súvisiaca agenda s “registrom” rieši kompetenciu OVM smerujúcu ku nejakému rozhodnutiu, teda získaniu oprávnenia na niečo pre FO/PO a toto OVM zapisuje niekde. V súčasnom ponímaní elektrizácie procesov ako sa riešia od čias OPISu sa teda rieši celý proces tak ako bol v papierovom svete, hlavne s pohľadu účasti úradníka na procese. Moja otázka je, či je to takto potrebné?

Ja som trošku taký rojko a myslím, že proces treba radikálne upraviť tak, že ak sa nejedná o národný záujem, úzko špecializované bohatstvo štátu, nejaký iný princíp, tak proste celý register by mal fungovať automaticky bez úradníka.

  • register obyvateľov - lekár napíše rodný list a hotovo ste tam. ked umriete, tak zase ste vonku. Môžete sa prihlásiť do svojho profilu a meniť tam čo chcete - fotku, maily, bydlisko a pod, je to na Vás a čo Vám systém dovolí /oprávnenia a dáta z iných IS) Načo sú matrikárky? sú podstivejšie ako pôrodný lekár, čo vypisuje list o narodení dieťaťa?
  • reg. právnických osôb / živnostenský register - spíšete zakl.listinu alebo vyberiete čo chcete robiť a systém vás zaeviduje. potom sa už vy sám prihlásite do toho registra a robíte tam čo chcete so svojim profilom (resp. čo vám oprávnenia a systém dovolí) Načo listiny tam posielať, ktoré ste už raz posielali daniarom a pod…
  • daňový register - automaticky ak ste PO podnikateľ, tak ste v ňom. ak ste iný subjekt, zašktnete v vo svojom profile v RPOa podnikateľov že chcete byť daň.subjekt a hotovo.
    – takto aj s vozidlami, … a tak dalej… načo je kataster a vozidlá a čo ja viem čo. Nech je register majetkových práv a tam budete môcť si dať čo chcete… Evidenciu nech si robí kataster ak tam nie sú čisté dáta, zatiaľ asi v tomto automaticky bude len minimum vecí, ale nech tam je k tomu aj dane k tomuto majetku, exekúcie a pod. Pri autách predsa načo policajt pozerá do systému, že kto komu čo predáva? Tak isto, načo ma policajt kontroluje či mám pri sebe vodičák, ked si pozrie občiansky a dá si ho do čítačky u seba v aute, tak musí vidieť celú moju historiu vodiča, rovnako auta v ktorom sedím a pod…

Proste ja by som už úradníkov do procesov registrov neťahal a hlavne sa odpútal do tých formulárov a podaní. Aj dnes je možné vytvárať z ISVS výpisy a odpisy, tak ak má niekto záujem mať aj “papierovú / elektronický” dokument, nech to má, ale to si práve priplatí.

Rovnako skutočne robil tie procesy, kde úradník vôbec niečo posudzuje vecne a nie len formálne, osobne si myslím, že toho nebude veľa, hlavne ak sa pozeráme na “registre” - o evidenciách to netvrdím :slight_smile:

Ešte možno dodatok ku tomu, čo by vlastne robili úradníci, ked by sa veci riešili automaticky. podľa mňa by viacej mali kontrolovať čo sa robí v štáte a potom to dávať práve do tých profilov k PO alebo FO, aby aj ostatná verejnosť vedela o tom, čo robia ludia a potom by sa každý uvedomil, či bude klamať a podvádzať, alebo nie :slight_smile: viete, na FB si ludia lajkujú profily a píšu tam všetko o sebe, a štát to o nich nemôže robiť? možno pri PO by sa to mohlo začať.
Možno ideálny svet.


#34

Toto si ja rad precitam, neviem ako o MUK, ale o CSRU koluju vseliake myty. Infoziadostami sa neda dostat velmi k tomu co to vlastne robi.

Samotny napad toho, ze si do registra zapisem nieco sam alebo ked predavam majetok sa to vyriesie “peer-to-peer” sposobom je ok. Nakolko je to mozne pri akych agendach je otazka. Boli tu uz aj onakvejsie napady Registre cez blockchain


#35

CSRU a MUK boli svojho času to iste, ako predtým G2G dátová časť MFSR a teraz modul procesno dátovej integrácie :slight_smile:


#36

Ako ďalší priklad a inšpiráciu uvádzam Register poverení na vykonanie exekúcie (MSSR). V sekcii pomocník je vysvetlená zákonná motivácia a všetko, čo s tým súvisí.

Zjavne sa an tento register pri tvorbe riadil týmto postupom, ktorý popisuje @Lubor