Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

Odkaz na výstup diff

Obě strany předchozí revize Předchozí verze
Následující verze
Předchozí verze
nap:pravidla_tvorby_a_udrzby_vlastni_ctyrvrstve_architektury_jednotlivych_uradu [2019/08/23 14:56] – [Ohlášení agend úřadu v RPP] Tomáš Šedivecnap_dokument:pravidla_tvorby_a_udrzby_vlastni_ctyrvrstve_architektury_jednotlivych_uradu [2021/07/29 16:51] (aktuální) – cms a pravidla připojení Tomáš Šedivec
Řádek 1: Řádek 1:
-~~Title: Pravidla pro vrstvy architektury úřadu~~+====== Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury ======
  
-====== Pravidla pro vrstvy architektury úřadu ======+Tato kapitola popisuje architekturu úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu. Jde o jiný přístup k popisu požadavků na využívání systémů a služeb eGovernmentu než v části [[nap_dokument:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivých úřadů]], kde se požadavky popisují v celé šíři (v celé architektuře) sdílené služby, funkčního celky či tematické oblasti.
  
-Tato kapitola popisuje pravidla pro sdílené služby, funkční celky a tématické oblasti po jednotlivých architektonických vrstvách, včetně pravidel, návodů a dobrých praktik k jejich zanesení do informační koncepce a architektury úřadu. Jde o jiný přístup k popisu požadavků na využívání systémů a služeb eGovernmentu než v části [[nap:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Pravidla pro architekturu sdílených služeb, funkčních celků a tématických oblastí jednotlivých úřadů]], kde se požadavky popisují v celé šíři (v celé architektuře) sdílené služby, funkčního celky či tématické oblasti.+Skladba této kapitoly odpovídá [[nap_dokument:uvod#Domény Národní architektury veřejné správy|doménám národní architektury]]
  
-Skladba této kapitoly odpovídá [[nap:uvod#Domény Národní architektury veřejné správy|doménám národní architektury]] +{{ nap-dokument:nap.png |}}
- +
-{{ :soubor:nap.png |}}+
  
  
Řádek 15: Řádek 13:
  
  
-<note important>Popis všech centrálně poskytovaných systémů a jejich služeb je popsán v části [[:nap:architektura_a_sdilene_sluzby_verejne_spravy_cr|Architektura sdílených služeb, funkčních celků a tématických oblastí veřejné správy ČR]]. +<WRAP center round tip 60%> 
- +Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce. 
-Konkrétní implementační kroky a způsoby zapracování do informační koncepce OVS pro jednotlivé sdílené služby, funkční celky a tématické oblasti jsou popsány v kapitole [[:nap:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Pravidla pro architekturu sdílených služeb, funkčních celků a tématických oblastí jednotlivých úřadů]].+</WRAP>
  
-Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce v části XXX.</note> 
  
 Pro architekturu strategie a směřování je podstatný především soulad se strategickými dokumenty, jejich principy a cíli. Mezi tyto dokumenty patří: Pro architekturu strategie a směřování je podstatný především soulad se strategickými dokumenty, jejich principy a cíli. Mezi tyto dokumenty patří:
-  - Informační koncepce ČR+  - Strategie Digitální Česko a z ní zejména Informační koncepce ČR
   - Informační koncepce úřadu   - Informační koncepce úřadu
-  - Strategie Digitální Česko 
   - Národní architektonický plán   - Národní architektonický plán
 +  - Strategický rámec rozvoje veřejné správy 2014+
 +  - Koncepce klientsky orientované veřejné správy 2021+
 +  - Strategie rozvoje infrastruktury pro prostorové informace v České republice do roku 2020 (GeoInfoStrategie)
 +
 +V modelu vlastní celkové architektury úřadu by praktickému používání při řízení úřadu měly sloužit zejména diagramy strategických cílů, architektonických principů, architektonických požadavků a omezujících podmínek, vytýčených směrů rozvoje a očekávaných výstupů. Tyto by měly sladěným způsobem kombinovat objekty převzaté z nadřazených strategií, viz výše a z vlastních strategií a koncepcí úřadu.
 +
  
  
Řádek 33: Řádek 35:
  
  
-<note important>Popis všech centrálně poskytovaných systémů a jejich služeb je popsán v části [[:nap:architektura_a_sdilene_sluzby_verejne_spravy_cr|Architektura sdílených služeb, funkčních celků a tématických oblastí veřejné správy ČR]].+<WRAP center round tip 60%> 
 +Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce. 
 +</WRAP>
  
-Konkrétní implementační kroky a způsoby zapracování do informační koncepce OVS pro jednotlivé sdílené služby, funkční celky a tématické oblasti jsou popsány v kapitole [[:nap:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Pravidla pro architekturu sdílených služeb, funkčních celků a tématických oblastí jednotlivých úřadů]]. 
  
-Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce v části XXX.</note> +**Pro tuto doménu architektury nejsou v současnosti Národním architektonickým plánem stanovena žádná pravidla.**
- +
-**Pro tuto vrstvu architektury nejsou v současnosti Národním architektonickým plánem stanovena žádná pravidla.**+
  
  
Řádek 46: Řádek 47:
  
  
-<note important>Popis všech centrálně poskytovaných systémů a jejich služeb je popsán v části [[:nap:architektura_a_sdilene_sluzby_verejne_spravy_cr|Architektura sdílených služeb, funkčních celků a tématických oblastí veřejné správy ČR]].+<WRAP center round tip 60%> 
 +Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí je popsán v části [[nap_dokument:architektura_a_sdilene_sluzby_verejne_spravy_cr|Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR]].
  
-Konkrétní implementační kroky a způsoby zapracování do informační koncepce OVS pro jednotlivé sdílené služby, funkční celky a tématické oblasti jsou popsány v kapitole [[:nap:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Pravidla pro architekturu sdílených služeb, funkčních celků a tématických oblastí jednotlivých úřadů]].+Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části [[nap_dokument:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady]].
  
-Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce v části XXX.</note> +Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce. 
- +</WRAP>
- +
- +
-===== Pravidla byznys architektury výkonu veřejných služeb úřadu =====+
  
  
Řádek 62: Řádek 61:
 ==== Rozdělení procesů a funkcí veřejné správy ==== ==== Rozdělení procesů a funkcí veřejné správy ====
  
-Pro rozhodování o variantách architektury řešení IT podpory byznys potřeb výkonu veřejné správy úřadu je nutné všechny tyto byznys potřeby VS vyhodnocovat a třídit z několika úhlů pohledu.+Pro rozhodování o variantách podpory potřeb výkonu veřejné správy úřadu je nutné všechny tyto byznys potřeby VS vyhodnocovat a třídit z několika úhlů pohledu. 
  
-Vedoucí informatiky úřadu a techničtí správci ISVS jsou povinni ve spolupráci s jejich věcnými správci vytvořit a udržovat aktuální model procesní, respektive funkční dekompozice úřadu a její diagram, tzv. Mapu byznys portfolia/architektury úřadu.+Vedoucí útvaru informatiky úřadu a techničtí správci ISVS jsou povinni ve spolupráci s jejich věcnými správci vytvořit a udržovat aktuální model procesní, respektive funkční dekompozice úřadu a její diagram, tzv. Mapu byznys portfolia/architektury úřadu.
  
 Tento model musí z podstaty komplexního řízení informatizace úřadu obsahovat identifikované všechny činnosti (schopnosti, procesy, funkce nebo služby, dále zastoupeny pouze pojmem funkce), které organizace vykonává, ať již jsou aktuálně manuální nebo elektronizované. Jako součást prostředků dlouhodobého řízení rozvoje IS úřadu musí být u všech těchto funkcí úřadu vyhodnoceno, do jaké míry uspokojivě a efektivně jsou podpořeny informačními technologiemi a do jaké míry tak má být cílově učiněno v časovém horizontu informační koncepce úřadu (5 let). Tato část Informační koncepce OVS pak musí obsahovat a zohledňovat zejména: Tento model musí z podstaty komplexního řízení informatizace úřadu obsahovat identifikované všechny činnosti (schopnosti, procesy, funkce nebo služby, dále zastoupeny pouze pojmem funkce), které organizace vykonává, ať již jsou aktuálně manuální nebo elektronizované. Jako součást prostředků dlouhodobého řízení rozvoje IS úřadu musí být u všech těchto funkcí úřadu vyhodnoceno, do jaké míry uspokojivě a efektivně jsou podpořeny informačními technologiemi a do jaké míry tak má být cílově učiněno v časovém horizontu informační koncepce úřadu (5 let). Tato část Informační koncepce OVS pak musí obsahovat a zohledňovat zejména:
  
-  * rozhodnutí o konsolidaci IT podpory byznys funkcí úřadu +  * rozhodnutí o konsolidaci IT podpory byznys funkcí úřadu, 
-  * rozhodnutí o možnostech sdílené IT podpory byznys funkcí úřadu +  * rozhodnutí o možnostech sdílené IT podpory byznys funkcí úřadu, 
-  * optimalizaci funkcí úřadu s podporou ICT - doplnění a rozvoj nedostatečné ICT podpory funkcí úřadu+  * optimalizaci funkcí úřadu s podporou ICT - doplnění a rozvoj nedostatečné ICT podpory funkcí úřadu.
  
 Přitom je nutné pohlížet na identifikované funkce úřadu a rozhodovat o nich přinejmenším z následujících čtyřech hledisek: Přitom je nutné pohlížet na identifikované funkce úřadu a rozhodovat o nich přinejmenším z následujících čtyřech hledisek:
Řádek 78: Řádek 77:
   - Hledisko míry (a potenciálu) vymístění funkcí a využití sdílených služeb na místo individuálních funkcí.   - Hledisko míry (a potenciálu) vymístění funkcí a využití sdílených služeb na místo individuálních funkcí.
   - Hledisko výkonu funkcí úřadu vlastním nebo cizím jménem a na vlastní nebo cizí účet.   - Hledisko výkonu funkcí úřadu vlastním nebo cizím jménem a na vlastní nebo cizí účet.
 +
 +Podle všech výše uvedených úhlů pohledu se liší potřeby funkcí úřadu na jejich aplikační podporu, proto je nutno mezi nimi rozlišovat a následně podle tohoto navrhovat řešení této aplikační podpory a volit způsob její realizace. Je důležité tyto vlastnosti funkcí úřadu znát a rozvoj aplikací úřadu podle nich prokazatelně řídit.
 +
 +Detailní referenční modely byznys architektury, rozpracovávající zde uvedená pravidla, včetně jejich grafického vyjádření, stanovuje a publikuje odbor Hlavního architekta Ministerstva vnitra ČR, ve spolupráci s odborem eGovernmentu Ministerstva vnitra ČR a organizacemi zastupujícími jednotlivé úrovně státní správy a samosprávy.
  
 === Hledisko míry podpory externích služeb pro klienty veřejné správy === === Hledisko míry podpory externích služeb pro klienty veřejné správy ===
Řádek 85: Řádek 88:
     * Hlavní procesy, funkce úřadu - úřad vykonává v interakci s externím klientem nebo pro výkon služby veřejné správy externímu klientovi     * Hlavní procesy, funkce úřadu - úřad vykonává v interakci s externím klientem nebo pro výkon služby veřejné správy externímu klientovi
     * Podpůrné procesy, funkce úřadu - úřad vykonává jako předpoklad, přímou podporu nebo návaznost na individuální poskytování služeb externím klientům     * Podpůrné procesy, funkce úřadu - úřad vykonává jako předpoklad, přímou podporu nebo návaznost na individuální poskytování služeb externím klientům
-    * Funkce a procesy správy zdrojů - úřad vykonává pro zajištění všech ostatních předpokladů a zdrojů dle své role a pozice ve veřejné správě, bez přímé souvislosti s podporou služeb svým individuálním externím klientům.+    * Funkce a procesy správy sdílených zdrojů - úřad vykonává pro zajištění všech ostatních předpokladů a zdrojů dle své role a pozice ve veřejné správě, bez přímé souvislosti s podporou služeb svým individuálním externím klientům.
     * Řídící a rozvojové funkce - vykonává úřad, aby byl schopen plánovat, realizovat, monitorovat a vyhodnocovat kvalitu a výkonnost svých funkcí a jejich další rozvoj.     * Řídící a rozvojové funkce - vykonává úřad, aby byl schopen plánovat, realizovat, monitorovat a vyhodnocovat kvalitu a výkonnost svých funkcí a jejich další rozvoj.
-    * Provozní funkce - vykonává úřad pro základní zajištění své udržitelné existence (provozu), bez ohledu na to, jaké jsou jeho hlavní, podpůrné a zdrojové funkce.+    * Provozní funkce - vykonává úřad jako správu základních zdrojů pro zajištění své udržitelné existence (provozu), bez ohledu na to, jaké jsou jeho hlavní, podpůrné a sdílené zdrojové funkce.
  
-{{ :soubor:zakladni_deleni_funkci_procesu_sluzeb.png | Základní dělení funkcí, procesů a služeb úřadu}}+{{ nap-dokument:zakladni_deleni_funkci_procesu_sluzeb.png | Základní dělení funkcí, procesů a služeb úřadu}}
  
 Referenční model byznys architektury úřadu dále dělí hlavní funkce pro výkon služeb zejména externím klientům (občané a zástupci organizací), ale i interním klientům (úřady a úředníci) na: Referenční model byznys architektury úřadu dále dělí hlavní funkce pro výkon služeb zejména externím klientům (občané a zástupci organizací), ale i interním klientům (úřady a úředníci) na:
Řádek 98: Řádek 101:
     * Agendově specifické funkce veřejné správy     * Agendově specifické funkce veřejné správy
   * Funkce společného zázemí agend - představující funkce vykonávané typicky (ale ne výhradně) mimo interakci s klientem, z angl. Back-Office (dále také BO), společně a jednotně pro více (až pro všechny) agend úřadu.   * Funkce společného zázemí agend - představující funkce vykonávané typicky (ale ne výhradně) mimo interakci s klientem, z angl. Back-Office (dále také BO), společně a jednotně pro více (až pro všechny) agend úřadu.
-  * Funkce správy spisů a případů - sloužící ke správě dokumentů a informací propojujících jednotlivé fáze (a funkční oblasti) vyřizování případů (řízení) klientů, interních i externích.+  * Funkce správy spisů a případů - sloužící ke správě dokumentů a informací propojujících jednotlivé fáze (a funkční oblasti) vyřizování případů (řízení) klientů, interních i externích. Všechny povinnosti vedení řádných dokumentů a spisů ve spisové službě nesmí nahrazovat evidence případů, které slouží jen pro zvláštní záležitosti vymykající se zaběhlým a řádným postupům.
   * Funkce integrace a spolupráce mezi úřady při výkonu služeb klientům.   * Funkce integrace a spolupráce mezi úřady při výkonu služeb klientům.
  
  
-{{ :soubor:dalsi_deleni_procesu_funkci_sluzeb.png |Další dělení (klasifikace) funkcí, procesů a služeb hlavní oblasti v kontextu ostatních funkčních oblastí}}+{{ nap-dokument:dalsi_deleni_procesu_funkci_sluzeb.png |Další dělení (klasifikace) funkcí, procesů a služeb hlavní oblasti v kontextu ostatních funkčních oblastí}}
  
  
 === Hledisko míry (a potenciálu) vymístění funkcí a využití sdílených služeb na místo individuálních funkcí === === Hledisko míry (a potenciálu) vymístění funkcí a využití sdílených služeb na místo individuálních funkcí ===
  
-Identifikované funkce v modelu byznys architektury úřadu je nutné posuzovat z hlediska dostupnosti již sdílených byznys služeb nebo potenciálu na vymístění (outsourcing) k poskytovateli takové sdílené služby - uvnitř úřadu nebo samosprávné jednotky z vlastního rozhodnutí, jinde ze zákona.+Identifikované funkce v modelu byznys architektury úřadu je nutné posuzovat z hlediska dostupnosti již sdílených byznys služeb nebo potenciálu na vymístění (outsourcing) k poskytovateli takové sdílené služby - uvnitř úřadu nebo samosprávné jednotky z vlastního rozhodnutí, jinde ze zákona nebo jiného předpisu.
  
 Přitom rozlišujeme následující možnosti (úrovně) sdílení na: Přitom rozlišujeme následující možnosti (úrovně) sdílení na:
Řádek 113: Řádek 116:
   * Celostátně (celoplošně) sdílené služby. Ty se na této i na všech další úrovních dělí ještě na:   * Celostátně (celoplošně) sdílené služby. Ty se na této i na všech další úrovních dělí ještě na:
     * služby externí na podporu klientů veřejné správy (a případně OVM) - služby hlavních a podpůrných procesy     * služby externí na podporu klientů veřejné správy (a případně OVM) - služby hlavních a podpůrných procesy
-    * služby interní na podporu úřadů a úředníků - služby zdrojových, řídících a provozních procesů+    * služby interní na podporu úřadů a úředníků - služby sdílených zdrojových, řídících a provozních procesů
   * Sdílené služby veřejnoprávních korporací (správců rozpočtových kapitol, krajských a místních (ORP) územních korporací)   * Sdílené služby veřejnoprávních korporací (správců rozpočtových kapitol, krajských a místních (ORP) územních korporací)
-  * Sdílené služby uvnitř úřadu - typicky služby pro obslužné funkce (FO), pro funkce zázemí agend (BO) a pro funkce správy spisů a případů+  * Sdílené služby uvnitř úřadu - typicky služby pro obslužné funkce (FO), pro funkce zázemí agend (BO) a pro funkce správy dokumentů, spisů a případů
   * Individuální (dílčí, specifické, nesdílené) funkce - typicky odborné agendové funkce (MO)   * Individuální (dílčí, specifické, nesdílené) funkce - typicky odborné agendové funkce (MO)
  
 === Hledisko výkonu funkcí úřadu vlastním nebo cizím jménem a na vlastní nebo cizí účet === === Hledisko výkonu funkcí úřadu vlastním nebo cizím jménem a na vlastní nebo cizí účet ===
  
-Jako protipól funkcí předaných k vykonání jinému úřadu, organizaci, vyskytují se v orgánech veřejné správy funkce vykonávaném pro někoho jiného, tj. cizím jménem, na cizí účet, případně obojí. U všech identifikovaných funkcí úřadu je nutné - vždy posuzovat i tento aspekt, tj. u činností (procesů, funkcí, služeb) čím jménem a na čí účet jsou vykonávány.+Jako protipól funkcí předaných k vykonání jinému úřadu, organizaci, vyskytují se v orgánech veřejné správy funkce vykonávaném pro někoho jiného, tj. cizím jménem, na cizí účet, případně obojí. U všech identifikovaných funkcí úřadu je nutné - vždy posuzovat i tento aspekt, tj. u činností (procesů, funkcí, služeb) čím jménem a na čí účet jsou vykonávány. Typickým příkladem takto převzatých funkcí jsou:
  
-Podle všech výše uvedených úhlů pohledu se liší potřeby funkcí úřadu na jejich aplikační podporu, proto je nutno mezi nimi rozlišovat a následně podle tohoto navrhovat řešení této aplikační podpory a volit způsob její realizace. Je důležité tyto vlastnosti funkcí úřadu znát a rozvoj aplikací úřadu podle nich prokazatelně řídit.+  * Výkon služeb veřejné správy přenesené působnosti 
 +  * Výkon korporátních nebo státních středisek sdílených služeb
  
-Detailní referenční modely byznys architektury, rozpracovávající zde uvedená pravidla, včetně jejich grafického vyjádření tj. Map, stanovuje a publikuje OHA MV, ve spolupráci s OeG a organizacemi zastupujícími jednotlivé úrovně státní správy a samosprávy. 
  
 ==== Ohlášení agend úřadu v RPP ==== ==== Ohlášení agend úřadu v RPP ====
Řádek 148: Řádek 151:
 998-1-1-1 **Jméno** vlastníka silničního vozidla. 998-1-1-1 **Jméno** vlastníka silničního vozidla.
  
-Smyslem této notace, oznámení agend v Registru práv a povinností a následné technologické specifikace je **jednoznačné oddělení právních a informačních zodpovědností.** Při návrhu publikace prostřednictvím Propojeného datového fondu (eGSBtedy správce agendy definuje právní rozdělení kontextů a údajů a správce příslušného agendového informačního systému následné informační rozdělení těchto údajů. Toto rozdělení pak jednoznačně definuje položku v předávané datové větě v rámci propojeného datového fondu a řízení oprávnění přístupu k této položce.+Smyslem této notace, oznámení agend v [[nap:rpp|Registru práv a povinností]] a následné technologické specifikace je **jednoznačné oddělení právních a informačních zodpovědností.** Při návrhu publikace prostřednictvím [[:nap:egsb|eGSB / ISSS]] tedy správce agendy definuje právní rozdělení kontextů a údajů a správce příslušného agendového informačního systému následné informační rozdělení těchto údajů. Toto rozdělení pak jednoznačně definuje položku v předávané datové větě v rámci propojeného datového fondu a řízení oprávnění přístupu k této položce.
  
 Správce Agendového informačního systému tedy musí spolupracovat se správcem agendy na ohlášení agendy tak, aby bylo možné provést jednoznačnou dekompozici údaje v kontextu na jedno informační položky. Definice těchto informačních položek je následovně součástí definice datového rozhraní. Správce Agendového informačního systému tedy musí spolupracovat se správcem agendy na ohlášení agendy tak, aby bylo možné provést jednoznačnou dekompozici údaje v kontextu na jedno informační položky. Definice těchto informačních položek je následovně součástí definice datového rozhraní.
Řádek 154: Řádek 157:
 **Zvolený princip zamezuje záměnám údajů podle jejich názvů (jméno vlastníka vozidla je určitě něco jiného než jméno vlastníka nemovitosti, ačkoli se obě položky jmenují jméno) a je nutné při návrhu všech datových rozhraní používat výše uvedenou číselnou hierarchickou notaci.** **Zvolený princip zamezuje záměnám údajů podle jejich názvů (jméno vlastníka vozidla je určitě něco jiného než jméno vlastníka nemovitosti, ačkoli se obě položky jmenují jméno) a je nutné při návrhu všech datových rozhraní používat výše uvedenou číselnou hierarchickou notaci.**
  
-Správce agendy při ohlášení také určuje, jaké údaje ze základních registrů či jiných agend má oprávnění při své činnosti využívat a správce agendového informačního systému pak při návrhu datového rozhraní čerpá z definice datových položek jednotlivých ISVS, které údaje/data publikují do propojeného datového fondu veřejné správy (definice WSDL na eGSB).+Správce agendy při ohlášení také určuje, jaké údaje ze základních registrů či jiných agend má oprávnění při své činnosti využívat a správce agendového informačního systému pak při návrhu datového rozhraní čerpá z definice datových položek jednotlivých ISVS, které údaje/data publikují do [[nap:propojeny_datovy_fond|propojeného datového fondu veřejné správy]].
  
 **Pokud je agenda vykonávána prostřednictvím více Agendových informačních systémů, pak správce agendy musí určit toho správce agendového informačního systému, který bude závazně určovat rozpad údaje na datové položky, a ostatní správci agendových informačních systémů musí tento rozpad respektovat.** **Pokud je agenda vykonávána prostřednictvím více Agendových informačních systémů, pak správce agendy musí určit toho správce agendového informačního systému, který bude závazně určovat rozpad údaje na datové položky, a ostatní správci agendových informačních systémů musí tento rozpad respektovat.**
Řádek 162: Řádek 165:
 Obslužné a komunikační kanály úřadu veřejné správy vůči jeho externím klientům je pro účely jejich efektivního řízení a jejich IT podpory možné dělit z několika úhlů pohledu, a to podle: Obslužné a komunikační kanály úřadu veřejné správy vůči jeho externím klientům je pro účely jejich efektivního řízení a jejich IT podpory možné dělit z několika úhlů pohledu, a to podle:
  
-  * Sdílení a subjektivity provozovatele obslužného kanálu na vlastní, centrální, v přenesené působnosti, u poskytovatelů služeb a další +  * Sdílení a subjektivity provozovatele obslužného kanálu na vlastní, centrální, v přenesené působnosti, u poskytovatelů služeb (třetích osob) a další 
-  * Podle míry zapojení klienta na samoobslužné nebo asistované (osobní, vně listinné či hlasové, ale vnitřně plně elektronické) +  * Podle míry zapojení klienta na  
-  * Podle vazby na místo a agendu na univerzální - bez místní a věcné příslušnosti, územní - s místní, ale bez věcné příslušnosti a agendové - s věcnou příslušností (jedné nebo více agend téhož ústředního správního úřadu), ale bez místní příslušnosti. +    * samoobslužné nebo  
-  * Podle komunikačního média a prostředku podání/doručení na osobní - diktát do protokolu na přepážce, listinné - poštou, kurýrem nebo na podatelně a na elektronické - Datovou schránkou, elektronicky podepsaným dokumentem do elektronické podatelny nebo do specifické aplikace úřadu (dle zvláštních zákonů).+    * asistované (osobní, vně listinné či hlasové, ale vnitřně plně elektronické) 
 +  * Podle vazby na místo a agendu na  
 +    * univerzální - bez místní a věcné příslušnosti,  
 +    * územní - s místní, ale bez věcné příslušnosti a  
 +    * agendové - s věcnou příslušností (jedné nebo více agend téhož ústředního správního úřadu), ale bez místní příslušnosti (historicky a v oprávněných případech i místní příslušností)
 +  * Podle komunikačního média a prostředku podání/doručení na osobní - sepsání protokolu, listinné - poštou, kurýrem nebo na podatelně a na elektronické - Datovou schránkou, elektronicky podepsaným dokumentem do elektronické podatelny nebo do specifické aplikace úřadu (dle zvláštních zákonů) nebo postupem popsaným na úřední desce úřadu.
  
-Cílem je, co nejvíce potřeb klientů obsloužit v prvním stupni obsluhy, v univerzálních kontaktních místech (UKM) - klientských centrech, jako je samoobslužný Portál klienta (občana, podnikatele, zástupce organizace a cizince) v PVS a asistovaný CzechPOINT. Přitom pro nezbytné individuální služby budou nadále k dispozici specializovaná kontaktní místa úřadů.+Cílem je, co nejvíce potřeb klientů obsloužit v prvním stupni obsluhy, tj. [[nap:univerzalni_kontaktni_misto|univerzálních kontaktních místech]] (také jako "UKM") - klientských centrech, jako je samoobslužný Portál klienta (občana, podnikatele, zástupce organizace a cizince) v PVS a asistovaný CzechPOINT. Přitom pro nezbytné individuální služby budou nadále k dispozici specializovaná kontaktní místa úřadů.
  
-Zásadou ježe kterémkoli UKM nalezne klient informace všech svých kontaktech a řízeních s veřejnou správou.+Výchozím předpokladem při návrhu řešení by měla být maximální snahaaby rámci UKM nalezl klient maximum dostupných informací o svých kontaktech a řízeních s veřejnou správou.
  
-V případě asistovaných kontaktních míst (univerzálních i v OVS) však zprostředkuje informace o všech informacích ze vztahu klienta a veřejné správy úředník, výhradně na základě explicitního zmocnění klientem. To je jediný případ, kdy smí úředník najednou vidět více než jednu agendu současně, přitom ale smí vidět pouze stavové informace z notifikací, tj. zda by měl klient agendě věnovat pozornost pro nějaké právo nebo povinnost. Na základě takového přehledu může dát klient pokyn, aby pro něj vyřízení jednotlivých agend po jedné úředník zprostředkoval.+V případě asistovaných kontaktních míst (univerzálních i v územních či agendových OVS) však zprostředkuje informace o všech informacích ze vztahu klienta a veřejné správy úředník, výhradně na základě explicitního zmocnění klientem. To je jediný případ, kdy smí úředník najednou vidět více než jednu agendu současně, přitom ale smí vidět pouze stavové informace z [[nap:notifikace|notifikací]], tj. zda by měl klient agendě věnovat pozornost pro nějaké právo nebo povinnost. Na základě takového přehledu může dát klient pokyn, aby pro něj vyřízení jednotlivých agend po jedné úředník zprostředkoval.
  
-Všechny úkony v obslužných kanálech musí být adekvátně zaznamenány ve spisové službě úřadu.+Všechny úkony v obslužných kanálech musí být adekvátně evidovány a zaznamenány v transakčním logu příslušných IS a ve spisové službě úřadu.
  
 Úřad veřejné správy je povinen v legislativě (může-li ji ovlivnit), v procesech úřadu a v jejich aplikační podpoře (v rozsahu dle platné legislativy) zajistit plnou rovnoprávnost všech obslužných kanálů a umožnit klientovi volbu mezi kanály. Úřad veřejné správy je povinen v legislativě (může-li ji ovlivnit), v procesech úřadu a v jejich aplikační podpoře (v rozsahu dle platné legislativy) zajistit plnou rovnoprávnost všech obslužných kanálů a umožnit klientovi volbu mezi kanály.
Řádek 179: Řádek 187:
 Preference kanálu, efektivnějšího z pohledu úřadu, tedy typicky elektronického samoobslužného kanálu, je možná pouze zvýšením jeho atraktivity pro klienta, nikoli regulatorním opatřením (nařízením, sankcí). Preference kanálu, efektivnějšího z pohledu úřadu, tedy typicky elektronického samoobslužného kanálu, je možná pouze zvýšením jeho atraktivity pro klienta, nikoli regulatorním opatřením (nařízením, sankcí).
  
-Pro informatickou podporu v úřadu dále vyplývá, že na konci horizontu pravidel této IKČR, aktuálně v roce 2022, platí pro všechny agendy úřadu, že:+Pro informatickou podporu v úřadu dále vyplývá, že na konci horizontu pravidel této IKČR, aktuálně v roce 2023, platí pro všechny agendy úřadu, že:
  
-  * Všechna řešení (zákonná i informatická) musí být navržena tak, aby vnitřně byla plně elektronická a vně podporovala všechny obslužné kanály (konverze dokumentů).+  * Všechna řešení (zákonná, byznys i informatická) musí být navržena tak, aby vnitřně byla plně elektronická a vně podporovala všechny obslužné kanály (konverze dokumentů).
   * Všechny kontaktní kanály, včetně specializovaných, budou podporovat navigaci ke službě (vyhledání služby) podle životních situací, vyplývajících z životních událostí klientů.   * Všechny kontaktní kanály, včetně specializovaných, budou podporovat navigaci ke službě (vyhledání služby) podle životních situací, vyplývajících z životních událostí klientů.
  
-Budou navrženy takové úpravy právního prostředí a IT řešení, aby v dlouhodobém horizontu podporovaly rovnost a provázanost obslužných kanálů (Multichannel) - tj. řízení je možné v kterémkoli kanálu začít, v jiném sledovat jeho průběh a v jiném řízení dokončit.+Budou navrženy takové úpravy právního prostředí, byznys procesů a funkcí a IT řešení, aby v dlouhodobém horizontu podporovaly rovnost a provázanost obslužných kanálů (Multichannel) - tj. řízení je možné v kterémkoli kanálu začít, v jiném sledovat jeho průběh a v jiném řízení dokončit.
  
-==== Portály občana a úředníka ==== 
  
-Portál je mimo jiné i technickým nástrojem pro on-line transakční služby klientům veřejné správy, pro informování o výkonu veřejné správy a pro interaktivní komunikaci ze strany klienta. Proto mají být součástí portálu také popsané životní situace (pokud možno interaktivní na základě parametrů), ale i elektronické formuláře pro podání a pro úkony učiněné klientem vůči orgánu veřejné moci, a to se schopností předvyplnění a dotažení dokládaných údajů. 
  
-Portály tedy nemohou být samostatné a nepropojené aplikace, ale naopak musí se jednat o prostředek, který je integrován s informačními systémy v úřadu. Především s elektronickou spisovou službou, s agendovými informačními systémy, ale třeba i s ekonomickými systémy tam, kde se jejich prostřednictvím shromažďují údaje o výplatách či o poplatcích podle jednotlivých klientů. Portál má sloužit klientovi k získání informací, jako prostředek pro publikování otevřených dat, statistik a veřejných výstupů, pro elektronická podání a komunikaci klienta s úřadem apod. Nově musí portál sloužit i držitelům zaručené elektronické identifikace jako prostředek pro získání jejich údajů, pro různé notifikace, ale třeba i pro interaktivní podání žádostí, či podání žádostí o výpisy apod. 
  
-Oba typy samoobslužných kanálů přístupu k externím a interním službám veřejné správy mají mnoho společného, ale v něčem se liší. Oba typy portálů mají uživateli zpřístupnit postupně všechny jemu nabízené elektronické služby a oba tak učiní hierarchickým, federalizovaným způsobem. 
- 
-V případě Portálu občana v PVS stojí občan jako samoobslužný uživatel „vně“ veřejné správy a portál mu poskytuje jedno univerzální vstupní místo dovnitř. Z toho důvodu jsou všechny věcné (agendové) a do budoucna i místní portály se svými službami federalizovány „pod“ tímto ústředním portálem. 
- 
-V případě portálů samospráv se předpokládají dva trendy: a) jednak budou lokální portály samospráv obsahovat obrácený směr navigace do Portálu občana, kde bude moci klient vyřídit vše ostatní ze státní správy, co případně nenašel v místním portálu a b) lokální portály budou moci být v dlouhodobé perspektivě nahrazovány místně přizpůsobenými službami centrálního Portálu občana v PVS. 
- 
-Naproti tomu v případě Portálu úředníka stojí úředník hluboko „uvnitř“ veřejné správy, nachází se ve svém úřadu, kde je ve státní službě nebo zaměstnán, a proto jako Portál úředníka primárně užívá Portál (Intranet) úřadu, resortu, kraje, obce. Tento lokální portál úředníka je pak federalizován s centrálním Portálem úředníka, který postupně agreguje (poskytuje) všechny celostátní elektronické služby pro úředníka. Úředník se tak prostřednictvím svého portálu dívá „ven“ ze svého oddělení, na všechny elektronické služby úřadu, resortu či korporace a celého eGovernmentu. 
- 
-Všechny sdílené portálové komponenty, které mají být užívány v lokálních portálech úředníka, musí být technicky i licenčně vyřešeny tak, aby se v těchto portálech daly využívat bez omezení a bez další finančních nároků. 
- 
-==== Služby pro životní situace - úplné elektronické podání (ÚEP) ==== 
- 
-Zejména byznys a aplikační architektura úřadu musí být v nových a významně měněných agendách a řešeních jejich IT podpory upravena tak, aby podporovala tzv. úplné elektronické podání (ÚEP). 
  
 ==== Vliv byznys architektury úřadu na možnosti řešení její IT podpory ==== ==== Vliv byznys architektury úřadu na možnosti řešení její IT podpory ====
Řádek 212: Řádek 204:
 Tam, kde úřad ze zákona zůstává zodpovědný za určitou činnost (agendu, podpůrnou funkci) nemůže využít sdílených řešení a ani na úrovni centrálních prvků eGovernmentu nebudou taková sdílená řešení připravována, dokud se zákonné podmínky pro tuto oblast nezmění. Tam, kde úřad ze zákona zůstává zodpovědný za určitou činnost (agendu, podpůrnou funkci) nemůže využít sdílených řešení a ani na úrovni centrálních prvků eGovernmentu nebudou taková sdílená řešení připravována, dokud se zákonné podmínky pro tuto oblast nezmění.
  
-Příkladem je ERP (rozpočetnictví) nebo spisová služba. Zde jak procesy, tak jejich aplikační podporu musí mít každý úřad vlastní, zůstává věcným správcem těchto řešení. Pokud je tedy úřad věcným správcem nějakého řešení, zachovává si za něj zodpovědnost a pravomoc o něm okamžitě rozhodovat - musí to být řešení v pravomoci tohoto úřadu.+Příkladem je ERP nebo spisová služba. Zde jak procesy, tak jejich aplikační podporu musí mít každý úřad vlastní, zůstává věcným správcem těchto řešení. PPokud je tedy úřad věcným správcem nějakého řešení, zachovává si za něj zodpovědnost a měl by mít pravomoc o něm okamžitě rozhodovat – mělo by to být řešení v pravomoci tohoto úřadu.
  
-V takovém případě, pro taková řešení jako je ERP nebo eSSL může OVS využít sdílené služby pouze na IT technologické a platformové úrovni, SW řešení mu musí poskytnuto maximálně tzv. multitenantní formou (více samostatných nájemníků) na společné technické infrastruktuře.+V takovém případě, pro taková řešení jako je ERP nebo eSSL může OVS využít sdílené služby pouze na IT technologické a platformové úrovni, SW řešení mu musí poskytnuto maximálně tzv. multitenantní formou (více samostatných nájemníků) na společné technické infrastruktuře, aby individuální zodpovědnost OVS za činnost a údaje zůstala zachována.
  
  
Řádek 221: Řádek 213:
  
  
 +<WRAP center round tip 60%>
 +Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí je popsán v části [[nap_dokument:architektura_a_sdilene_sluzby_verejne_spravy_cr|Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR]].
  
-<note important>Popis všech centrálně poskytovaných systémů a jejich služeb je popsán v části [[:nap:architektura_a_sdilene_sluzby_verejne_spravy_cr|Architektura sdílených služeb, funkčních celků a tématických oblastí veřejné správy ČR]].+Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části [[nap_dokument:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady]].
  
-Konkrétní implementační kroky a způsoby zapracování do informační koncepce OVS pro jednotlivé sdílené služby, funkční celky a tématické oblasti jsou popsány v kapitole [[:nap:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Pravidla pro architekturu sdílených služeb, funkčních celků a tématických oblastí jednotlivých úřadů]].+Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce. 
 +</WRAP>
  
-Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce v části XXX.</note> 
  
 +Z hlediska řízení informatizace představuje aplikační architektura těžiště řízení efektivní IT podpory výkonu veřejné správy. Rozvoj každého informačního systému úřadu se děje prostřednictvím rozvoje jeho aplikačních komponent, a to v kontextu všech ostatních aplikačních komponent úřadu a dostupných sdílených aplikačních služeb eGovernmentu. Proto je aktuální model cílového stavu aplikační architektury úřadu základem informační koncepce každého úřadu, orgánu veřejné správy.
  
-Z hlediska řízení informatizace představuje aplikační architektura těžiště řízení efektivní IT podpory výkonu veřejné správy. Rozvoj všech informačních systémů úřadu se děje prostřednictvím rozvoje jeho komponent a v kontextu všech ostatních aplikačních komponent úřadu a aplikačních služeb eGovernmentu. Proto je aktuální model cílového stavu aplikační architektury úřadu základem informační koncepce každého úřadu, orgánu veřejné správy. +Informační systémy veřejné správy slouží pro podporu výkonu agendy či agend veřejné správy. Musí tedy sloužit pro úředníka jako prostředek, který ho provádí jeho úřední činností a který mu pomáhá při jeho úřední práci, shromažďuje a doplňuje potřebné údaje, hlídá naplnění určitých povinností a nabízí řešení, ale třeba by měl být schopen i připravit návrh rozhodnutí v dané věci. Úředník by v ISVS, resp. v AIS měl dostat komplexní nástroj, který za něj vyřeší veškerou či alespoň značnou část administrativy a úředník tak bude mít čas na práci s klientem a na skutečné správní rozhodování tam, kde je takového rozhodování třeba. Stručně řečeno se mění evidenční úloha těchto IS na úlohu procesní.
- +
-Informační systémy veřejné správy slouží pro podporu výkonu agendy či agend veřejné správy. Musí tedy sloužit pro úředníka jako prostředek, který ho provádí jeho úřední činností a který mu pomáhá při jeho úřední práci, shromažďuje a doplňuje potřebné údaje, hlídá naplnění určitých povinností a nabízí řešení, ale třeba by měl být schopen i připravit návrh rozhodnutí v dané věci. Úředník by v ISVS měl dostat komplexní nástroj, který za něj vyřeší veškerou či alespoň značnou část administrativy a úředník tak bude mít čas na práci s klientem a na skutečné správní rozhodování tam, kde je takového rozhodování třeba.+
  
  
Řádek 237: Řádek 230:
  
  
-Informační systémy veřejné správy (ISVS), tak jak je definují jejich agendové nebo jiné zákony, se tedy obvykle skládají z jedné nebo více aplikačních komponent. Aplikační komponenty ISVS a ostatních informačních systémů úřadu, lze pro účely jejich správy dělit například podle míry sdílení aplikačních služeb a podle klientů těchto služeb, nebo podle vztahu IS k řetězci obsluhy klientů veřejné správy.+Informační systémy veřejné správy (ISVS), tak jak je definují jejich agendové nebo jiné zákony, se tedy obvykle skládají z jedné nebo více aplikačních komponent. Aplikační komponenty ISVS a ostatních informačních systémů úřadu, lze pro účely jejich správy dělit například podle toho, jaké skupiny byznys funkcí úřadu podporují, podle míry sdílení aplikačních služeb a podle klientů těchto služeb, nebo podle vztahu IS k řetězci obsluhy klientů veřejné správy.
  
 Vedoucí informatiky úřadu a techničtí správci ISVS jsou povinni ve spolupráci s jejich věcnými správci vytvořit a udržovat aktuální model dekompozice aplikačních komponent a aplikačních funkcí úřadu a její diagram, tzv. Mapu aplikačního portfolia/architektury úřadu. Vedoucí informatiky úřadu a techničtí správci ISVS jsou povinni ve spolupráci s jejich věcnými správci vytvořit a udržovat aktuální model dekompozice aplikačních komponent a aplikačních funkcí úřadu a její diagram, tzv. Mapu aplikačního portfolia/architektury úřadu.
Řádek 243: Řádek 236:
 Podporu pro rozhodování při řízení životního cyklu aplikačních komponent informačních systémů VS a současně vyjádření nejlepší praxe jejich inventarizace a třídění poskytuje tzv. Referenční model aplikační architektury, který základem aplikační mapy úřadu. Podporu pro rozhodování při řízení životního cyklu aplikačních komponent informačních systémů VS a současně vyjádření nejlepší praxe jejich inventarizace a třídění poskytuje tzv. Referenční model aplikační architektury, který základem aplikační mapy úřadu.
  
-{{ :soubor:rozdeleni_aplikacnich_komponent.png |Rozdělení aplikačních komponent úřadu do vrstev}}+{{ nap-dokument:rozdeleni_aplikacnich_komponent.png |Rozdělení aplikačních komponent úřadu do vrstev}}
  
-Dělení vychází z účelu aplikačních komponent shora počínaje úlohou uživatelského rozhraní a navigace až po platformy, zcela nezávislé na druzích uživatelů a poskytovaných služeb úřadu. V aplikační mapě se toto dělení uplatní jako vrstvy vertikální dimenze, viz obrázek 10.+Dělení vychází z účelu aplikačních komponent shora počínaje úlohou uživatelského rozhraní a navigace až po platformy, zcela nezávislé na druzích uživatelů a poskytovaných služeb úřadu. V aplikační mapě se toto dělení uplatní jako vrstvy vertikální dimenze.
  
-{{ :soubor:rpzdeleni_transakcnich_a_informacnich_komponent.png |Rozdělení transakčních a informačních (analytických) komponent}}+{{ nap-dokument:rpzdeleni_transakcnich_a_informacnich_komponent.png |Rozdělení transakčních a informačních (analytických) komponent}}
  
-Dále dělení aplikací vychází z byznys logiky podporovaných funkcí, kde na jedné straně jsou funkce (služby) pro vnější klienty, partnery a veřejnost, na druhé straně jsou funkce detailně podporující jednotlivé klíčové zdroje úřadu (znalosti, zaměstnance, majetek a zásoby (a jejich dodavatele), případně svěřené registry), viz obrázek 11.+Dále dělení aplikací vychází z byznys logiky podporovaných byznys funkcí, kde na jedné straně jsou to funkce (služby) pro vnější klienty, partnery a veřejnost, na druhé straně jsou funkce detailně podporující jednotlivé klíčové zdroje úřadu (znalosti, zaměstnance, majetek a zásoby (a jejich dodavatele), případně svěřené registry).
  
-Rozsah a obsah aplikací pro obslužnéodborné funkce zázemí agend se liší podle segmentů veřejné správy. Odlišnosti ostatních kategorií jsou minimálnípřevažují obdobné jednotné aplikační funkce.+Pokud zákon pro nějakou agendu definuje i způsob IT podpory evidence údajů, a zmocňuje tak k implementaci ISVS, není tím stanoveno, že by tento systém nemohl některé své komponenty využívat společně s ostatními agendami (agendovými systémy) téhož úřadu. Na druhou stranu dosud není možné, nestanovuje-li to explicitně zákon, sdílet v ISVS aplikační komponenty vlastněné jiným úřadem (ani příslušnou korporací, tj. rezortem, krajem nebo ORP).
  
-Povinností ředitele informatiky úřadu (technického správce) je zohlednit vzájemnou podobnost aplikací podle jejich kategorie při rozhodování o konsolidaci aplikací nebo o návrhu aplikační podpory kategoriíchkde je tato nedostatečná nebo chybí.+Z toho vyplývá aktuálně proveditelný požadavek na optimalizaci procesů a aplikačního portfolia úřadu tak, že pro průřezové procesy agend (podobné, íbuzné čjednotné byznys funkce a procesy) využije jednotných nebo dokonce centrálních sdílených komponent aplikačního portfolia úřadu (např. pro obsluhu klientů na přepážkách, portálovou samoobsluhu, řízení kontrol na místě, příjem a párování plateb apod., transkripce jmen osob ze zemí používajících jiné písmo, než latinka) rámci svého úřadupřípadně zákonem nebo jiným předpisem mu zpřístupněných centrálních sdílených aplikačních služeb na vyšší úrovni VS (korporace, centrální eGovernment).
  
-Referenční model aplikační architektury s plným detailem třídění a s odlišným obsahem klíčových transakčních komponent pro jednotlivé odlišující se segmenty veřejné správy (např. zdravotnictvípojistné agendydotační agendy, správa síťové infrastruktury apod.) stanovuje a publikuje OHA MV.+Pokud se takto sdílí v úřadu několik komponent napříč agendami, používají tyto pro externí označování klienta nikoli AIFO, ale nejlépe nějaké společné veřejné klientské číslo občana a organizace v rámci systému kmenových dat úřaduAIFOjako neveřejný identifikátorbude využíváno pouze při externí výměně údajů o klientovi v agendě prostřednictvím Back-End integrace přes [[nap:referencni_rozhrani|referenční rozhraní]].
  
-Pokud zákon pro nějakou agendu definuje i způsob IT podpory evidence údajů, zmocňuje tak k implementaci ISVS, není tím stanoveno, žby tento systém nemohl některé své komponenty využívat společně s ostatními agendami (a agendovými systémy) téhož úřadu.+=== Průřezové, IT a bezpečnostní služby ===
  
-Na druhou stranu dosud není možné, nestanovuje-li to explicitně zákonsdílet v ISVS aplikační komponenty vlastněné jiným úřadem (ani příslušnou korporací, tj. rezortem, krajem nebo ORP).+Rozsah a obsah aplikací pro obslužné, odborné a funkce zázemí agend se liší podle segmentů veřejné správy. Odlišnosti ostatních kategorií jsou minimálnípřevažují obdobné a jednotné aplikační funkce.
  
-Z toho vyplývá aktuálně proveditelný požadavek optimalizace procesů a aplikačního portfolia úřadu tak, že pro průřezové procesy agend (podobné, příbuzné či jednotné byznys funkce a procesy) využije jednotných nebo dokonce centrálních sdílených komponent aplikačního portfolia úřadu (napřpro obsluhu klientů na epážkách, portálovou samoobsluhu, řízení kontrol na místě, příjem a párování plateb apod., transkripce jmen osob ze zemí používajících jiné písmo, než latinka).+Obsah aplikací pro průřezové, IT a bezpečnostní služby je v referenčním modelu edstaven ve formě typových, logických aplikačních komponent. Tyrkysové komponenty edstavují výsledky zobecnění dosavadní praxe autorůzatímco oranžové komponenty byly evzaty z referenčního modelu EU (EIRA).
  
-Pokud se takto sdílí v úřadu několik komponent napříč agendami, používají tyto pro externí označování klienta nikoli AIFO, ale nejlépe nějaké společné klientské číslo občana v rámci systému úřadu. AIFO bude využíváno pouze při externí výměně údajů klientovi agendě prostřednictvím Back-End integrace přes ISZR a eGSB.+Povinností ředitele informatiky úřadu (technického správce) je zohlednit vzájemnou podobnost aplikací podle jejich kategorie při rozhodování konsolidaci aplikací nebo o návrhu aplikační podpory kategoriích, kde je tato nedostatečná nebo chybí.
  
 +Referenční model aplikační architektury s plným detailem třídění a s odlišným obsahem klíčových transakčních komponent pro jednotlivé odlišující se segmenty veřejné správy (např. zdravotnictví, pojistné agendy, dotační agendy, správa síťové infrastruktury apod.) bude vydán v následujících verzích [[:nap_dokument|NAP]].
  
-==== Pravidla pro uživatelská rozhraní a přístup k informačním systémům ====+{{ :nap-dokument:prurezove_it_sluzby.png | Průřezové, IT a bezpečnostní služby}}
  
  
-Uživatelská rozhraní ISVS i provozních systémů musí být především ergonomicky optimální pro nejlepší podporu odpovídajících uživatelských rolí a jejich výkonu externích i interních funkcí veřejné správy. 
  
-  * Úřad musí mít všechny svoje formuláře primárně v autentizované zóně portálu a umožnit předvyplnění údajů z PPDF s využitím zaručené identity klienta 
-  * Agendové a místní portály se budou rozšiřovat z informačních na transakční (ÚEP) 
-  * Transakční obsah portálu (formuláře) musí být integrován (federalizován) s PVS - Portál občana (cílově s předáním identity) 
-  * Identifikace uživatelů v portálu musí využívat národní identifikační schéma (NIA) 
  
-V případě uživatelských rolí zaměřených na jedinou agendu nebo malou část provozních funkcí, tj. roli pracující výhradně v určitém „informačním silu“, je upřednostněna efektivita práce před univerzalitou a skladebností uživatelského rozhraní. 
  
-IS poskytující služby uživatelům, kteří mají více rolí, často je střídají nebo potřebují informační podporu napříč „informačními sily“, musí vedle toho disponovat i odděleným (de-coupled, sligtly coupled), servisně orientovaným uživatelským rozhraním. Z toho současně plyne, že všechny odpovídající aplikační komponenty musí být alespoň „service enabled“, tzn., musí své funkce pro taková UI poskytovat v podobě orchestrovatelných webových služeb. 
  
-Kromě výjimečně zdůvodnitelných případů, například modelovacích nebo GIS nástrojů, nebo při nedostupnosti dostatečně propustného internetového připojení, nesmí být žádná byznys logika obsažena v uživatelském rozhraní, nýbrž musí být z aplikačních serverů dostupná jednotně pro všechny použité typy UI (lokální klient, webový klient, mobilní klient). Důvodem je usnadnění jednotné údržby byznys logiky při neustálých změnách (parametrizaci) funkcí IS. 
  
-IKČR předpokládá postupné sjednocování (unifikace) vzhledu a chování portálových aplikací ústředních správních úřadů pro dosažení jednotného ivatelského zážitku klienta. To platí zejména poté, co budou elementární služby úřadů dostupné „proklikem“ z portálu občana.+==== Pravidla pro uživatelská rozhraní a přístup k informačním systémům ====
  
-U místních portálů obcí IKČR naopak předpokládá i nadále lokální specifický „look & feel“, který podporuje sounáležitost občana s obcí, jako klíčovou podporovanou hodnotu, vedle ergonomie a efektivity obsluhy, která tím nesmí být dotčena. 
  
-Cílově IKČR předpokládá, že obce budou moci na místo budování lokálních portálů využívat SaaS služeb Portálu občana v PVS, a to v prvním kroku pro svěřené služby státní správy v enesené působnosti, později i pro služby samosprávy hospodářskou činnost obce. Proto tento účel bude v PVS možnost služby graficky lokalizovat, avšak při zachování jednotné navigace a nástrojů obsluhy.+Uživatelská rozhraní ISVS i provozních systémů musí být edevším ergonomicky optimální pro nejlepší podporu odpovídajících uživatelských rolí jejich výkonu externích i interních funkcí veřejné správy.
  
 +  * Úřad musí mít všechny svoje formuláře primárně v autentizované zóně [[nap:portaly_verejne_spravy_a_soukromopravnich_uzivatelu_udaju|portálu]] a umožnit předvyplnění údajů z [[nap:propojeny_datovy_fond|PPDF]] s využitím [[nap:elektronicka_identifikace_pro_klienty_verejne_spravy|zaručené identity klienta]]
 +  * Agendové a místní portály se budou rozšiřovat z informačních na transakční
 +  * Transakční obsah portálu (formuláře nebo uživatelská rozhraní portálových aplikací) musí být integrován (federalizován) s PVS - [[nap:portal_obcana|Portál občana]] 
 +  * Vyžaduje-li právní předpis nebo výkon působnosti prokázání totožnosti, lze umožnit prokázání totožnosti s využitím elektronické identifikace pouze prostřednictvím kvalifikovaného systému elektronické identifikace. Tato identifikace je nyní zajištěna pouze prostřednictvím [[nap:nia|národního identitního schématu]]
  
 +Kromě výjimečně zdůvodnitelných případů, například modelovacích nebo GIS nástrojů, nebo při nedostupnosti dostatečně propustného internetového připojení, nesmí být žádná byznys logika obsažena v uživatelském rozhraní, nýbrž musí být z aplikačních serverů dostupná jednotně pro všechny použité typy UI (lokální klient, webový klient, mobilní klient). Důvodem je usnadnění jednotné údržby byznys logiky při neustálých změnách (parametrizaci) funkcí IS.
 +
 +NAP předpokládá postupné sjednocování vzhledu a chování portálových aplikací ústředních správních úřadů pro dosažení jednotného uživatelského zážitku klienta. To platí zejména poté, co budou elementární služby úřadů dostupné „proklikem“ z portálu občana. Pro tento účel je zveřejněný [[https://designsystem.gov.cz/|grafický manuál MVČR]]
 +
 +Cílem je pro menší ústřední úřady a územní samosprávy umožnit místo budování lokálních portálů využívat SaaS služeb Portálu občana v PVS, a to v prvním kroku pro svěřené služby státní správy v přenesené působnosti, později i pro služby samosprávy a hospodářskou činnost obce. Proto tento účel bude v PVS možnost služby graficky lokalizovat, avšak při zachování jednotné navigace a nástrojů obsluhy.
 ==== Pravidla pro obslužné agendové aplikace (FO) ==== ==== Pravidla pro obslužné agendové aplikace (FO) ====
  
  
-Cílově musí být obslužné aplikační funkce jednotné a centralizované v úřadu, resortu (nebo korporaci) a státu tak, aby klientům veřejné správy umožňovaly dobrý „zážitek“ a efektivní obsluhu, a to úměrně výše uvedenému členění obslužných kanálů veřejné správy a požadavků na jejich podporu.+Cílově musí být obslužné aplikační funkce jednotné a centralizované v úřadu, resortu (nebo korporaci) a státu tak, aby klientům veřejné správy umožňovaly dobrý a jednotný „zážitek“ a efektivní obsluhu, a to úměrně výše uvedenému členění obslužných kanálů veřejné správy a požadavků na jejich podporu.
  
 To znamená, že aplikace obslužných kanálů stejného typu, například externí portál, musí být hierarchicky federativně integrované nebo zcela centrální. Aplikace různého typu, například uživatelské rozhraní pro fyzickou přepážku a pro portál musí být vzájemně integrovány tak, že užívají společnou aplikační logiku komunikace s klienty, která není vestavěna ani do portálu, ani do přepážkového SW, ale právě do společného aplikačního SW obslužných kanálů, také označovaného CRM, což ve veřejné správě znamená Citizen Relationship Management. To znamená, že aplikace obslužných kanálů stejného typu, například externí portál, musí být hierarchicky federativně integrované nebo zcela centrální. Aplikace různého typu, například uživatelské rozhraní pro fyzickou přepážku a pro portál musí být vzájemně integrovány tak, že užívají společnou aplikační logiku komunikace s klienty, která není vestavěna ani do portálu, ani do přepážkového SW, ale právě do společného aplikačního SW obslužných kanálů, také označovaného CRM, což ve veřejné správě znamená Citizen Relationship Management.
Řádek 298: Řádek 292:
 CRM společně s komunikačními technologiemi (web, mail, telefon, chat, SMS, DS, a další) zajistí jednotnou vícekanálovou obsluhu (multichannel, omnichannel). CRM společně s komunikačními technologiemi (web, mail, telefon, chat, SMS, DS, a další) zajistí jednotnou vícekanálovou obsluhu (multichannel, omnichannel).
  
-Podstatnou část agendové byznys logiky přebírají obslužné kanály z agendově specifických (Middle-Office) systémů a ze systémů agendového zázemí (Back-Office).+Podstatnou část agendové byznys logiky čerpají a prezentují obslužné kanály z agendově specifických (MiddleOffice) systémů a ze systémů agendového zázemí (Back-Office).
  
  
Řádek 304: Řádek 298:
  
  
-Ve všech případech, kdy má být veřejná služba v agendě zajišťována v přenesené působnosti nebo ve vlastní působnosti plošně v pobočkové síti (FŘ, OSSZ, Okresní soudy) je povinností ústředního správního úřadu ohlašujícího tuto agendu vystupovat jako věcný správce jejího ISVS a zajistit pro takovou agendu centrální agendový informační systém, pokrývající odborné agendové funkce (MO), případně funkce agendového zázemí (BO).+Ve všech případech, kdy má být veřejná služba v agendě zajišťována v přenesené působnosti nebo ve vlastní působnosti plošně v pobočkové síti (územní dekoncentráty - FŘ, OSSZ, Okresní soudy) je povinností ústředního správního úřadu ohlašujícího tuto agendu vystupovat jako věcný správce jejího ISVS a zajistit pro takovou agendu centrální agendový informační systém, pokrývající odborné agendové funkce (MO), případně funkce agendového zázemí (BO).
  
 Tento systém musí být dostupný prostřednictvím síťové infrastruktury státu ve všech obslužných místech veřejné správy, agendových i univerzálních. Musí být uzpůsoben k integraci na lokální i na celostátní aplikační komponenty pro obsluhu klientů (FO), pro lokální společné funkce zázemí agend (platby, vedení spisu apod.) (BO), zejména pak musí být integrovatelný na lokální spisovou službu, lokální saldokontní účetnictví klientů a lokální EkIS úřadu. Tento systém musí být dostupný prostřednictvím síťové infrastruktury státu ve všech obslužných místech veřejné správy, agendových i univerzálních. Musí být uzpůsoben k integraci na lokální i na celostátní aplikační komponenty pro obsluhu klientů (FO), pro lokální společné funkce zázemí agend (platby, vedení spisu apod.) (BO), zejména pak musí být integrovatelný na lokální spisovou službu, lokální saldokontní účetnictví klientů a lokální EkIS úřadu.
Řádek 310: Řádek 304:
 Uživatelské rozhraní těchto centrálních AIS musí být zařaditelné a volatelné z jednotné transakční navigace v centrálním portálu úředníků (intranetu veřejné správy) i (dočasně) v lokálním intranetu úřadu. Uživatelské rozhraní těchto centrálních AIS musí být zařaditelné a volatelné z jednotné transakční navigace v centrálním portálu úředníků (intranetu veřejné správy) i (dočasně) v lokálním intranetu úřadu.
  
-Pro aplikační architekturu úřadu potom platí, že úřad musí buď: +Pro aplikační architekturu úřadu potom platí, že úřad musí pro logicky centralizovaný AIS buď:
- +
-a) využívat tuto centrálně sdílenou aplikační komponentu, tj. poskytnout uživatelům úřadu uživatelský přístup k této komponentě prostřednictvím JIP/KAAS a integrovat tuto komponentu na Back-Office s ostatními nezbytně místními komponentami úřadu, jako je spisová služba úřadu nebo systém řízení obsluhy klientů.+
  
-b) využívat vlastní agendový systém úřadu pro tuto agendu, integrovaný na centrální sdílenou komponentu, sloužící jako její „tlustý klient“, avšak s plnou odpovědností úřadu za jeho legislativní aktualizaci.+  - využívat tuto centrálně sdílenou aplikační komponentu, tj. poskytnout uživatelům úřadu uživatelský přístup k této komponentě prostřednictvím JIP/KAAS a integrovat tuto komponentu na Back-Office s ostatními nezbytně místními komponentami úřadu, jako je spisová služba úřadu nebo systém řízení obsluhy klientů. 
 +  - b) využívat vlastní standardizovaný agendový systém úřadu pro tuto agendu (nebo multi-agendový), integrovaný na centrální sdílenou komponentu, sloužící jako její „tlustý klient“, avšak s plnou odpovědností úřadu za jeho legislativní aktualizaci.
  
-Pro obě varianty platí závazně jak pro věcného správce centrálního systému, tak pro lokální úřad s tím, že jak jejich interní zaměstnanectak externí klient nesmějí v rámci poskytnutí jedné služby této agendy v žádném případě zadávat žádné údaje dvakrát.+Pro obě varianty platí závazně jak pro věcného správce centrálního systému, tak pro lokální úřad architektonický požadavek, že ani  interní zaměstnanciani externí klient nesmějí v rámci poskytnutí jedné služby této agendy v žádném případě zadávat žádné údaje dvakrát.
  
 Výše uvedená centrální odborná agendová aplikace musí být správcem (ohlašovatelem agendy) poskytnuta včetně samoobslužného zákaznického portálu občana/podnikatele, zajišťujícího splnění principu Once Only. Současně tato centrální aplikace publikuje v agendě evidované agendové údaje do PPDF a publikuje veřejné údaje agendy do VDF jako otevřená data. Výše uvedená centrální odborná agendová aplikace musí být správcem (ohlašovatelem agendy) poskytnuta včetně samoobslužného zákaznického portálu občana/podnikatele, zajišťujícího splnění principu Once Only. Současně tato centrální aplikace publikuje v agendě evidované agendové údaje do PPDF a publikuje veřejné údaje agendy do VDF jako otevřená data.
Řádek 324: Řádek 317:
  
  
-Pokud úřad je činný ve více agendách, které všechny vedou na obdobné funkce zázemí agend (BO), například vedení spisu, příjem poplatku, výplata dávky, apod., bude pro tyto funkce užívat sdílené řešení (spisovou službu, saldokontní účetnictví, …) a měl by postupně sjednotit legislativu a procesy v těchto oblastech funkcí.+Pokud úřad je činný ve více agendách, které všechny vedou na obdobné funkce zázemí agend (BO), například vedení spisu, příjem poplatku, výplata dávky, apod., bude pro tyto funkce užívat sdílené řešení (spisovou službu, saldokontní účetnictví, …) a měl by postupně sjednotit legislativu a procesy v těchto oblastech funkcí. Je potřeba z byznysového pohledu myslet, že například správa daní se od obecného správního řízení liší v základní koncepci, a proto vždy budou existovat situace, které jsou sice pro správní proces přijatelné, avšak pro správu daní by byly zcela nepřijatelné. Z ICT pohledu se však jedná o přizpůsobení konkrétního řešení konkrétní situaci/problému - zvané také jako "parametrizace".
  
 Klíčovou komponentou této oblasti z pohledu klientů i úřadu je komponenta pro vedení kmene klientů a jejich pohledávkových/závazkových účtů (saldokonto). Tyto komponenty by měly být v každém úřadu centrální a jednotné, napříč agendami. Klíčovou komponentou této oblasti z pohledu klientů i úřadu je komponenta pro vedení kmene klientů a jejich pohledávkových/závazkových účtů (saldokonto). Tyto komponenty by měly být v každém úřadu centrální a jednotné, napříč agendami.
Řádek 333: Řádek 326:
  
  
-==== Pravidla pro aplikace spisové služby správy případů ====+==== Pravidla pro aplikace spisové službysprávy případů a workflow ====
  
 +Odlišné procesní nároky pro správu klientských případů a spisů, jednoznačně vztažených ke klientům (data vlastněná klienty a propůjčená do správy úřadům) a případů a spisů interní správy OVS (bez vazeb na klienta). Je doporučeno uvědomit si tyto odlišnosti, jim přizpůsobit vazby na AISy na jedné straně a vazby na provozní systémy (ERP, HR, nákup apod.) na druhé straně.
  
-Každý úřad by měpro evidenci všech úředních dokumentů zavést, provozovat a využívat jeden systém elektronické spisové služby, sdílený všemi agendami a útvary úřadu, pokud se z pohledu dobrého hospodáře nevyplatí užívat pro některou agendu samostatnou evidenci dle zák. o archivnictví. V takovém případě musí být obě evidence integrovány tak, aby se uživatelsky daly využívat společně (například v nich vyhledávat, nebo do nich volat služby s dotazem na stav dokumentu).+Z pohledu zákona o archivnictví a spisové službě existuje tzv. kategorie „určených původců“, která má povinnost vykonávat spisovou službu v elektronické podobě v elektronických systémech spisové služby. I přes rozdíly uvedené v předchozím odstavci o vazbách tedy každý určený původce musí pro evidenci všech dokumentů zavést, provozovat a využívat systém elektronické spisové služby, sdílený všemi agendami a útvary úřadu, pokud se z pohledu dobrého hospodáře nevyplatí užívat pro některou agendu samostatnou evidenci podle zákona o archivnictví. V takovém případě musí být obě (všechny) evidence integrovány v souladu s Národním standardem. Obdobně a přiměřeně by měli k výše uvedené problematice ohledem na architektonické principy přistupovat i úřady, které nejsou určenými původci.
  
-Pokud úřad pro své agendy vede více dokumentů pro jedno řízení (případ) v tzv. spisuměl by jako společnou a sdílenou komponentu zvážit právě funkcí správy těchto případů a spisů. Pokud navíc postupně stále více agend je ve svém vyřizování elektronizováno a automatizováno jako tzv. elektronické Workflow, měl by úřad disponovat jedinou sdílenou komponentou pro řízení tohoto workflow nad případy (a dokumenty nebo transakcemi) klientů.+Pokud úřad pro své agendy vede více dokumentů v téže věci, je povinen evidovat tyto dokumenty v tzv. spisu. Proto by pak měl jako společnou a sdílenou komponentu zvážit právě funkci správy spisů. Pokud navíc postupně stále více agend je ve svém vyřizování elektronizováno a automatizováno jako tzv. elektronického oběhu dokumentů (Workflow), měl by úřad disponovat jedinou sdílenou komponentou pro řízení tohoto workflow nad elektronickými dokumenty.  
 +Elektronický nástroj pro workflow by měl podporovat oba základní typy edávání práce: 
 +  * transakční workflow – kdy mezi pracovníky přechází odkaz na rozpracovanou transakci v agendovém nebo provozním IS, společně s odkazy na odpovídající dokumenty nebo spisy, které jsou přílohou. 
 +  * dokumentové workflow – kdy mezi pracovníky přechází jenom odkaz na dokument nebo spis ve spisové službě, případně, kdy je dokument nebo spis prostřednictvím workflow předáván
  
 +Uživatelský klientem pro workflow by měl(o) být současně (optimálně):
 +  * uživatelské rozhraní aplikace AIS, provozního systému nebo spisové služby, to podle typu workflow, viz výše
 +  * společné rozhraní přistupující do „workflow-inboxu“ v Portálu úředníka, kde jsou odkazy na veškerá probíhající workflow
 +  * rozhraní pro mailovou schránku úředníka umožňující práci s workflow obou typů"
  
 ==== Pravidla pro kategorii znalostních systémů ==== ==== Pravidla pro kategorii znalostních systémů ====
  
  
-Znalostní systémy v úřadu musí být konsolidovány tak, aby všechny informace a znalosti úřadu, s výjimkou informací o individuálním výkonu moci v agendě a klasifikovaných informací, byly dostupné pro vzdělávání a podporu výkonu služeb pro všechny zaměstnance úřadu, se společným vyhledáváním informací v intranetu úřadu.+Znalostní systémy v úřadu musí být konsolidovány tak, aby všechny informace a znalosti úřadu, s výjimkou informací o individuálním výkonu moci v agendě a klasifikovaných informací, byly dostupné pro vzdělávání a podporu výkonu služeb pro všechny zaměstnance úřadu, se společným vyhledáváním informací v intranetu úřadu / Portálu úředníka..
  
 Pro informační systémy poskytující informace o platném, historickém i připravovaném právu platí, že v úřadech mohou být provozovány jenom takové systémy a pouze pro takové funkce, které nejsou podporovány centrálním systémem eSbírka/eLegislativa. Pro informační systémy poskytující informace o platném, historickém i připravovaném právu platí, že v úřadech mohou být provozovány jenom takové systémy a pouze pro takové funkce, které nejsou podporovány centrálním systémem eSbírka/eLegislativa.
Řádek 352: Řádek 353:
  
  
-Každý úřad je povinen zvážit ve své architektuře pořízení řešení pro centrální správu identit a oprávnění uživatelů(také zvané IDM (Identity Management), IAM (Identity & Access Management)) úřadu a její integraci s personálním systémem úřadu na jedné straně a s centrálním jednotným identitním prostorem úředníků VS ČR na druhé straně (aktuálně řešení JIP/KAAS).+Každý úřad je povinen zvážit ve své architektuře pořízení řešení pro centrální správu identit a oprávnění uživatelů (také zvané IDM (Identity Management), nebo IAM (Identity & Access Management)) úřadu a její integraci s personálním systémem úřadu na jedné straně a s centrálním jednotným identitním prostorem úředníků VS ČR na druhé straně (aktuálně řešení JIP/KAAS).
  
-  * Povinnost napojení autentizace autorizace klientů na JIP/NIA a úředníků na JIP/KAAS+  * Povinnost napojení identifikace autentizace klientů na kvalifikovaný systém, který je v současnosti pouze [[nap:nia|NIA]]  
 +  * Povinnost napojení identifikace, autentizace autorizace úředníků na JIP/KAAS
   * Doporučení realizovat centrální správu identit úřadu (IDM), napojenou u úředníků na HR (HCM)   * Doporučení realizovat centrální správu identit úřadu (IDM), napojenou u úředníků na HR (HCM)
  
 ==== Pravidla pro integrační platformy ==== ==== Pravidla pro integrační platformy ====
  
-Častým problémem je, že u správců ISVS jsou tyto informační systémy budované jako autonomní bloky, které nejsou řádně a správně propojeny a integrovány s dalšími informačními systémy a komponentami v úřadu. Je nutno na to myslet již při sestavování prvotní architektury a důsledně zajistit tyto integrace, a to formou otevřených, a především popsaných a nahraditelných rozhraní, nikoliv jako blackboxy na dohodě dodavatelů.+Častým problémem je, že u správců ISVS jsou tyto informační systémy budované jako autonomní bloky, které nejsou řádně a správně propojeny a integrovány s dalšími informačními systémy a komponentami v úřadu. Je nutno na to myslet již při sestavování prvotní architektury a důsledně zajistit tyto integrace, a to formou otevřených, a především popsaných a nahraditelných rozhraní, nikoliv jako blackboxy (peer-to-peer, P2P) na dohodě dodavatelů.
  
 Každý informační systém veřejné správy musí být integrován s: Každý informační systém veřejné správy musí být integrován s:
  
-  * Elektronickým systémem spisové služby pro odbornou správu dokumentů a pro úkony spojené s dokumenty, kdy ESSL je tím nástrojem pro výkon spisové služby evidenci všech dokumentů+  * Elektronickým systémem spisové služby – pro vedení spisové služby, případně se samostatnou evidencí dokumentů pro odbornou správu dokumentů a pro úkony spojené s dokumenty, kdy výše uvedené systémy jsou nástroji buď pro výkon spisové služby, případně pro evidenci dokumentů. Tyto systémy musí pak být vždy v souladu s Národním standardem dle zákona č. 499/2004 Sb
   * Provozními systémy typu IDM a monitoringu   * Provozními systémy typu IDM a monitoringu
   * Auditovacími a logovacími systémy - pro zajištění logování nakládání s údaji evidovanými v ISVS včetně ale nikoliv pouze osobních údajů   * Auditovacími a logovacími systémy - pro zajištění logování nakládání s údaji evidovanými v ISVS včetně ale nikoliv pouze osobních údajů
Řádek 370: Řádek 372:
 Preferovaným způsobem integrace aplikací je využití standardní integrační platformy (též Enterprise Application Integration, dále též jen „EAI“, nebo synonymum Enterprise Service Bus, dále též jen ESB), která nahradí P2P integraci úřadu a poskytuje funkce pro zejména asynchronní integraci (nečekající na potvrzení zápisu do databáze či odpověď), obsloužení front, logování apod. Preferovaným způsobem integrace aplikací je využití standardní integrační platformy (též Enterprise Application Integration, dále též jen „EAI“, nebo synonymum Enterprise Service Bus, dále též jen ESB), která nahradí P2P integraci úřadu a poskytuje funkce pro zejména asynchronní integraci (nečekající na potvrzení zápisu do databáze či odpověď), obsloužení front, logování apod.
  
-Každý úřad bude využívat vlastní nebo sdílenou EAI propojenou na centrální eGSB.+Každý úřad bude využívat vlastní nebo sdílenou EAI propojenou na centrální [[:nap:egsb|eGSB / ISSS]].
  
 Tato pravidla v souladu s NAP předpokládají vícestupňovou hierarchickou strukturu integračních platforem. Tato pravidla v souladu s NAP předpokládají vícestupňovou hierarchickou strukturu integračních platforem.
  
-Pro zapojení úřadů do sdílení v rámci propojeného datového fondu je vybudována centrální integrační platforma eGSB (eGovernment Service Bus). Na ni se úřady přednostně napojují prostřednictvím korporátních integračních platforem resortů (krajů, ORP) nebo prostřednictvím vlastních EAI, pokud takovou mají.+Pro zapojení úřadů do sdílení v rámci propojeného datového fondu je vybudována centrální integrační platforma [[:nap:egsb|eGSB / ISSS]]. Na ni se úřady přednostně napojují prostřednictvím korporátních integračních platforem resortů (krajů, ORP) nebo prostřednictvím vlastních EAI, pokud takovou mají.
  
 Korporátní EAI slouží primárně pro potřeby interní integrace v rámci kapitoly nebo veřejné korporace, jako externí integrace pro úřad ministerstva nebo územního celku a jako sdílená služba pro podřízené organizace korporace, pro které není výhodné vybudovat EAI vlastní. Korporátní EAI slouží primárně pro potřeby interní integrace v rámci kapitoly nebo veřejné korporace, jako externí integrace pro úřad ministerstva nebo územního celku a jako sdílená služba pro podřízené organizace korporace, pro které není výhodné vybudovat EAI vlastní.
Řádek 410: Řádek 412:
  
  
-<note important>Popis všech centrálně poskytovaných systémů a jejich služeb je popsán v části [[:nap:architektura_a_sdilene_sluzby_verejne_spravy_cr|Architektura sdílených služeb, funkčních celků a tématických oblastí veřejné správy ČR]].+<WRAP center round tip 60%> 
 +Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí je popsán v části [[nap_dokument:architektura_a_sdilene_sluzby_verejne_spravy_cr|Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR]].
  
-Konkrétní implementační kroky a způsoby zapracování do informační koncepce OVS pro jednotlivé sdílené služby, funkční celky a tématické oblasti jsou popsány v kapitole [[:nap:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Pravidla pro architekturu sdílených služeb, funkčních celků a tématických oblastí jednotlivých úřadů]].+Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části [[nap_dokument:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady]].
  
-Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce části XXX.</note>+Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce
 +</WRAP> 
 + 
 +<WRAP center round info 60%> 
 +Datová architektura IS VS je formálně součástí jedné vrstvy společně s aplikační architekturou. Zde jsou popsány rozděleně z důvodu důrazu na práci a pravidla pro systém a práci a pravidla pro data/údaje, se kterými pracují. 
 +</WRAP>
  
  
Řádek 430: Řádek 438:
 Každý správce ISVS, který obsahuje nějaký datový fond, je povinen zajistit (správce ISVS musí): Každý správce ISVS, který obsahuje nějaký datový fond, je povinen zajistit (správce ISVS musí):
  
-  - **Referenčnost -** ztotožnit všechny subjekty/objekty vedené v základních registrech (fyzické osoby – ROB, právnické osoby – ROS, adresní body a další územní prvky - RUIAN) a začít přijímat notifikace o změnách údajů o těchto subjektech/objektech jak ze základních registrů, tak od dalších agendových zdrojů.+  - **Referenčnost -** ztotožnit všechny subjekty/objekty vedené v základních registrech (fyzické osoby – ROB, právnické osoby – ROS, adresní body a další územní prvky - RUIAN) a začít přijímat [[nap:notifikace|notifikace]] o změnách údajů o těchto subjektech/objektech jak ze základních registrů, tak od dalších agendových zdrojů.
   - **Jednoznačnost -** rozdělit si datový fond na části   - **Jednoznačnost -** rozdělit si datový fond na části
     - **Referenční údaje** – musí být v souladu se základními registry     - **Referenční údaje** – musí být v souladu se základními registry
     - **Agendové údaje** – pochází od editorů základních registrů (např. Evidence Obyvatel) nebo jiných agendových informačních systémů (např. registr řidičů) v rámci agendy jsou pouze využívány     - **Agendové údaje** – pochází od editorů základních registrů (např. Evidence Obyvatel) nebo jiných agendových informačních systémů (např. registr řidičů) v rámci agendy jsou pouze využívány
     - **Vlastní údaje agendy** – údaje vytvářené v rámci agendy (mohou být dále poskytovány jiným agendám jako agendové)     - **Vlastní údaje agendy** – údaje vytvářené v rámci agendy (mohou být dále poskytovány jiným agendám jako agendové)
-  - **Bezpečnost a důvěrnost** – musí být zajištěna jak z hlediska ochrany osobních údajů, tak i z hlediska zabezpečení proti ztrátě či neoprávněnému pozměnění údajů+  - **Bezpečnost** – musí být zajištěna jak z hlediska ochrany osobních údajů, tak i z hlediska zabezpečení proti ztrátě či neoprávněnému pozměnění údajů
  
  
Řádek 450: Řádek 458:
 IKČR ukládá úřadům udržovat aktuální klasifikace základních informačních (datových) objektů architektury úřadu. Tyto identifikované objekty musí být klasifikovány do následujících kategorií a je nutné s nimi v aplikační architektuře nakládat způsobem, odpovídajícím jejich klasifikaci. IKČR ukládá úřadům udržovat aktuální klasifikace základních informačních (datových) objektů architektury úřadu. Tyto identifikované objekty musí být klasifikovány do následujících kategorií a je nutné s nimi v aplikační architektuře nakládat způsobem, odpovídajícím jejich klasifikaci.
  
-Všechny údaje spravované v IS úřadu, tvoří tzv. **datový fond úřadu**. Základní existenciální (statické, kartotéční) údaje o subjektech (klientech, dodavatelích, zaměstnancích, apod.) a o objektech veřejné správy (evidovaná vozidla, kulturní památky, hospodářská zvířata, vl. majetek úřadu, apod.) představují tzv. **datový kmen úřadu**, nebo jeho kmenová data. Naproti tomu údaje o řízeních (operacích, úkonech) se subjekty nebo nad objekty veřejné správy se nazývají transakční data úřadu. Kmenová a transakční data jsou dvě nejdůležitější součásti datového fondu úřadu, další kategorie dat jsou představeny níže.+Všechny údaje spravované v IS úřadu, tvoří tzv. **datový fond úřadu**. Základní existenciální (statické, kartotéční) údaje o subjektech (klientech, dodavatelích, zaměstnancích, apod.) a o objektech veřejné správy (evidovaná vozidla, kulturní památky, hospodářská zvířata, vl. majetek úřadu, apod.) představují tzv. **datový kmen úřadu**, nebo jeho kmenová data. Naproti tomu údaje o řízeních (operacích, úkonech) se subjekty nebo nad objekty veřejné správy se nazývají **transakční data úřadu**. Kmenová a transakční data jsou dvě nejdůležitější součásti datového fondu úřadu, další kategorie dat jsou představeny níže.
  
-Zásadním požadavkem informační koncepce z hlediska klasifikace dat ve veřejné správě je zavedení pojmu **agendový údaj**. V současné době je již zaveden zákoně o základních registrech (§ 2) pojem referenční údaj. Agendový údaj má obdobnou datovou kvalitu a je nutné zajistit i právní jistotu při jeho využívání. Jde například o údaje týkající se řidičů, vozidel, vzdělání fyzických osob, kvalifikace osob fyzických či právnických k provádění činnosti dle zákona (lékař, vzdělávací instituce, akreditační středisko apod.).+Zásadním požadavkem informační koncepce z hlediska klasifikace dat ve veřejné správě je zavedení pojmu **agendový údaj**. V současné době je již zaveden zákoně o základních registrech (§ 2) pojem referenční údaj. Agendový údaj má obdobnou datovou kvalitu při jeho využívání, ale za jeho kvalitu a záruku ručí jeho poskytovatel, což je ve většině případů [[nap:agendovy_model_verejne_spravy|ohlašovatel agendy]]. Jde například o údaje týkající se řidičů, vozidel, vzdělání fyzických osob, kvalifikace osob fyzických či právnických k provádění činnosti dle zákona (lékař, vzdělávací instituce, akreditační středisko apod.).
  
 Použitím výše uvedených principů můžeme údaje vedené v datovém fondu informačního systému veřejné správy (agendě), a souhrnně v datovém fondu úřadu, rozdělit z několika hledisek. Prvotním hlediskem je klasifikace datových objektů z hlediska zodpovědnosti za jejich validitu, viz výše bod **jednoznačnost.** Použitím výše uvedených principů můžeme údaje vedené v datovém fondu informačního systému veřejné správy (agendě), a souhrnně v datovém fondu úřadu, rozdělit z několika hledisek. Prvotním hlediskem je klasifikace datových objektů z hlediska zodpovědnosti za jejich validitu, viz výše bod **jednoznačnost.**
Řádek 461: Řádek 469:
   * Transakční data individuálních řízení v agendách   * Transakční data individuálních řízení v agendách
   * Dokumenty   * Dokumenty
 +  * Prostorová data
   * Analytická (agregovaná, anonymizovaná nebo jinak transformovaná) data   * Analytická (agregovaná, anonymizovaná nebo jinak transformovaná) data
   * Signálová data (datový proud v reálném čase)   * Signálová data (datový proud v reálném čase)
-  * Metadata analytických dat, dokumentů a multimediálních objektů+  * Metadata prostorových dat, analytických dat, dokumentů a multimediálních objektů
   * Provozní a bezpečnostní auditní data (logy)   * Provozní a bezpečnostní auditní data (logy)
-  * Parametrizační, customizační data, řídící číselníky (jazyky, měny, směrovací čísla, typy daní, kategorie sazeb, druhy paliv, kategorie vozidel, NACE, atd.)+  * Parametrizační data, řídící číselníky (jazyky, měny, směrovací čísla, typy daní, kategorie sazeb, druhy paliv, kategorie vozidel, NACE, atd.)
   * Data programového kódu (zdrojový kód v databázi)   * Data programového kódu (zdrojový kód v databázi)
  
-Zásadní klasifikace datových objektů nejen v datovém kmeni, ale i v dalších výše uvedených datových objektech je podle obsažení osobních údajů:+Další zásadní klasifikace datových objektů nejen v datovém kmeni, ale i v dalších výše uvedených datových objektech je podle obsažení osobních údajů:
  
   * Obsahující osobní údaje   * Obsahující osobní údaje
-  * Obsahující citlivé osobní údaje+  * Obsahující zvláštní kategorie osobních údajů (dříve jako citlivé osobní údaje)
   * Neobsahující osobní údaje.   * Neobsahující osobní údaje.
  
-Zásadním nástrojem pro správu datových objektů o subjektech a objektech práva obsažených v datovém kmeni agendy je Registr práv a povinností. Při ohlášení agendy je nutné uvést výčet údajů vedených v agendě dle zákona 111/2009 Sb. o základních registrech §51 odst. 6) písm. h). Tyto podklady slouží pro oznamovatele jiných agendy, kteří dle písmene j) tohoto ustanovení registrují požadavek na využívání těchto údajů.+Základním nástrojem pro správu datových objektů o subjektech a objektech práva obsažených v datovém kmeni agendy je Registr práv a povinností. Při ohlášení agendy je nutné uvést výčet údajů vedených v agendě dle zákona 111/2009 Sb. o základních registrech § 51 odst. 5) písm. h). Tyto podklady slouží pro oznamovatele jiných agendy, kteří dle písmene j) tohoto ustanovení registrují požadavek na využívání těchto údajů.
  
-V rámci RPP jsou udržovány informace o takto poskytovaných a využívaných údajích z legislativního hlediska, tj. tak jak jsou uvedeny v odpovídajícím právním předpisu. Z hlediska technického využití je pak správce ISVS, který údaje poskytuje prostřednictvím eGSB publikovat odpovídající technický předpis jak XML šablonu v rámci WSDL předpisu využívání publikovaných služeb eGSB.+V rámci RPP jsou udržovány informace o takto poskytovaných a využívaných údajích z legislativního hlediska, tj. tak jak jsou uvedeny v odpovídajícím právním předpisu. Z hlediska technického využití je pak správce ISVS, který údaje poskytuje prostřednictvím [[:nap:egsb|eGSB / ISSS]] publikovat odpovídající technický předpis jak XML šablonu v rámci WSDL předpisu využívání publikovaných služeb [[:nap:egsb|eGSB / ISSS]].
  
-Z technického hlediska je tedy závazný předpis, jakým jsou data publikovány pro využívání na rozhraní Informačního systému základních registrů a eGSB. Tím je sjednoceno referenční rozhraní veřejné správy a zajištěna jednoznačná technologická prezentace právních pojmů z hlediska přenášených údajů.+Z technického hlediska je tedy závazný předpis, jakým jsou data publikovány pro využívání na rozhraní [[nap:referencni_rozhrani|Informačního systému základních registrů a eGSB/ISSS]]. Tím je sjednoceno referenční rozhraní veřejné správy a zajištěna jednoznačná technologická prezentace právních pojmů z hlediska přenášených údajů.
  
-Současně tato koncepce **nepředpokládá** možnost výměny údajů mezi informačními systémy veřejné správy mimo referenční rozhraní+Současně se **nepředpokládá** možnost výměny údajů mezi informačními systémy veřejné správy mimo referenční rozhraní.
- +
-Informační koncepce přepokládá novelizaci vyhlášek o datových prvcích informačních systémů (496/2006 Sb.) a referenčním rozhraní (53/2007 Sb.) tak, aby reflektovaly výše uvedené zásady.+
  
  
Řádek 504: Řádek 511:
  
  
-V rámci svého lokálního informačního systému mohou, respektive musí být úřadem pro výkon agendy využívány referenční a agendové údaje. Tyto údaje mohou být využívány on-line při jejich potřebě dotazem na referenční rozhraní (ISZR a eGSB), nebo může být v uložena jejich kopie pro sujekty a objekty vedené v rámci agendy.+V rámci svého lokálního informačního systému mohou, respektive musí být úřadem pro výkon agendy využívány referenční a agendové údaje. Tyto údaje mohou být využívány on-line při jejich potřebě dotazem na referenční rozhraní (ISZR a eGSB/ISSS), nebo může být v uložena jejich kopie pro subjekty a objekty vedené v rámci agendy.
  
 **Agendový údaj:** **Agendový údaj:**
Řádek 515: Řádek 522:
  
   * Správce (agendy) registruje u Registru práv a povinností údaj jako agendový   * Správce (agendy) registruje u Registru práv a povinností údaj jako agendový
-  * Správce publikuje údaj v rámci vybraného kontextu s vazbou na subjekt/objekt prostřednictvím eGSB+  * Správce publikuje údaj v rámci vybraného kontextu s vazbou na subjekt/objekt prostřednictvím [[:nap:egsb|eGSB / ISSS]]
   * Správce publikuje změny agendového údaje   * Správce publikuje změny agendového údaje
   * Správce přijímá reklamace na stav agendového údaje   * Správce přijímá reklamace na stav agendového údaje
   * Agenda využívající agendový údaj registruje tento požadavek v Registru práv a povinností   * Agenda využívající agendový údaj registruje tento požadavek v Registru práv a povinností
-  * Agenda využívá údaj prostřednictvím eGSB+  * Agenda využívá údaj prostřednictvím [[:nap:egsb|eGSB / ISSS]]
   * Pokud agenda ukládá ve svém datovém fondu tento údaj, pak ho udržuje v souladu se skutečností odběrem změn   * Pokud agenda ukládá ve svém datovém fondu tento údaj, pak ho udržuje v souladu se skutečností odběrem změn
   * Pokud je při činnosti agendy zjištěna pochybnost o správnosti údaje, pak oznámí správci údaje   * Pokud je při činnosti agendy zjištěna pochybnost o správnosti údaje, pak oznámí správci údaje
Řádek 525: Řádek 532:
 Z hlediska efektivity výkonu veřejné správy je zásadní, jak efektivně jsou referenční a agendové údaje z referenčního rozhraní využívány. Současně je nutné architektonicky zabezpečit, aby výkon veřejné správy byl maximálně odolný vůči výpadkům centrálních komponent. Z hlediska efektivity výkonu veřejné správy je zásadní, jak efektivně jsou referenční a agendové údaje z referenčního rozhraní využívány. Současně je nutné architektonicky zabezpečit, aby výkon veřejné správy byl maximálně odolný vůči výpadkům centrálních komponent.
  
-a) Pokud nejsou tyto údaje ve větším množství v rámci agendy využívány, pak je nejefektivnější a nejbezpečnější jejich využívání na základě on-line dotazů v okamžiku potřeby. V datech agendy pak nejsou údaje trvale uloženy, ale je uložen pouze jejich tvar získaný v okamžiku dotazu a v souvislosti s daným účelem.+  - Pokud nejsou tyto údaje ve větším množství v rámci agendy využívány, pak je nejefektivnější a nejbezpečnější jejich využívání na základě on-line dotazů v okamžiku potřeby. V datech agendy pak nejsou údaje trvale uloženy, ale je uložen pouze jejich tvar získaný v okamžiku dotazu a v souvislosti s daným účelem
 +  - Pokud jsou tyto údaje využívány agendou ve větším množství, nebo v případě nedostupnosti centrálních systémů hrozí nebezpečí z prodlení, pak je efektivní údržba lokální kopie referenčních a agendových údajů o subjektech a objektech agendy pro potřeby jejího výkonu. V tomto případě je nezbytně nutná systematická údržba těchto údajů tak, aby byly **v souladu** s údaji vedenými v základních registrech a agendových zdrojů. Za tímto účelem je nutné využívat procesu [[nap:notifikace|notifikace]] změn a aktualizace údajů o subjektech a objektech, pro které byla tato změna notifikována.
  
-b) Pokud jsou tyto údaje využívány agendou ve větším množství, nebo v ípadě nedostupnosti centrálních systémů hrozí nebezpečí z prodlení, pak je efektivní údržba lokální kopie referenčních a agendových údajů o subjektech a objektech agendy pro potřeby jejího výkonu. V tomto případě je nezbytně nutná systematická údržba těchto údajů tak, aby byly **v souladu** s údaji vedenými v základních registrech a agendových zdrojů. Za tímto účelem je nutné využívat procesu notifikace změn a aktualizace údajů subjektech a objektechpro které byla tato změna notifikována.+Princip [[nap:notifikace|notifikace]] je zásadně typu **pull** a bez edávání údajů při [[nap:notifikace|notifikaci]]. Tedy agenda využívající údaje požádá o seznam subjektů či objektůpro které za uplynulé období (typicky jeden den) došlo ke změně údaje. Daný seznam pak využije k aktivnímu dotazu na zdroj údajů, kde získává údaje dle svých oprávnění. Je tak tedy zajištěnože během [[nap:notifikace|notifikací]] nemohou být předány údaje, na které agenda nemá oprávnění. Současně při dotazech na fyzickou či právnickou osobu je vytvořen záznam v základních registrech a dotčený subjekt práva získá informaci tomže agenda aktualizovala údaje o něm ve svém datovém kmeni.
  
-Princip notifikace je zásadně typu **pull** a bez předávání údajů při notifikaci. Tedy agenda využívající údaje požádá o seznam subjektů či objektů, pro které za uplynulé období (typicky jeden den) došlo ke změně údaje. Daný seznam pak využije k aktivnímu dotazu na zdroj údajů, kde získává údaje dle svých oprávnění. Je tak tedy zajištěno, že během notifikací nemohou být předány údaje, na které agenda nemá oprávnění. Současně při dotazech na fyzickou či právnickou osobu je vytvořen záznam v základních registrech a dotčený subjekt údajů získá informaci o tom, že agenda aktualizovala údaje o něm ve svém datovém kmeni. +V případě, že OVS využívá více než jeden vlastní (lokální) agendový informační systém a využívá referenčních a agendových kmenových údajů, musí být implementováno lokální řešení správy kmenových dat, které po iniciálním ztotožnění udržuje přijímáním [[nap:notifikace|notifikací]] z PPDF kmenová data úřadu aktuální a nezatěžuje [[nap:propojeny_datovy_fond|propojený datový fond]] průběžnými on-line dotazy. Osobní údaje získané tímto způsobem jsou uloženy mimo jiné agendové informační systémy a jednotlivými systémy jsou využívány pouze v případě potřeby. Tím je zajištěno oddělení a zabezpečení osobních údajů s nezpochybnitelným auditem přístupu k osobním údajům.
- +
-V případě, že OVS využívá více než jeden vlastní (lokální) agendový informační systém a využívá referenčních a agendových kmenových údajů, musí být implementováno lokální řešení správy kmenových dat, které po iniciálním ztotožnění udržuje přijímáním notifikací z PPDF kmenová data úřadu aktuální a nezatěžuje PPDF (a ISZR s eGSB) průběžnými on-line dotazy. Osobní údaje získané tímto způsobem jsou uloženy mimo jednotlivé informační systémy a jednotlivými systémy jsou využívány pouze v případě potřeby. Tím je zajištěno oddělení a zabezpečení osobních údajů s nezpochybnitelným auditem přístupu k osobním údajům.+
  
  
Řádek 541: Řádek 547:
  
  
-Otevřená data musí především naplnit legislativní požadavky ve smyslu zákona 106/1999 Sb. o svobodném přístupu k informacím. Navíc musí způsob jejich zveřejnění naplnit následující podmínky, jejichž splnění musí zajistit OVS, který otevřená data zveřejňuje:+Otevřená data musí především naplnit legislativní požadavky ve smyslu zákona 106/1999 Sb. o svobodném přístupu k informacím se zohledněním zákona o ochraně osobních údajů a nařízením GDPR. Navíc musí způsob jejich zveřejnění naplnit následující podmínky, jejichž splnění musí zajistit OVS, který otevřená data zveřejňuje:
   * Otevřená data musí být katalogizována v NKOD v podobě jednotlivých datových sad.   * Otevřená data musí být katalogizována v NKOD v podobě jednotlivých datových sad.
   * Datová sada musí být tvořena logicky souvisejícími údaji, logicky organizovanými do záznamů se stejnou datovou strukturou.   * Datová sada musí být tvořena logicky souvisejícími údaji, logicky organizovanými do záznamů se stejnou datovou strukturou.
Řádek 563: Řádek 569:
   * Prvky definované logickými datovými schématy distribucí datové sady, jejichž sémantika je významná, musí být propojeny na pojmy sémantického slovníku pojmů za účelem harmonizace sémantiky datových sad dle k tomu určené OFN zveřejněné na POD.   * Prvky definované logickými datovými schématy distribucí datové sady, jejichž sémantika je významná, musí být propojeny na pojmy sémantického slovníku pojmů za účelem harmonizace sémantiky datových sad dle k tomu určené OFN zveřejněné na POD.
   * V případě duplicit u publikovaných datových sad, nebo doplňování údajů různými publikujícími ke stejné publikované entitě je nutné doplnit vazby na již publikované údaje ve VDF. Povinnost doplnění vazeb spadá na toho publikujícího, který publikuje doplňující údaje.   * V případě duplicit u publikovaných datových sad, nebo doplňování údajů různými publikujícími ke stejné publikované entitě je nutné doplnit vazby na již publikované údaje ve VDF. Povinnost doplnění vazeb spadá na toho publikujícího, který publikuje doplňující údaje.
-  * U každé datové sady publikované do VDF musí být uvedena informace o notifikačním mechanismu o změnách dle příslušné OFN uvedené na POD.+  * U každé datové sady publikované do VDF musí být uvedena informace o [[nap:notifikace|notifikačním]] mechanismu o změnách dle příslušné OFN uvedené na POD.
   * OVS, který datovou sadu zveřejňuje, musí zajistit a garantovat dostupnost distribucí datové sady v otevřeném a strojově čitelném formátu pro všechny OVS, které je využívají při výkonu svých agend.   * OVS, který datovou sadu zveřejňuje, musí zajistit a garantovat dostupnost distribucí datové sady v otevřeném a strojově čitelném formátu pro všechny OVS, které je využívají při výkonu svých agend.
   * Správce ISVS, ze kterého je datová sada získána, zodpovídá za věcnou správnost obsahu datové sady. To znamená, že zodpovídá za:   * Správce ISVS, ze kterého je datová sada získána, zodpovídá za věcnou správnost obsahu datové sady. To znamená, že zodpovídá za:
Řádek 571: Řádek 577:
     * předávání oznámení o aktualizacích notifikačnímu HUBu.     * předávání oznámení o aktualizacích notifikačnímu HUBu.
  
-==== Údaje povinně zveřejňované ve VDF ==== 
-Ve VDF jsou jako otevřená data povinně zveřejňovány následující údaje: 
  
-^Poskytovatel zveřejňující údaje ve VDF ^Zveřejňované údaje ^Způsob zveřejnění| 
-|Český statistický úřad |Číselníky zavedené sdělením ve Sbírce zákonů |Dle OFN Číselníky| 
-|Ohlašovatel agendy ve smyslu § 48 písm. f) zákona č. 111/2009 Sb. o základních registrech |Číselníky kódující údaje uvedené v registru práv a povinností dle § 51 odst. 5 písm. h) zákona č. 111/2009 Sb., o základních registrech. Ohlašovatel agendy číselník zveřejňuje ve VDF, pokud již číselník nezveřejňuje Český statistický úřad nebo jiný ohlašovatel.|Dle OFN Číselníky| 
  
  
 ==== Pravidla pro analytická data ==== ==== Pravidla pro analytická data ====
  
- +Každý úřad, který ze zákona udržuje primární individuální evidenční data o subjektech či objektech práva ve svých agendových systémech, může pro potřebu řízení agend i pro jinou veřejnou potřebu vytvářet z těchto údajů vytvářet anonymizované statistické údaje.
-Každý úřad, který ze zákona udržuje primární individuální evidenční data o subjektech či objektech práva ve svých agendových systémech, je automaticky povinen pro potřebu řízení agend i pro jinou veřejnou potřebu vytvářet z těchto údajů anonymizované statistické údaje.+
  
 Anonymizované statistické údaje jsou tříditelné podle všech parametrů (klíčů), které nejsou údaji specificky chráněnými a nezakládají možnost profilace. Anonymizované statistické údaje jsou tříditelné podle všech parametrů (klíčů), které nejsou údaji specificky chráněnými a nezakládají možnost profilace.
Řádek 596: Řádek 596:
 Statistické údaje, které mohou orgány nyní ze zákona pověřené sběrem takových statistických údajů získat z jejich primárních evidencí, nesmějí být duplicitně získávány sběrem od subjektů. Statistické údaje, které mohou orgány nyní ze zákona pověřené sběrem takových statistických údajů získat z jejich primárních evidencí, nesmějí být duplicitně získávány sběrem od subjektů.
  
 +==== Pravidla pro prostorová data ====
  
-==== Pravidla pro geo-data ====+Každý agendový informační systém spravující prostorová data, která mohou být sdílena v rámci propojeného datového fondu veřejné správy, musí: 
 +  * Být obsahově popsán do úrovně datových prvků v informačním systému o informačních systémech veřejné správy do úrovně datových prvků. Datový prvek odpovídá třídě prostorových dat v geografických informačních systémech.  
 +  * Publikovat služby sdílení prostorových dat  
 +  * Datové prvky prostorových dat, které jsou ve vztahu příbuznosti, podobnosti nebo identicity k prvkům [[nap:ruian|RÚIAN]], musí obsahovat identifikátor prvku [[nap:ruian|RUIAN]] (např. budovy digitální technické mapy, adresní místa agendou dotčených nemovitostí, aj.)
  
  
-Doplníme ve spolupráci s ČÚZK 
  
  
Řádek 608: Řádek 611:
   - Propojený datový fond   - Propojený datový fond
     - Referenční údaje ze základních registrů (využívá se [služeb ISZR)     - Referenční údaje ze základních registrů (využívá se [služeb ISZR)
-    -    Údaje publikované agendami a jejich AISy (využívá se [rozhraní eGSB])+    -    Údaje publikované agendami a jejich AISy (využívá se [[:nap:egsb|eGSB / ISSS]])
   - Veřejný datový fond   - Veřejný datový fond
     - Veřejné rejstříky a seznamy publikované způsobem umožňujícím dálkový přístup)     - Veřejné rejstříky a seznamy publikované způsobem umožňujícím dálkový přístup)
Řádek 614: Řádek 617:
  
  
-===== Pravidla technologické architektury IS VS =====+===== Pravidla technologické / platformové architektury IS VS ===== 
 + 
 +<WRAP center round tip 60%> 
 +Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí je popsán v části [[nap_dokument:architektura_a_sdilene_sluzby_verejne_spravy_cr|Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR]]. 
 + 
 +Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části [[nap_dokument:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady]]. 
 + 
 +Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce. 
 +</WRAP>
  
  
Řádek 621: Řádek 632:
  
  
-Klasifikaci prvků IT technologické architektury, tjvýpočetního výkonu, úložného prostorukoncových zařízení a dalších platformových HW a SW služebvydá jako další akcelelrátorů OHA potéco bude možnost zobecnit a sdílet zkušenost z dostatečného množství individuálních architektur úřadů v této oblasti.+IT technologická architektury (také jako "platformová architektura") je vrstva zabývající se technologiemikteré svými funkcionalitami a službami podporují aplikace, systémy a obecně prvky z aplikační architekturyOblasti platformové architektury se dají rozdělit na: 
 +  - Výpočetní výkon 
 +  - datová úložiště 
 +  - koncová zařízení (FirewallSwitchobecně aktivní prvky).
  
  
Řádek 639: Řádek 653:
  
  
-PaaS a IaaS služby eGC mohou být využity pro nahrazení kterékoliv služby na technologické vrstvě architektury úřadu, resp. interní implementace dané služby („funkce“ z pohledu architektonického modelu) může být nahrazena služnou PaaS nebo IaaS. Na PaaS a IaaS služby eGC budou kladeny stejné architektonické požadavky jako na platformy provozované on-premise. Pro služby eGC a on-premise budou stejné i bezpečnostní požadavky odpovídající úrovni hodnocení bezpečnostních dopadů ISVS tyto platformy využívající.+PaaS a IaaS [[nap:egovernment_cloud|služby eGC]] mohou být využity pro nahrazení kterékoliv služby na technologické vrstvě architektury úřadu, resp. interní implementace dané služby („funkce“ z pohledu architektonického modelu) může být nahrazena služnou PaaS nebo IaaS. Na PaaS a IaaS [[nap:egovernment_cloud|služby eGC]] budou kladeny minimálně stejné architektonické požadavky jako na platformy provozované on-premise. Pro [[nap:egovernment_cloud|služby eGC]] a on-premise budou stejné i bezpečnostní požadavky odpovídající úrovni hodnocení bezpečnostních dopadů ISVS tyto platformy využívající.
  
 Praktické využití PaaS a IaaS služeb je očekáváno zejména ve formě skupin služeb odpovídajících provozní platformě určitého ISVS nebo provozního informačního systému, případně jeho jasně definované části (např. web front-end), a to buď na úrovni plně spravované technologické platformy včetně správy OS (PaaS), nebo na úrovni virtualizovaných výpočetních a diskových zdrojů (IaaS), jejichž správu bude úřad provádět vlastními silami nebo s využitím služeb třetí strany. Z pohledu eGC je pro dosažení vyšší úrovně efektivity preferováno použití služeb PaaS. Praktické využití PaaS a IaaS služeb je očekáváno zejména ve formě skupin služeb odpovídajících provozní platformě určitého ISVS nebo provozního informačního systému, případně jeho jasně definované části (např. web front-end), a to buď na úrovni plně spravované technologické platformy včetně správy OS (PaaS), nebo na úrovni virtualizovaných výpočetních a diskových zdrojů (IaaS), jejichž správu bude úřad provádět vlastními silami nebo s využitím služeb třetí strany. Z pohledu eGC je pro dosažení vyšší úrovně efektivity preferováno použití služeb PaaS.
  
 Dalším příkladem využití PaaS služeb je využití plně spravovaných platforem databázových nebo aplikačních serverů včetně zajištění SW licencí. Dalším příkladem využití PaaS služeb je využití plně spravovaných platforem databázových nebo aplikačních serverů včetně zajištění SW licencí.
 +
 +==== Pravidla pro režim Active - Active jednotlivých výpočetních uzlů ====
 +
 +Staví-li se výpočetní platformy v režimu Active - Active je nezbytné mít zajištěny minimálně 3 lokality, kdy 2 lokality slouží pro samotné výpočetní platformy a třetí lokalita pro umístění technologií dohledující zbylé lokality a rozhodující o jejich chování.  
  
  
  
 ===== Pravidla fyzické a komunikační infrastruktury IS VS ===== ===== Pravidla fyzické a komunikační infrastruktury IS VS =====
 +
 +<WRAP center round tip 60%>
 +Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí je popsán v části [[nap_dokument:architektura_a_sdilene_sluzby_verejne_spravy_cr|Popis sdílených služeb, funkčních celků a tematických oblastí veřejné správy ČR]].
 +
 +Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části [[nap_dokument:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí jednotlivými úřady]].
 +
 +Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce.
 +</WRAP>
 +
 +
 +KIVS/CMS je systém, jehož primárním účelem je zprostředkovávat řízené a evidované propojení informačních systémů subjektů státní správy a samosprávy ke službám (aplikacím), které poskytují informační systémy jiných subjektů státní správy a samosprávy s definovanou bezpečností a SLA parametry, tj. přístup ke službám eGovernmentu. KIVS/CMS tak můžeme nazvat privátní sítí pro výkon veřejné správy na území státu. KIVS/CMS jako privátní síť veřejné správy využívá dedikovaných resp. pronajatých síťových prostředků pro bezpečné propojení úředníků orgánů veřejné správy (OVS) pracujících v agendách veřejné správy s jejich vzdálenými agendovými informačními systémy, pro bezpečné síťové propojení agendových systémů navzájem a pro bezpečný přístup jednotlivých OVS do Internetu.
 +
 +OVS a SPUÚ přistupují ke službám eGovernmentu, jako např. [[https://archi.gov.cz/nap:propojeny_datovy_fond|propojenému datovému fondu,]] výhradně přes CMS jedním ze čtyř možných způsobů:
 +
 +  - Prostřednictvím Krajských sítí (aktuálně v krajích Vysočina, Plzeňském, Karlovarském, Zlínském a částečně Pardubickém + další budou-li vybudovány). 
 +  - Prostřednictvím [[nap:metropolitni_site|metropolitních sítí]] připojených např. na [[nap:its|Integrovanou telekomunikační sít (ITS) MVČR]]. 
 +  - Prostřednictvím Komunikační infrastruktury veřejné správy (KIVS) s využitím komerčních nabídek soutěžených prostřednictvím Ministerstva vnitra. 
 +  - Prostřednictvím veřejného internetu, a to přes zabezpečený tunel VPN SSL nebo VPN IPSec.
 +
 +Pokud chce úřad využít KIVS, tj. soutěž přes centrálního zadavatele Ministerstvo vnitra, je nutné definovat požadavky dle [[https://www.mvcr.cz/clanek/komunikacni-infrastruktura-verejne-spravy-278660.aspx|katalogových listů]] a následně zrealizovat nákup v dynamickém nákupním systému. Služby CMS lze čerpat také prostřednictvím [[https://archi.gov.cz/nap:narodni_datova_centra|Národních datových center]].
 +
 +Pro OVS jsou přípustné pouze varianty 1 až 3, komunikace mezi jednotlivými OVS je tak vedena výhradně prostřednictvím KIVS/CMS, tzn. jednotlivé OVS mají povinnost přistupovat k informačním systémům veřejné správy (ISVS) pouze prostřednictvím KIVS/CMS.
 +
 +
 +S výjimkou tzv. provozních informačních systémů, které jsou uvedeny v § 1 odst. 4 písm. a) až d) zákona č. 365/2000 Sb., o informačních systémech veřejné správy (ZoISVS), je § 6g odst. 3 tohoto zákona správcům ISVS uložena povinnost poskytovat služby informačních systémů veřejné správy prostřednictvím CMS. Organům veřejné správy je prostřednictvím § 6g odst. 4 ZoISVS uložena povinnost využívat sítě elektronických komunikací CMS.¨
 +
 +Protože skrze CMS se publikují služby tzv. [[nap:referencni_rozhrani|referenčního rozhraní]], definovaného v § 2 písm. j) ZoISVS, má vztah k CMS i povinnost uložená v § 5 odst. písm. d) ZoISVS, tj. povinnost správců ISVS zajistit, aby vazby jimi spravovaného ISVS na ISVS jiného správce byly uskutečňovány prostřednictvím CMS.
 +
 +S ohledem na výše popsané vlastnosti CMS, jakož i s ohledem na výše popsané právní aspekty, lze také dodat, že využívání, popř. nevyužívání CMS je relevantním faktorem pro posuzování plnění souvisejících právních povinností, a to zejména povinností v oblasti kybernetické bezpečnosti nebo ochrany osobních údajů, jakož i povinnosti řádného a hospodárného nakládání s veřejnými finančními prostředky a povinnosti k předcházení vzniku škod.
 +
 +
 +===== Specifická pravidla pro architekturu úřadů =====
 +
 +
 +==== Pravidla pro architekturu dle velikosti a možností úřadů ====
 +
 +
 +Pro obce 1. a 2. typu má vize architektury veřejné správy následující podobu:
 +
 +Architekturu IT úřadu obce 1. a 2. typu (do určité velikosti, viz níže) tvoří pouze koncová zařízení pro uživatele, síťovou infrastrukturu jim jako sdílenou poskytuje kraj, aplikační služby pro státní správu v přenesené působnosti poskytnou ohlašovatelé agend a aplikační služby pro samosprávní působnost poskytne vyšší stupeň územní samosprávy (ORP, kraj) jako sdílenou službu.
 +
 +Pro oblast samosprávy tak vychází koncepce z následujících principů:
 +
 +
 +  - NAP je závazný pro všechny subjekty samosprávy, které mají více než 10 zařízení.
 +  - Informační systémy pro činnosti a agendy v přenesené působnosti přebírají v plném rozsahu od centrálních úřadů. Samosprávné činnosti si každý územněsprávní celek zajišťuje sám.
 +  - Subjekty s méně než 10 zařízeními si pořizují pouze uživatelský HW a SW, tj. tato koncová zařízení, SW produkty pro výkon veřejné správy jim jako službu zajišťují subjekty, v jejichž správním obvodě leží.
  
  
 +==== Pravidla pro architekturu dle pozice úřadu ve struktuře VS ČR a vztahu ke sdíleným službám ====
  
-<note important>Popis všech centrálně poskytovaných systémů a jejich služeb je popsán v části [[:nap:architektura_a_sdilene_sluzby_verejne_spravy_cr|Architektura sdílených služeb, funkčních celků a tématických oblastí veřejné správy ČR]]. 
  
-Konkrétní implementační kroky a způsoby zapracování do informační koncepce OVS pro jednotlivé sdílené službyfunkční celky a tématické oblasti jsou popsány kapitole [[:nap:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu|Pravidla pro architekturu sdílených služeb, funkčních celků a tématických oblastí jednotlivých úřadů]].+Úřadyzodpovědné ze zákona jako věcní správci sdílených prvků služeb eGovernmentupovažují tyto jim svěřené prvky za nedílnou součást architektury svého úřadu. Vedle celkové architektury svých úřadů ještě samostatně modelují modely architektury těchto svěřených sdílených prvků, to i na úrovni podrobnosti tzv. architektury řešení. Tyto úřady pro tyto prvky modelují také tzv. rozšířené modely, tj. modely zahrnující také prvky typové (logické) prvky architektury na straně typových (typických) odběratelů jejich sdílených služeb.
  
-Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce v části XXX.</note>+Úřady, užívající služeb sdílených prvků eGovernmentu, nemodelují tyto informační systémy žádném případě jako aktivní prvky (aplikační a technologické komponenty a rozhraní) - nemají je v rozsahu své zodpovědnosti, nýbrž výhradně jako služby (byznys, aplikační nebo technologické a infrastrukturní - podle potřeby vyjádření) a rozhraní vlastních komponent na tyto systémy.
  
-==== Klasifikace fyzické komunikační infrastruktury ====+Úřady zodpovědné za implementaci provoz centrální registrů a AIS pro služby v přenesené působnosti, modelují architekturu svých úřadů přirozeně i včetně těchto systémů. Současně jsou povinny vytvářet a udržovat také tzv. rozšířené modely, tj. modely zahrnující také prvky typové (logické) prvky architektury na straně typových (typických) odběratelů jejich sdílených služeb, ukazující veškerý potřebný kontext (například integraci centrálního AIS na lokální eSSL a EkIS).
  
 +Úřady užívající tyto centrální AIS pro služby v přenesené působnosti, nemodelují ve svých architekturách úřadu tyto jako aktivní prvky (nemají je ve své zodpovědnosti), nýbrž jako služby těchto systémů a rozhraní vlastních komponent na tyto systémy.
  
-Klasifikaci prvků fyzické (stavební, technologické) a komunikační infrastruktury vydá jako další akcelelrátorů OHA poté, co bude možnost zobecnit a sdílet zkušenost z dostatečného množství individuálních architektur úřadů v této oblasti.+===== Pohledy celkové skladby architektury veřejné správy =====
  
 +==== Pohled úředníka ====
  
-==== Pravidla využití sdílených prvků infrastruktury ====+{{ :nap-dokument:egov_4_prehled_klient_ur.png |}}
  
 +==== Pohled klienta - právnické osoby ====
  
-KIVS, CMS, krajské konektory+{{ :nap-dokument:egov_4_prehled_klient_po.png |}}
  
-Jste-li obcí, pak se připojujte se na CMS přes krajský konektor.+==== Pohled klienta fyzické osoby ====
  
-Jste-li krajem, poskytněte obcím krajskou síť, protože je to bezpečné, spolehlivé a cenově efektivní.+{{ :nap-dokument:egov_4_prehled_klient_fo.png |}}
  
-Využitím služeb eGC zároveň dochází k fyzickému přemístění provozovaných služeb do datových center poskytovatele eGC a je třeba řešit související otázky připojení úřadu k poskytovateli eGC … bude doplněno