- Česky (cs)
- English (en)
Toto je starší verze dokumentu!
<title>Rozšiřující znalostní báze Architektury eGovernmentu ČR</title>
Rozšiřující znalostní báze obsahuje postupy, rady, návody a další informace, které nejsou obsahem hlavních navazujících dokumentů, ale dále rozvíjejí jejich myšlenky a povinnosti. V tabulce níže jsou jednotlivé oblasti s odkazy na samostatné stránky, případně je obsah celé rozšiřující znalostní báze uveden pod tabulkou.
Vzorová informační koncepce OVS
Struktura a náležitosti Informační koncepce stanovuje vyhláška č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy.
Bližší představu o obsahu informační koncepce ústředního OVS s novou strukturou lze získat např. prostudováním informačních koncepcí ústředních OVS, které již při aktualizacích svých informačních koncepcí postupují v souladu s dokumentem Metody řízení ICT VS ČR, jako je např. mj. i v přímé návaznosti na celostátní strategii Digitální Česko aktualizovaná Informační koncepce Ministerstva průmyslu a obchodu ČR
Úvod
Identifikace Informační koncepce
Doplňte v případě potřeby obecný úvod o informace týkající se vašeho úřadu.
Aktuálním smyslem Informační koncepce (IK) úřadu je především stanovit jeho cíle v oblasti digitalizace a popsat, jak budou pro naplnění těchto cílů rozvíjeny informační systémy a IT služby úřadu. Stručně to shrnuje Zásada řízení ICT Z3: Strategické řízení pomocí IK OVS, která je součástí Informační koncepce ČR.
Orgán veřejné správy (OVS) vydává tuto Informační koncepci v souladu se zákonem č. 365/2000 Sb., o informačních systémech veřejné správy (§ 5a). V Informační koncepci OVS stanovuje své dlouhodobé cíle v oblasti řízení architektury úřadu, řízení ICT služeb.
Popište vztah IK ke klíčovým strategickým dokumentům úřadu a eGovernmentu
Základní údaje Informační koncepce
Název orgánu veřejné správy | XY |
---|---|
IČO | XXXXXXX |
Typ organizace | Orgán státní správy |
Adresa sídla | XYZ |
Verze IK | XX.XX |
Datum vzniku | mm/rrrr |
Datum schválení | dd.mm. rrrr |
Počátek platnosti | dd.mm. rrrr |
Autor verze | |
Organizační útvar / organizace | Útvar XY |
Verzi schválil | |
Organizační útvar / organizace | Útvar XY |
Název souboru | IK_ XY.docx |
Počet stran | 100+ |
Manažerské shrnutí
Shrnutí IK pro klíčové zainteresované:
- pro vedení úřadu
- pro externí orgány (např. OHA)
- pro správce ISVS (věcné i technické)
- pro členy IT útvarů a dodavatele ICT služeb
V kapitole manažerské shrnutí jsou uvedeny: Základní odpovědnosti a kompetence OVS (povinnosti, zákony, agendy). Klíčové transformační cíle a úkoly OVS Shrnutí toho nejdůležitějšího, co stojí před OVS a jeho představiteli (GDPR, spisovka, eIDAS, …). Klíčové vnitřní potřeby informatiky a eGovernmentu OVS Shrnutí nejdůležitějších ostatních vlivů, provozních potřeb a optimalizačních podnětů Shrnutí vize cílového stavu architektury úřadu Přehled klíčových rysů vize cílového stavu úřadu (plně digitalizován, plně centralizován, plně outsourcován atp.). Výběr klíčových změnových záměrů / projektů z Roadmapy Výběr klíčových změn ve způsobu řízení informatiky a eGovernmentu OVS. Popište Vztah IK a souvisejících strategických dokumentů OVS a eGovernmentu https:%%//%%archi.gov.cz/uvod_dokumenty
Nejstručnější rekapitulace závěrů IK
Uveďte zásadní závěry popsané níže v kapitolách této IK.
Základní zodpovědnosti a kompetence úřadu
Shrňte základní kompetence úřadu popsané níže v kapitolách této IK.
Shrnutí stávajícího stavu úřadu a jeho architektury
Popište hlavní zjištění vyplývající z poznání současného stavu struktury a fungování (tedy architektury) úřadu a její podpory informačními technologiemi (míra digitalizace agend jak jsou využívány sdílené služby eGovernmentu apod.)..
Klíčové transformační cíle
Shrňte klíčové cíle digitální transformace úřadu a jeho způsobu řízení ICT, které vycházejí z motivací úřadu popsaných níže v kapitole 2, části A i B.
Klíčové vnitřní potřeby ICT
Uveďte, jaké jsou potřeby identifikované interně v ICT pro poskytování kvalitních ICT služeb.
Shrnutí vize cílového stavu úřadu a jeho architektury
Slovně nebo graficky vyjádřete cílovou představu (vizi) úřadu, zejména jeho byznys a aplikační architektury, popsané níže v kapitolách této IK.
Výběr klíčových změnových záměrů / projektů
Shrňte základní přehled změn, jejich rozpočtů, harmonogramů apod., které jsou popsané níže v kapitolách této IK.
Výběr klíčových změn v řízení ICT
Slovně nebo graficky vyjádřete představu (vizi) cílové podoby procesů, organizace, lidských zdrojů a dalších součástí řízení ICT úřadu, popsané níže v kapitolách této IK.
Základní podmínky realizovatelnosti změn
Vypište manažerské požadavky na finanční zdroje, služební místa, lidské zdroje apod., popsané níže v kapitolách této IK.
Jak číst informační koncepci
Vysvětlete strukturu obsahu IK, pokud jste strukturu významně rozšířili oproti standardní šabloně. Strukturu šablony nezužujte, povinné kapitoly neodstraňujte.
Dokument IK úřadu postupně popisuje ve svých jednotlivých částech:
Část A: Koncepce architektury úřadu je o fungování úřadu jako celku. Měla by popsat činnosti úřadu v rámci jeho agend („co dělám a proč“) a jejich podporu informačními systémy a technologiemi („s čím to dělám“).
Část B: Koncepce řízení služeb ICT se zaměřuje na fungování ICT útvaru úřadu. Měla by popsat služby, které ICT poskytuje ostatním složkám úřadu a způsob jejich řízení.
Obě části (A i B) jsou členěny do čtyř kapitol, z nichž první dává přehled stávajícího stavu, druhá popisuje motivace ke změnám (co je potřeba změnit a proč), třetí obsahuje high-level návrh cílového stavu (jak to bude vypadat po změnách) a čtvrtá definuje plán realizace popsaných změn (jakými projekty a kdy budou dodány).
Další část (C) dokumentu je o tom, jak bude tento dokument řízen a jak bude naplňován – postupy realizace změn, kontroly a vyhodnocování změn a odpovědnosti za plnění.
Poslední část dokumentu (D) obsahuje různé dodatky, přílohy apod., ve kterých může čtenář najít vysvětlení, upřesnění nebo rozšíření informací z předchozích částí dokumentu.
Část A: Koncepce architektury úřadu
Představuje celkovou inventuru současného stavu úřadu z hlediska výkonu funkcí veřejné správy (byznys architektura), jejich podpory informačními systémy (aplikační a datová architektura) a technologiemi (architektura IT a komunikační infrastruktury). Následně odpovídá na otázky CO? a PROČ? je třeba stavět či měnit, resp. do jakého stavu se chce úřad dostat a jakými změnami/projekty toho dosáhne.
Význam byznys architektury pro návrh cílového stavu a potřebných změn v ICT podpoře funkcí úřadu popisuje Národní architektonický plán (NAP) v kapitole Pravidla byznys architektury výkonu veřejných služeb úřadu.
Úvod do architektury úřadu
Tato kapitola je čistě edukativní, slouží jako úvod a návod. Do této kapitoly není potřeba dělat změny, nemáte-li zásadní potřebu zdůraznit nějakou zvláštnost vašeho úřadu. Doporučujeme ji v IK zachovat jako základní informaci pro budoucího čtenáře.
popis stávajícího stavu architektury
Zodpovědnosti a kompetence úřadu
Shrňte základní kompetence úřadu, co je posláním úřadu, za jakým účelem úřad věcně existuje. Obsah můžete následně ve stručnější formě použít v kap. 2.2 manažerského shrnutí.
Přehled byznys architektury
Graficky znázorněte všechny činnosti (schopnosti, procesy, funkce nebo služby), které úřad vykonává. V následujícím obrázku uvedené procesy a jejich dělení představují příklad, rozdělení v rámci hypotetického úřadu. Jednotlivé kategorie (1. až 5.) doplňte o specifické procesy vašeho úřadu.
Hlavní a podpůrné procesy
V rámci zamyšlení se nad jednotlivými částmi této kapitoly doporučujeme udělat důkladnou kontrolu zápisů v RPP, týkající se především – ohlášení agend, ISVS, zákonných zmocnění, definice údajů, katalogu služeb VS.
Nedílnou součástí popisu stávajícího stavu úřadu a jeho agend je, zda jsou agendy uspokojivě podpořeny službami informačních systémů, tudíž není očekáváno žádné další zlepšení, nebo naopak, zda u předmětných agend je možné očekávat a je třeba plánovat jejich digitální transformaci.
Stav řídících, provozních a korporátních činností a jejich IT podpory
Uveďte přehled ostatních činností vykonávaných úřadem a stav jejich digitalizace.
Přehled klíčových rolí
Zde uveďte seznam klíčových rolí, nezbytných pro digitální transformaci vašeho úřadu.
Přehled digitalizace z pohledu organizační struktury
Vložte model organizační struktury úřadu.
Přehled dat ve správě úřadu
Jedním z klíčových předpokladů digitalizace je kvalitní správa dat, díky které úřad zajistí dobrou znalost, důvěryhodnost a využitelnost svých dat. Téma dat prochází napříč všemi základními vrstvami architektury úřadu (byznys, aplikační a technologickou).
Shrnutí potřeb ze stávajícího stavu byznys architektury
Stručně shrňte, co vyplývá z této kapitoly nejdůležitějšího pro další navazující části a závěry IK (co jsme zjistili). Tuto dílčí rekapitulaci můžete následně použít jako vstup pro celkové manažerské shrnutí v kapitole 2.
Aplikační architektura informačních systémů úřadu
Přehled a klasifikace všech informačních systémů úřadu
Informační systémy (IS), se skládají z jedné nebo více aplikačních komponent. Aplikační komponenty 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 jejich vzájemné integrace. Součástí zpracování IK je i úloha pro technické správce ISVS 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 diagram této dekompozice, tzv. Mapu aplikačního portfolia/architektury úřadu.
Přehled ISVS a provozních ISVS ve správě úřadu
Zaevidujte ve stanovené struktuře všechny ISVS úřadu včetně uvedení informace, zda ISVS zároveň podléhají zákonu č. 181/2014 Sb., o kybernetické bezpečnosti ve znění pozdějších předpisů, které byly určené jako kritická informační infrastruktura (dále jen „KII“) nebo jako významný informační systém (dále jen „VIS“).
Provozní informační systémy úřadu
Popište provozní informační systémy stanovené v § 1 odst. 4 zákona č. 365/2000 Sb., ve znění pozdějších předpisů a všechny provozní informační systémy s vazbou na ISVS. U provozních informačních systémů nespecifikovaných v zákoně č. 365/2000 Sb., ve znění pozdějších předpisů se popisuje pouze vazba / vazby na ISVS.
Nástroje podporující spolupráci
Popište, jaké kolaborativní nástroje používáte, případně umožňujete použít, jak zajišťujete bezpečnost jich samotných a dále dat, která při jejich použití vznikají.
Využití klíčových sdílených služeb eGovernmentu a externích IS
Popište, které ze sdílených služeb jsou úřadem a konkrétním IS využívány.
Publikace služeb a IS eGovernmentu
Popište, zda jsou úřadem vytvářeny a publikovány sdílené služby, které mohou být dostupné pro využití jinými úřady nebo koncovými uživateli. Popis z tohoto odstavce bude zveřejněn v NAP v sekci sdílených služeb.
Využití cloud řešení
Popište, které cloudové služby jsou úřadem využívány, jaký je stav systémů úřadu z pohledu jejich možné migrace do cloud technologií, jaké jsou omezení a předpoklady.
Zaměřte se na využití eGovernment cloudu z pohledu zvýšení efektivity, rozsahu poskytovaných služeb, kvality a bezpečnosti a zároveň snížení nákladů provozu informačních systémů a aplikací veřejné správy
Integrační model aplikační architektury
Popište, vzájemnou integraci jednotlivých IS uvnitř úřadu, jejich napojení na sdílené služby eGovernmentu, a propojení na PPDF. Popište, aplikační služby, které na druhé straně poskytuje váš úřad jiným.
Shrnutí potřeb ze stávajícího stavu aplikační architektury
Stručně shrňte, co vyplývá z této kapitoly nejdůležitějšího pro další navazující části a závěry IK (co jsme zjistili). Tuto dílčí rekapitulaci můžete následně použít jako vstup pro celkové manažerské shrnutí v kapitole 2.
Datová architektura informačních systémů úřadu
Základní charakteristiky datové architektury
Popište, jak pracujete s datovou architekturou v rámci celkové (enterprise) architektury úřadu a v rámci architektury jednotlivých řešení (informačních systémů resp. jejich změn), zda máte a udržuje popis současného a cílového stavu datové architektury apod.
Přehled datových rozhraní
Východiskem pro přehled datových integrací a způsobů zpřístupnění dat úřadu v následujících podkapitolách by měla být inventarizace datových rozhraní, jejichž prostřednictvím jsou zpřístupňovány vlastní údaje.
Datová integrace
Vložte model a popište současný stav datové integrace vnější (s jinými úřady) i vnitřní (mezi informačními systémy úřadu). Model se primárně zaměřuje na integrační vazby systémů prostřednictvím datových rozhraní typu „aplikační rozhraní pro přístup k datům AIS/IS“ a „kontext údajů o subjektu práva poskytovaných přes PPDF“.
Zpřístupnění dat
Znázorněte pomocí modelu a popište, jak je realizována tvorba a publikace otevřených datových sad a analytických či datových produktů (reportů, datovch souborů, statistik apod.).
Shrnutí potřeb ze stávajícího stavu datové architektury
Stručně shrňte, co vyplývá z této kapitoly nejdůležitějšího pro další navazující části a závěry IK (co jsme zjistili). Tuto dílčí rekapitulaci můžete následně použít jako vstup pro celkové manažerské shrnutí v kapitole 2.
Architektura IT infrastruktury úřadu
Architektura serverové infrastruktury
Doplňte popis a model architektury IT (výpočetního výkonu a úložného prostoru).
Infrastrukturní architektura koncových zařízení
Doplňte popis a model architektury koncových zařízení, jejich správy a monitoringu, včetně BYOD zařízení a zařízení externích pracovníků.
Shrnutí potřeb ze stávajícího stavu Infrastrukturní architektury
Stručně shrňte, co vyplývá z této kapitoly nejdůležitějšího pro další navazující části a závěry IK (co jsme zjistili). Tuto dílčí rekapitulaci můžete následně použít jako vstup pro celkové manažerské shrnutí v kapitole 2.
Architektura komunikační infrastruktury úřadu
Doplňte popis toho, jakými prostředky je IT infrastruktura propojena na zbytek sdílených služeb eGovernmentu, na klienty, do zahraničí, s důrazem na využití CMS a KIVS a na eliminaci použití obecného internetu.
Shrnutí potřeb ze stávajícího stavu Infrastrukturní architektury
Stručně shrňte, co vyplývá z této kapitoly nejdůležitějšího pro další navazující části a závěry IK (co jsme zjistili). Tuto dílčí rekapitulaci můžete následně použít jako vstup pro celkové manažerské shrnutí v kapitole 2.
Přehled projektů
Přehled již schválených či běžících projektů.
Přehled motivací úřadu ke změnám architektury
Identifikujte a popište v této kapitole motivace úřadu ke změnám architektury, tj. co je potřeba na současném fungování úřadu změnit a proč. Využijte nabídnutou strukturu, v případě potřeby ji rozšiřte o chybějící oblasti vašeho zájmu.
Poslání úřadu, strategické cíle a byznys požadavky
Vysvětlete potřebu změny architektury úřadu v kontextu dopadů poslání úřadu, strategických a externích byznys požadavků
Poslání a kompetence úřadu
Popište, jaké změny v architektuře úřadu jsou potřebné z důvodu změn v poslání, základních odpovědnostech a kompetencích úřadu (nové a rozšiřující agendy a činnosti, nové povinnosti), pokud nastaly nebo se připravují.
Strategické cíle úřadu
Popište, jak by mohly změny v architektuře podpořit splnění strategických cílů úřadu.
Externí byznys požadavky
Popište potřebné změny v architektuře úřadu vyvolané byznys požadavky přicházejícími z vnějšího prostředí (např. od centrálních orgánů veřejné správy, z nové legislativy, nařízení vlády apod.).
Interní byznys požadavky
Popište, jaké změny v architektuře úřadu jsou potřebné z pohledu zlepšování procesů, optimalizace výkonnosti, vnitřní digitalizace fungování úřadu apod.
Dopady a požadavky na ICT
Vliv moderních trendů na změny
Popište identifikované high-level požadavky na funkční změny v existujících ICT řešeních a službách v kontextu moderních trendů
Dopady byznys požadavků a strategických cílů úřadu na ICT
Popište dopady byznys požadavků a strategických cílů na ICT, např. potřeba zavedení nových technologií podporující potřeby byznysu, upgrade morálně zastaralých verzí nepodporujících potřeby byznysu, potřeba extra provozních finančních zdrojů, potřeba extra lidských zdrojů
Cíle ICT strategie
Popište požadavky identifikované v rámci ICT, např. na nové technologie, upgrade verzí, cloud computing, finanční zdroje, lidské zdroje
Hodnocení ekonomické výhodnosti provozu, způsobu provozu a přínosů IS
Popište:
a) výsledky pravidelných hodnocení za použití metody celkových nákladů na vlastnictví informačního systému; popis metody celkových nákladů na vlastnictví informačního systému je uveden v příloze k této vyhlášce a
b) hodnocení ukazatelů hospodárnosti, efektivnosti a účelnosti provozu a způsobu provozu informačního systému za minulá účetní období a jejich cílové hodnoty pro příští účetní období s uvedením nezbytných předpokladů pro jejich dosažení.
Výjimky OHA
Popište schválené či požadované výjimky OHA, pokud takové existují. Popište, jaké systémové změny realizujete, aby IS úřadu byly v souladu s architektonickými principy.
Shoda s cíli Informační koncepce ČR
Vyhodnoťte, do jaké míry a jakým způsobem aktuálně vyhovuje stav architektury úřadu každému jednotlivému cíli IK ČR a jakými plánovanými změnami (opatřeními, záměry a projekty) přispěje úřad k naplnění těchto cílů.
Dopady cílů Informační koncepce ČR v prostředí úřadu
Vyhodnoťte dopady hlavních i dílčích cílů IK ČR v prostředí úřadu.
S jistou mírou nepřesnosti lze říci, že postojem úřadu k jednotlivým cílům, bude jedna z následujících pozic:
- Cíl se úřadu netýká, úřad nemůže žádným způsobem přispět k jeho naplnění ani těžit z jeho výsledků.
- Úřad využívá, případně bude využívat, výsledků dosažení tohoto cíle, není však za cíl přímo zodpovědný / nemůže nijak přispět k jeho naplnění.
- Cíl se týká úřadu a úřad má proto povinnost přispět k jeho naplnění, s přihlédnutím k principu 3E (hospodárnost, efektivnost, účelnost).
Jde ovšem pouze o vodítko, nad každým z cílů a jeho plnění je třeba se upřímně zamyslet.
Dopady principů Informační koncepce ČR do digitalizace úřadu
Principy IKČR představují sadu zásad, funkčních a technologických pravidel, které je třeba pro úspěšnou digitální transformaci dodržovat a aplikovat v jednotlivých úřadech. Způsob a míra jejich aplikace závisí na konkrétním projektu či aktivitě.
Vyhodnoťte dopady a způsob uplatnění principů pro naplňování cílů Informační koncepce ČR v rámci úřadu.
Model motivační architektury úřadu
Doplňte model motivační architektury úřadu. Tento bod je volitelný, pokud model máte nebo ho chcete vytvořit například jako vizualizační pomůcku pro komunikaci cílů. Jde o vizualizaci cílů, jejich vzájemných vazeb a vazeb na cíle definované v IK ČR.
Shrnutí a interpretace potřebných změn architektury
Shrňte a interpretujte ve formě záměrů všechny potřebné změny architektury úřadu, které vyplývají z motivací popsaných v této kapitole. Jednotlivým záměrům stanovte prioritu a vysvětlete, jakou úvahou jste k prioritizaci dospěli. Tuto dílčí rekapitulaci můžete následně použít jako vstup pro celkové manažerské shrnutí.
Návrh cílového stavu architektury
Cílem kapitoly je popsat změny oproti stávajícímu stavu v jednotlivých oblastech architektury. Pro každou z nich by měl existovat projekt v plánu realizace změn (v další kapitole). V rámci jednotlivých podkapitol vložte modely stávajícího stavu doplněné o změny, které chcete realizovat. Změny graficky znázorněte, například použitím výraznějších barev.
Architektonická vize úřadu
Popište, jak úřad přistupuje k tématu své digitální transformace (jak ji úřad uchopí, co to pro něj znamená).
Návrh cílové byznys architektury
Popište nebo graficky znázorněte, jak se změní byznys architektura úřadu, tzn.:
- Služby klientům, externím i interním
- Portály, obslužné kanály
- Katalog služeb
Návrh cílové aplikační a datové architektury
Popište nebo graficky znázorněte změny na úrovni aplikací v kontextu celkové architektury úřadu (EA) a jeho okolí (eGovernmentu jako celku). Dále popište změny v datové architektuře úřadu jako celku (konceptuální model).
Využití klíčových sdílených služeb eGovernmentu a externích IS
Popište, které ze sdílených služeb jsou úřadem a konkrétním IS využívány.
Publikace služeb a IS eGovernmentu
Popište, zda budou úřadem vytvářeny a publikovány sdílené služby, které mohou být dostupné pro využití jinými úřady nebo koncovými uživateli. Popis z tohoto odstavce bude zveřejněn v NAP v sekci sdílených služeb.
Návrh cílové IT technologické architektury
Popište nebo graficky znázorněte změny v IT technologické architektuře, např. otázky typu: Cloud - ano/ne, Vlastní infrastruktura - ano/ne, Nákup služeb - ano/ne, infrastruktura státního podniku, …ve struktuře popisu stávajícího stavu.
Návrh cílové komunikační technologické architektury
Popište nebo graficky znázorněte, jak se změní komunikační architektura úřadu ve struktuře popisu stávajícího stavu.
Plán realizace změn v architektuře úřadu
V této kapitole popište, jakými změnovými aktivitami (projekty či programy) budou realizovány změny popsané v předchozí kapitole. Z jejího přečtení by měla být jasná velmi konkrétní představa o tom, kdy budou jednotlivé změny dodány a jakou aktivitou.
Návrh strategie implementace
Popište, kdy a jak převedete záměry identifikované v kapitole 2 do formy konkrétních aktivit (projektů/programů), které nastartujete pro úspěšnou realizaci potřebných změn a dosažení cílového stavu popsaného v kapitole 3.
Přehled všech běžících i plánovaných projektů/programů
Vložte přehled nebo roadmapu všech běžících i plánovaných projektů/programů s dopadem do architektury úřadu, včetně jejich předpokládaného časování a vzájemných závislostí. Ze stručného popisu jednotlivých projektů/programů by mělo být rozpoznatelné, jakou konkrétní změnu daný projekt/program dodává.
Předpoklady úspěšné realizace plánovaných projektů/programů
Doplňte předpoklady a požadavky pro úspěšné zavedení změn, zejména lidské a finanční zdroje, legislativní úpravy a další. Inspiraci je možné najít v MŘICT, kapitole Předpoklady úspěšné digitální transformace veřejné správy.
Způsob financování projektů/programů a provozu ICT
Doplňte do tabulek plánované celkové roční investiční náklady na realizaci projektů a náklady na provozování IS. Uveďte zdroje financování (státní rozpočet, ESIF, apod.) Součástí této fáze je rovněž vyhodnocení pětiletého TCO (Total Cost of Ownership) jako podklad pro rozhodnutí o implementaci záměru v Cloudu nebo OnPremise
Plán financování projektů
Všechny stávající i plánované projekty, zahrnuté do této informační koncepce, musí mít zajištěno financování. Závazná alokace finančních nákladů nezbytných pro přípravu záměru, jeho projektovou realizaci včetně nezbytných výběrových řízení a čtyřleté provozní náklady v členění podle jednotlivých zdrojů (státní rozpočet, strukturální fondy apod.). Finanční alokace musí být zavedena v evidenci investičních záměrů a provozní náklady ve střednědobém rozpočtu příslušné kapitoly státního rozpočtu.
Plán financování provozu ICT
Všechny stávající i plánované prostředky ICT, zahrnuté do této informační koncepce, musí mít zajištěno průběžné, každoroční financování svého provozu, rozvoje a obnovy majetku, tzv. „mandatorní výdaje“.
Celkové provozní výdaje činí za poslední rozpočtové období: xyz mil. Kč. Pro následující roky až do roku 202X (horizont IK úřadu) lze oprávněně předpokládat následující plán výdajů:
Pokrytí mandatorních výdajů bude zajištěno kombinací zdrojů ze státního rozpočtu a zdrojů spolufinancovaných z ESIF EU.
Část B: Koncepce řízení služeb ICT
Odpovídá na otázky JAK? budovat a řídit služby ICT na podporu výkonu služeb veřejné správy úřadu. Koresponduje s Metodami řízení ICT VS ČR.
Než budete pokračovat v hodnocení stávajícího stavu řízení, projděte si zpětně dotazník z posledního Benchmarku VS a najděte si svůj úřad v závěrečné zprávě z Benchmarku.
Zároveň doporučujeme pročíst MŘICT, kde najdete užitečné tipy na standardy řízení, které je doporučeno používat ve VS pro řízení ICT. Tyto užitečné zdroje se kontinuálně doplňují o cenné informace.
Popis stávajícího stavu řízení informatiky
Uveďte hlediska, ze kterých budete hodnotit stávající stav řízení útvaru ICT a eGovernmentu úřadu. Kriticky hodnoťte pozitivní i negativní skutečnosti. Popište, které prvky řízení chcete zachovat, a které naopak změnit. Vysvětlete proč. Využijte navrženou strukturu kapitoly.
Strategie, plánování a organizace řízení informatiky
Popište řízení schopností ICT útvaru. Uveďte, zda využíváte obecné metodiky řízení, případně popište vlastní způsob. Popište personální zabezpečení (FTE, úroveň znalostí, role), generační obměny, rozvoj znalostí, držení potřebného know-how členy týmu útvaru ICT, apod. Kriticky zhodnoťte potřebu realizace změn v řízení ICT, uveďte pozitivní i negativní skutečnosti. Vložte seznam řídících dokumentů, které využíváte pro řízení ICT úřadu. Klíčové posuzované schopnosti se pro účely hodnocení stávajícího stavu přebírají z MŘICT, kapitoly Řízení na úrovni útvaru ICT .
Zhodnocení stavu a metod řízení životního cyklu IS Pořízení a změny informačních systémů Provoz informačních systémů Poskytování služeb informačních systémů Útlum, konzervace a ukončení informačních systémů
Popište řízení životního cyklu IS úřadu podle jeho jednotlivých fází. Kriticky hodnoťte pozitivní i negativní skutečnosti. Uveďte případné metodiky, podle kterých životní cyklus IS řídíte. Vstupy pro hodnocení čerpejte z MŘICT, kapitoly Řízení jednotlivých ICT řešení .
Organizační opatření jsou formalizována v řídící dokumentaci, kde:
- je určuje pro řízení každého informačního systému věcného správce a technického správce.
- Věcný správce stanovuje požadavky na služby informačního systému a poskytování služeb informačního systému splňujících tyto požadavky.
- Technický správce zajišťuje
- návrh a realizaci informačního systému z hlediska splňování
- požadavků na služby informačního systému
- požadavků na technické a programové prostředky kladených na ně právními předpisy upravujícími informační nebo komunikační technologie, informační koncepcí orgánu veřejné správy a provozní dokumentací, a jde-li o informační systém spravovaný orgánem veřejné správy, pro nějž jsou závazná usnesení vlády, rovněž informační koncepcí České republiky a jinými usneseními vlády týkajícími se informačních nebo komunikačních technologií,
- zpracování provozní dokumentace a její aktuálnost.
Zhodnocení stavu spolupráce s ostatními útvary úřadu
Popište předmět a rozsah spolupráce definované organizačním řádem úřadu. Zhodnoťte stav této spolupráce, pojmenujte pozitivní i negativní stránky, identifikujte slabá místa. (např. spolupráce s Digitálním zmocněncem). Vybrané oblasti, kterých se může spolupráce týkat se přebírají z MŘICT, kapitoly Spolupráce s ostatními útvary úřadu a eGovernmentu .
Zhodnocení stavu spolupráce s orgány centrální koordinace ICT a eGovernmentu
Zhodnoťte úroveň spolupráce na centrální koordinaci ICT a eGovernmentu, v oblastech stanovování strategických cílů, specifických cílů pro váš úřad, využití centrálních řídících materiálů publikovaných v rámci archi.gov.cz, zpracování či vznášení podnětů pro změny obsahu/rozsahu centrálních materiálů, předkládání žádostí formou formulářů OHA a čerpání podpory ze strany OHA v rámci rozvoje IS či architektury úřadu, apod. Doplňte komunikační matici odpovědných útvarů/osob směrem k ostatním úřadům, například Digitální zmocněnec, člen RVIS, za oblast bezpečnosti hlášení incidentů NÚKIBu, apod. Vybrané oblasti, kterých se může spolupráce týkat se přebírají z MŘICT, kapitoly Spolupráce s ostatními útvary úřadu a eGovernmentu
Přehled běžících a schválených projektů pro řízení ICT
Uveďte aktuálně probíhající změny stávajícího stavu řízení ICT úřadu. Pro úspěšné řízení rozvojových programů/projektů, jejich kapacit, nákladů i přínosů musí být evidence projektů a záměrů úplná. Proto je úkolem každé aktualizace IK úřadu vždy posbírat informace o všech záměrech úřadu, včetně záměrů pro Digitální Česko, a teprve potom obezřetně posoudit, zda identifikované projekty mohou mít jakýkoli vztah k řízení ICT. Více viz. MŘICT kapitola Postup a plán realizace změn (Roadmap).
Přehled projektů řízení ICT
Zde uveďte seznam projektů, které mají dopad na změny v řízení ICT a jsou v různých fázích přípravy, schválení či průběhu.
Shrnutí potřeb ze stávajícího stavu
Stručně shrňte, co vyplývá z této kapitoly nejdůležitějšího pro další navazující části a závěry IK (co jsme zjistili). Tuto dílčí rekapitulaci můžete následně použít jako vstup pro celkové manažerské shrnutí v kapitole 2.
Popis důvodů pro změny řízení informatiky
Uveďte motivace ke změnám řízení ICT úřadu.
Zohledněte personální potřeby, organizační požadavky, řízení dodavatelů, program Digitální Česko, IK ČR. Čerpejte ze strategických dokumentů ČR i EÚ, například klientsky orientovaná VS ČR 2030, DČ 2.0 – Cesta k digitální ekonomice. Předpoklady a východiska řízení ICT.
Přehled externích cílů, úkolů a vlivů
Jmenujte externí cíle, úkoly a vlivy, které jsou motorem motivací pro změny řízení ICT úřadu. Mohou zde být uvedeny strategické dokumenty s dopadem na chod úřadu, plnění strategických cílů úřadu, usnesení vlády či zákonné povinnosti apod.
Přehled identifikovaných vnitřních motivací
Popište, jaké jsou vnitřní faktory motivace. Typicky se může jednat o naplňování cílů vytýčených v předchozích verzích IK, potřeba zvýšení efektivity správy a řízení ICT, řízení architektury úřadu, potřeba zavedení nových technologií, SWOT analýza apod.
Shoda se zásadami řízení ICT z IKČR
Doplňte do tabulky níže, jak se v řízení ICT úřadu projevují obecné zásady pořizování, vytváření, správy a provozování informačních systémů veřejné správy popsané v IK ČR zde: Obecné zásady řízení ICT z IKČR
Cíle zlepšování kvality řízení, rozvoje a provozu ICT služeb
Pojmenujte cíle vedoucí ke zlepšování kvality řízení, rozvoje a provozu informačních služeb, například zavedení standardů pro řízení ICT služeb dle doporučených rámců.
Cíle zlepšování v oblasti bezpečnosti
Pojmenujte cíle vedoucí ke zlepšování v oblasti kybernetické bezpečnosti, bezpečnosti dat, služeb, technických a programových prostředků apod., ale i fyzické bezpečnosti.
Shrnutí a interpretace identifikovaných změn řízení ICT
Shrňte identifikované potřeby změn, které chcete naplánovat k realizaci v následujících 3-5 letech. Tuto dílčí rekapitulaci můžete následně použít jako vstup pro celkové manažerské shrnutí v kapitole 2.
Návrh cílového stavu řízení informatiky
V této kapitole popište návrh změn organizace, procesů, metrik a nástrojů řízení ICT úřadu.
Návrh cílového stavu a metod řízení životního cyklu IS
Popište návrh změn ve způsobu řízení životního cyklu IS úřadu.
Návrh cílového stavu strategie, plánování a organizace řízení informatiky
Popište návrh změn v oblastech řízení architektury, personální politiky, vzdělávání a řízení lidských zdrojů, finančního řízení, strategického plánování, řízení změn, řízení rozvoje a provozu, řízení rizik a bezpečnosti
Návrh cílového stavu způsobu spolupráce s ostatními útvary úřadu
Popište návrh změn ve způsobu spolupráce s ostatními útvary úřadu.
Návrh cílového stavu způsobu spolupráce s centrálními autoritami v oblasti ICT a eGovernmentu
Popište návrh změn ve způsobu spolupráce s centrálními autoritami v oblasti ICT a eGovernmentu, například v rámci resortu, ministerstva, státních podniků, OHA, RVIS
Plán realizace změn pro dosažení cílového stavu informatiky
V této kapitole popište, jakými změnovými aktivitami (projekty či programy) budou realizovány změny popsané v předchozí kapitole. Z jejího přečtení by měla být jasná velmi konkrétní představa o tom, kdy budou jednotlivé změny dodány a jakou aktivitou.
Návrh strategie implementace
Popište, kdy a jak převedete záměry identifikované v kapitole 2 do formy konkrétních aktivit (projektů/programů), které nastartujete pro úspěšnou realizaci potřebných změn a dosažení cílového stavu popsaného v kapitole 3.
Plán projektů řízení ICT
Navrhněte plán realizace konkrétních projektů nebo manažerských opatření, kterými budou zajištěny identifikované potřeby změny řízení ICT úřadu. Ze stručného popisu jednotlivých projektů by mělo být rozpoznatelné, jakou konkrétní změnu daný projekt dodává.
Předpoklady úspěšné realizace plánovaných projektů/programů
Doplňte předpoklady a požadavky pro úspěšné zavedení změn, zejména lidské a finanční zdroje, legislativní úpravy a další. Inspiraci je možné najít v MŘICT, kapitole Předpoklady úspěšné digitální transformace veřejné správy.
Způsob financování projektů s dopadem do řízení ICT
Navrhněte plán řízení investičního a provozního rozpočtu.
Část C: Řízení životního cyklu informační koncepce
Tato kapitola je administrativního charakteru a slouží k popisu životního cyklu Informační koncepce. Editujte připravené bloky dle skutečného stavu vašeho úřadu. Nahraďte vzorový text textem platným pro váš úřad. Doplňte potřebné role a jejich odpovědnosti v uvedených oblastech činností.
Naplňování koncepce
Vydávání a vyhodnocování dodržování informační koncepce
Vyhodnocování dodržování IK je základním kontrolním mechanismem zajišťujícím zpětnou vazbu. Dílčí vyhodnocování se uskutečňuje v souladu s pravidelnou aktualizací IK jedenkrát ročně, celkové vyhodnocení v souladu s § 4(5) vyhlášky č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy nejpozději jednou za 24 měsíců od schválení koncepce. Za vyhodnocování dodržování IK je v souladu s legislativou odpovědný vrcholový útvar (orgán) řízení informatiky.
Za naplňování IK jsou považovány činnosti, prostřednictvím kterých dojde k:
- praktickému naplnění záměrů a dlouhodobých cílů uvedených v IK;
- praktickému naplnění postupů a zásad uvedených v IK;
- udržování IK v aktuálním stavu;
- pravidelnému vyhodnocování dodržování IK a k realizaci opatření pro odstranění zjištěných nedostatků.
Pro zajištění praktického naplnění IK je třeba stanovit osobní odpovědnosti za jednotlivé oblasti, které IK řeší.
Postupy při vyhodnocování dodržování informační koncepce
Vyhodnocování musí provádět jiný zaměstnanec úřadu než ten, který je přímo odpovědný za naplňování a aktualizaci IK. Totéž platí pro vyhodnocování dílčích oblastí, pro které byla stanovena konkrétní dílčí odpovědnost.
Vyhodnocování iniciuje vrcholový útvar (orgán) řízení informatiky. Pro vyhodnocování dílčích oblastí mohou být přizváni odborníci na tyto oblasti, avšak musí přitom být dodržena výše uvedená nezávislost vyhodnocující osoby na osobě odpovědné za realizaci.
Všechny činnosti, jejichž provádění je posuzováno, jsou porovnávány s koncepcí platnou
v době, kdy byla daná činnost prováděna. Vyhodnocování bude probíhat metodou dekompozice na dílčí oblasti a jejich následnou expertní analýzou.
Zaměstnanec provádějící vyhodnocení bude sledovat výsledky dílčích vyhodnocení jednotlivých oblastí, evidovat zjištěné nedostatky a zapisovat návrhy opatření na jejich odstranění.
Oblasti pro vyhodnocování informační koncepce
V průběhu vyhodnocování IK se posuzuje zejména:
- zda je kompletně a aktuálně zachycen veškerý obsah požadovaný vzorovou osnovou IK OVM publikovanou OHA a (připravovanou) vyhláškou,
- zda jsou informace v IK v souladu s aktuálním obsahem IK ČR a jejích následných dokumentů,
- zda jsou informace v IK uvedené použity srozumitelně a průkazně k rozhodování o identifikovaných potřebách a o jejich pokrytí plánovanými záměry,
- zda jsou informace v IK v souladu s centrálními evidencemi, zejména agend, ISVS, služeb, údajů a dalších a zda jsou aktuální,
- zda jsou plánované záměry na projekty realizovány ve stanoveném čase a rozsahu,
- zda všechny projekty informatizace a digitální transformace realizované v úřadu skutečně legitimně vyplývají z analýzy a syntézy v IK a jsou i ve shodě s evidencí záměrů Digitálního Česka,
- zda jsou z IK a z následných dokumentů IK ČR implementovány do interních předpisů úřadu a do jeho praxe všechny zásady, postupy a organizační opatření z oblasti řízení informatiky a jednotlivých ISVS.
- zda realizované záměry a přijatá opatření přinesla předpokládaný účinek,
- zda dříve zjištěné nedostatky byly odstraněny nebo se k jejich odstranění směřuje.
Pravidla pro vytváření zápisu z vyhodnocování informační koncepce
Z vyhodnocování bude vytvořen zápis. Za jeho vyhotovení odpovídá zaměstnanec úřadu, který řídí vyhodnocování.
Rozsah zápisu z vyhodnocování
Zápis z vyhodnocování bude identifikovat verzi IK, které se týká, a dále pak bude jednoznačně identifikován pořadovým číslem zápisu. Zápis bude obsahovat následující části:
- identifikační údaje zápisu (verze IK, datum počátku platnosti vyhodnocované IK, pořadové číslo zápisu);
- identifikace všech zaměstnanců, kteří vyhodnocení prováděli, a jejich role (jméno resp. jména, příjmení, útvar nebo externí organizace, funkce);
- záznam o průběhu vyhodnocování dle jednotlivých oblastí (co, jak, kdy a kdo vyhodnocoval);
- poznatky a závěry z vyhodnocování (soupis zjištěných nedostatků, kladná hodnocení);
- soupis přijatých opatření (návaznost na zjištěný nedostatek, obsah opatření, způsob realizace);
- schválení zápisu z vyhodnocení (kdo - jméno resp. jména, příjmení, útvar nebo externí organizace, funkce a kdy zápis schválil).
Postup vyhotovení zápisu z vyhodnocování
Do zápisu se po úvodních identifikačních údajích nejprve zapisuje záznam o průběhu vyhodnocení a poznatky a závěry z něj.
Zápis schvaluje náměstek představený útvaru, jehož zaměstnanci vyhodnocení IK provedli. Schválený zápis se zpřístupní a všichni dotčení zaměstnanci se s ním seznámí obdobným způsobem, jako je to u nové verze IK.
V dalším kroku ředitel odboru, odpovědného za realizaci IK, zajistí ve spolupráci s příslušnými odbornými útvary zpracování návrhu vhodných opatření, jejichž přijetí povede k odstranění zjištěných nedostatků, pokud byly nějaké nalezeny, která se spolu se schváleným zápisem předloží ke schválení vrcholovému útvaru (orgánu) řízení informatiky. Opatření s vlivem na obsah IK se promítnou v nejbližší řádné aktualizaci koncepce.
Postupy při provádění změn informační koncepce
Při provádění změn IK musí být dodržován níže uvedený postup. Uvedené činnosti provádí zaměstnanec odpovědný za plnění a aktualizaci IK.
Provádění změn do IK lze rozdělit na čtyři činnosti:
- včasná detekce změn v oblastech, které se dotýkají IK tak, aby byla zajištěna včasná změna IK;
- vlastní provedení změny v IK resp. vydání její nové verze;
- schválení změny IK resp. její nové verze;
- příprava nové IK v předstihu před ukončením platnosti té stávající.
Postup pro zajištění včasné změny informační koncepce
Pro zajištění včasné aktualizace IK bude prováděna její revize 1x ročně a to tak, aby byla v souladu s aktuálními požadavky úřadu, platných strategií a požadavky příslušných právních předpisů. V případě zjištění potřeby promítnutí těchto změn do informační koncepce, bude vydána její nová verze.
Událostmi, které povedou na nutnost aktualizace informační koncepce i mimo stanovenou periodu, jsou zejména:
- významná změna organizační struktury úřadu, při které dojde ke změnám odpovědností vztahujících se k IS,
- významná změna procesů, ve kterých je užíván IS,
- vznik nového záměru na pořízení nebo vytvoření nové části IS,
- dokončení části IS (uvedení části IS do produktivního provozu), jejíž pořízení nebo vytvoření bylo zahájeno v předcházejícím nebo stávajícím období,
- ukončení provozu části IS,
- významné změny v právních předpisech,
- nové podstatné požadavky na podporu výkonu veřejné správy úřadu službami jeho informačních systémy.
V této souvislosti musí vedoucí zaměstnanci všech organizačních jednotek, které užívají IS, jsou věcnými garanty nějaké části IS, respektive odpovídají za správu nějaké části IS, hlásit výše uvedené změny zaměstnanci odpovědnému za přípravu změn a tvorbu nových verzí IK. Tento zaměstnanec je též povinen sledovat další výše uvedené změny a jejich dopad na informační koncepci.
Postup zápisu změny do dokumentu informační koncepce
Změny IK budou prováděny formou vydání nové verze. Jednotlivé verze budou číslovány dvěma čísly, oddělenými tečkou:
- hlavní číslo verze, které bude odlišovat verze s významnými změnami (například kompletně přepracované kapitoly, změny zásadních postupů a podobně);
- vedlejší číslo verze, které bude odlišovat drobnější změny (například doplnění nového informačního systému, změny v personální oblasti, drobná změna v postupech).
Každá verze bude obsahovat tabulku změn oproti verzi předchozí. V této tabulce budou pro každou změnu stručně uvedeny následující informace:
- popis provedené změny;
- odůvodnění změny;
- identifikace místa (příp. více míst) dokumentu (minimálně číslem kapitoly), kterého se změna dotkla.
Postup přípravy nové informační koncepce
Zaměstnanec odpovědný za naplnění informační koncepce společně se zaměstnancem odpovědným za aktualizaci informační koncepce připraví 6 měsíců před ukončením její pětileté platnosti podklady pro strategické rozhodnutí vedení sekce ICT ohledně přípravy nové informační koncepce. Tyto podklady budou obsahovat:
- vyhodnocení stávající informační koncepce a její účinnosti (míru naplnění cílů, záměrů a opatření) za dobu od jejího vzniku,
- vyhodnocení způsobu vzniku a údržby stávající informační koncepce a doporučení pro postup tvorby nové informační koncepce (vlastními silami nebo s využitím externího dodavatele apod.),
- další podklady dle uvážení.
Odpovědnosti za uplatňování informační koncepce
Odpovědnosti za životní cyklus dokumentu informační koncepce
Životní cyklus IK je charakterizován těmito hlavními procesy a odpovědnostmi.
Odpovědnost za realizaci informační koncepce
Odpovědnost za naplnění IK je stanovena vždy vrcholovému útvaru (orgánu) řízení informatiky úřadu. Příklady dílčích odpovědností za jednotlivé oblasti IK jsou uvedeny v následující tabulce.
Splnění zákonných povinností
Odpovědnost za splnění komplexních zákonných povinností byla stanovena ministru/řediteli úřadu. Vybrané dílčí odpovědnosti za splnění konkrétních zákonných povinností jsou uvedeny v následující tabulce a slouží v této verzi IK pouze jako příklady.
Část D: Dodatky a přílohy informační koncepce úřadu
Dodatky
Základní pojmy a zkratky
Aktualizujte základní pojmy a zkratky dle zvyklostí a potřeb vašeho úřadu.
Seznam modelů, schémat, obrázků
Aktualizujte výsledný seznam v případě přidaných či odstraněných obrázků.
Seznam literatury
Doplňte interní řídící dokumenty, které jsou popisují řízení či strategii vašeho úřadu. Doplňte relevantní nařízení, zákony, směrnice, vyhlášky, které jsou relevantní pro úřad.
Seznam příloh
Tuto kapitulu využijte v případě, že máte vstupy vytvořené v samostatných souborech, publikované na intranetu či zveřejněné na internetu.
Přehled agend a kompetencí úřadu
Vložte přehled agend, máte-li zpracováno v samostatném dokumentu, případně vložte odkaz, kde máte publikováno.
Přehled právních norem upravujících činnost úřadu se vztahem k informačním a komunikačním systémům
Uveďte relevantní přehled agend pro váš úřad, máte-li zpracováno v samostatném dokumentu, případně vložte odkaz, kde máte publikováno.
Přehled a karty ISVS
Vložte karty ISVS, máte-li zpracováno v samostatném dokumentu, případně vložte odkaz, kde máte publikováno. Karty IS jsou využívány například v rámci žádostí o stanovisko OHA, v rámci rozvoje IS úřadu, apod.
Modely úřadu
Uveďte, zda máte vytvořené modely architektury dle rámce TOGAF a v modelovacím jazyku ArchiMate a popište místo uložení, například centrální úložiště eGovermentu, centrální úložiště resortu, centrální úložiště úřadu, lokální IT úložiště apod. vložte odkaz
Přehled a karty programových/projektových záměrů
Vložte karty programových/projektových záměrů ve formátu dovolujícím zobrazení v MS Word. Uveďte umístění, případně přiložte přílohu.
Tabulka pro uvedení IK OVS do souladu s IK ČR
Organization change management
Ve světě neustálých změn se řízení organizačních změn stalo důležitou součástí každého transformačního plánu a strategie.
Dnešní prostředí digitální transformace úřadů vyžaduje, aby úřady neustále procházely změnami, pokud chtějí zůstat efektivní a naplňovat potřeby a očekávání klientů.
Aby se zaměstnavatelé mohli přizpůsobit novým trendům, technologiím a procesům, musí změnit svůj přístup k provádění změn ve svých organizacích.
Co je to Řízení organizačních změn?
Organizační změna je proces přechodu ze současného stavu organizace do žádoucího budoucího stavu. Řízení organizačních změn vyžaduje plánování a implementaci změn v organizacích tak, aby se minimalizoval odpor zaměstnanců a náklady pro organizaci a současně maximalizovala účinnost úsilí o změnu.
Podle mnoha výzkumů je jedním z hlavních důvodů selhání projektů odpor a odolnost (rezistence) zaměstnanců vůči změnám a také špatná interní komunikace.
Správné vzdělávání zaměstnanců, jakož i otevřená a čestná komunikace jsou proto klíčovými prvky při minimalizaci negativních reakcí zaměstnanců. Před provedením změny by zaměstnanci měli být informováni o povaze změny a logice, která je za ní.
Proč bychom měli přehodnotit tradiční modely řízení změn?
Existují dva hlavní důvody, proč zaměstnavatelé potřebují přehodnotit tradiční modely řízení změn:
1. Zaměstnanci jsou hlavní hnací silou změn
V tradičních modelech řízení jsou vrcholový management a vedení hlavními a jedinými původci myšlenek na změnu. V rámci tohoto přístupu jsou zaměstnanci považováni za pasivní předměty změny. V takovém případě se mnoho důležitých poznatků zaměstnanců o tom, jak lze organizaci zlepšit, pomine nebo zanedbá.
Novější modely řízení změn organizace vidí zaměstnance jako hlavní hnací sílu úspěšné změny. Když se zaměstnanci do procesu aktivně zapojují od samého začátku, je mnohem pravděpodobnější, že pro změnu zahoří, odstraní se jejich odpor vůči změnám a jejich postoje se uvedou do souladu se strategickými cíli organizace a celé veřejné správy.
2. Organizační změna je trvalý proces
Organizace tradičně považovaly organizační změny pouze za projekty s počátečním a konečným datem. V rámci těchto projektů by organizace řešily vždy jednu oblast pro zlepšení, jako je implementace nového IT systému. Po dokončení projektu se organizace jednoduše vrátí ke starému způsobu práce, dokud nenastane nový projekt.
Novější přístup k řízení organizačních změn říká, že se jedná o probíhající proces, který nikdy nekončí. Role manažerů organizačních změn je proto méně prosazovat projekty diskrétních změn, ale spíše navrhovat organizaci způsobem, který umožňuje nepřetržité přizpůsobování se stále se vyvíjejícímu prostředí.
Pilíře úspěšného řízení organizačních změn
V minulosti řada projektů a s nimi spojených organizačních změn selhala. Proto jsou níže sebrány osvědčené postupy neboli pilíře úspěšného řízení organizačních změn .
1. Nejvyšší vedení musí být na palubě, v čele
Přestože by zaměstnanci měli být v centru každé iniciativy změny, úspěšné změny začínají nahoře. Ministři, předsedové, generální ředitelé a další nejvyšší vedoucí pracovníci jsou důležití, protože jejich oprávnění jim umožňuje vytvářet pocit naléhavosti, který je často nezbytný při provádění změn.
Doporučuje se, aby organizace zřídily tým odborníků na nejvyšší úrovni, kteří podávají zprávy ministrovi, generálnímu řediteli a mají za úkol vypracovat cílenou vizi a strategii pro změnu. Měli by být také schopni komunikovat o strategii způsobem, který je dostatečně jednoduchý na to, aby všichni zaměstnanci porozuměli.
2. Měly by být stanoveny jasné cíle
Zahájení změny bez jasné strategie a definovaných cílů je jedním z hlavních důvodů, proč iniciativy řízení organizačních změn selhaly. Protože se změny většinou provádějí za účelem nápravy nebo zlepšení současné úrovně výkonu veřejných služeb a provozu organizace, měly by organizace vždy identifikovat konkrétní, měřitelné výsledky očekávané od změny.
Toto je jediný způsob, jak mohou zaměstnavatelé řídit organizační sladění všech zaměstnanců a přimět je k dosažení stejných cílů.
3. Pochopení dopadu změny
Jakmile jsou jasné cíle a metriky stanoveny, dalším krokem je určení dopadů, které změna bude mít na různých organizačních úrovních a dokonce i pro jednotlivce.
Organizace musí přezkoumat účinek na každou organizační jednotku. Tento typ informací a poznatků pomáhá určit, kde jsou školení, motivace a podpora nejvíce potřebné ke zmírnění dopadů.
Zeptejte se sami sebe postupně na tyto 4 otázky:
- Jaké jsou dopady změny?
- Kdo bude nejvíce zasažen?
- Jak to bude přijato?
- Co uděláme pro zlepšení přijetí změn?
4. U zaměstnanců se musí zavést přístup zaměřený na změnu
Jak již bylo řečeno, bez sladění zaměstnanců je velmi obtížné úspěšně implementovat změny v organizacích. Je však povinností zaměstnavatelů pomáhat zaměstnancům přizpůsobit se a rozvíjet nové, na změnu zaměřené myšlení.
Zde je důležité mobilizovat střední management, aby se ztotožnil se změnami v organizaci, začal je podporovat a řídit. Manažeři se musí ujistit, že zaměstnanci chápou svou roli při realizaci vize a jsou plně na palubě.
Úřady potřebují vybudovat kapacity odborníků na změny a současně posílit kapacit všech odborností tak, aby součástí pracovní náplně každého úředníka (některých více a některých méně) bylo vedle výkonu každodenní rutiny i podíl na realizaci změn ve svém okolí.
5. Je důležité pochopit psychologické potřeby zaměstnanců
Sebeurčení a seberealizace jsou jedněmi ze základních potřeb lidí, kterým musíme lépe porozumět, abychom mohli úspěšně vést změny v organizacích. Ve veřejné správě jsou to bohužel často i potřeba pocitu bezpečí, zakonzervování stávajícího známého a bezpečného stavu a minimalizace přidělovaných úkolů.
Překonání obav a konzervace může vést u lidí, kteří mají být součástí dlouhodobé budoucnosti úřadů, právě přes uznávání a posilování potřeb sebeurčení a seberealizace zaměstnanců, jakož i jejich zapojení, slyšení a zmocnění je důležité.
Co organizace tedy mohou udělat, aby vytvořily procesy řízení změn, které zohledňují základní lidské potřeby samostatnosti a kompetence?
- Můžeme uspokojit potřeby zaměstnanců na samostatnost tím, že je vyzveme,
aby přihlásili své nápady na změny v rámci projektů.
- Můžeme zmocnit zaměstnance ke sběru změnových požadavků.
- Tím, že zaměstnancům poskytujeme prostor k nápadům na změnu, potvrzujeme také jejich způsobilost.
- Zaměstnancům poskytujeme snadný přístup k dovednostem a nástrojům potřebným k zvládnutí výzev, které proces změny přináší.
- Můžeme kultivovat pracovní prostředí, ve kterém lidé cítí pocit sounáležitosti, péči se o sebe a vnímají svůj vztah k organizaci jako přiměřeně stabilní.
6. Požadované chování zaměstnanců by mělo být posíleno pomocí uznání
Když mluvíme o uznávání zaměstnanců, většinou o tom uvažujeme jako o nástroji ke zlepšení a zvýšení motivace, angažovanosti a výkonu zaměstnanců. Nicméně, uznání zaměstnance je nejlepší způsob, jak jej převést na nový způsob chování a změny kultury organizace.
Nejlepší způsob, jak posílit změny v organizacích, je proto odměnit požadované chování zaměstnanců. K tomu je důležité předvídat a řešit odpor vůči změnám od samého začátku.
Protože většina zaměstnanců ráda zůstává ve své komfortní zóně, měli by zaměstnavatelé vědět, jak jim pomoci dostat se ven a přijmout nové způsoby, jak dělat věci jinak.
7. Transparentní, častá a čestná komunikace je nutností
Většina zaměstnanců tvrdí, že jejich zaměstnavatel není k nim vždy pravdivý a otevřený. Tento nedostatek důvěry může být smrtelný, pokud jde o iniciativy v oblasti řízení organizačních změn. Nejen, že zaměstnanci musí být dobře informováni během celého procesu změn, ale tato komunikace musí být čestná, transparentní a musí jít obousměrně. To znamená, že zasílání zpravodaje celé organizaci prostě nestačí.
Protože se většina zaměstnanců necítí pohodlně se změnami, transparentnost v každém kroku procesu řízení změn pomáhá budovat důvěru a spojení se zaměstnanci. Zaměstnavatelé také musí mít strategii, jak zabránit špatné komunikaci na pracovišti.
Zaměstnavatelé se proto nyní musí obrátit k novějším komunikačním řešením pro zaměstnance, která jim umožní mít hlavní zdroj komunikace, dokumentace a konverzací na jednom centrálním místě, typicky v intranetu nebo vnitřní sociální síti.
8. Řízení organizačních změn vyžaduje spolupráci a spoluvytváření
Výše se hovoří o důležitosti zapojení a posílení postavení zaměstnanců v celém procesu změn. Povzbuzením zaměstnanců, aby sdíleli své myšlenky a podíleli se na projektu, je celý proces mnohem úspěšnější.
Zaměstnanci však musí mít způsob, jak spolupracovat a komunikovat snadno. Zde je klíčový výběr interních komunikačních kanálů. Například e-mail jako primární komunikační kanál se nedoporučuje. Protože mnoho zaměstnanců trpí přetížením informacemi, kvůli kterým často ignorují svůj e-mail a intranety, je nutné zvolit účinnější komunikační kanály!
9. Úsilí o změnu se musí měřit
Během celého procesu řízení organizačních změn by měly být měřeny výsledky a dopad iniciativ. To neznamená pouze měření dopadu změny na náklady nebo počet zaměstnanců.
Místo toho by interní komunikátoři i manažeři měli sledovat a měřit zapojení zaměstnanců vytvořené novými procesy. Efektivní komunikace manažera je zde nesmírně důležitá.
Pochopení toho, jak jsou zaměstnanci zaujati sdílenými zprávami o změnách, může zaměstnavatelům pomoci posoudit jejich plán řízení změn a určit jeho účinnost a zdokumentovat veškeré získané zkušenosti.
Závěry
Projekty a procesy digitální transformace úřadů směrem k eGovernmentu nejsou jenom projekty implementace ICT řešení. Jsou to zejména projekty změn fungování výkonu veřejné správy v organizaci.
Takové projekty musí mít pro svůj úspěch oporu v metodách řízení organizačních změn (OCM).
Schopnost řídit organizační změny musí být v úřadech zavedena jako trvalá vnitřní schopnost organizace a součást její kultury, nejenom jako externími poradci dodaná součást vybraných projektů.
Personalisté a všechny úrovně řízení úřadu se stávají klíčovým faktorem úspěchu digitální transformace úřadů. Lídři digitalizace v úřadech je musí na svou stranu získat a aktivně zapojit co nejdříve.
Centrální nákup státu ICT produktů
Dynamický nákupní systém
Dynamický nákupní systém je zvláštním řízením, které probíhá elektronickou formou. Jeho hlavním účelem je podstatné ulehčení zadávání veřejných zakázek, jejichž předmětem je pořízení běžného (standardizovaného) a obecně dostupného zboží, služeb nebo stavebních prací; pokud některá plnění tyto podmínky nesplňují, nelze pro jejich zadání dynamický nákupní systém využít.
Dynamický nákupní systém lze tedy využít zejména pro pořizování takových typů komodit jako jsou kancelářské potřeby, běžně dostupné IT komponenty jako jsou monitory, klávesnice, náplně do tiskáren, překladatelské služby, běžný stavební materiál. V případě stavebních prací půjde spíše o výjimečnou možnost využití dynamického nákupního systému (lze si představit např. pravidelné provádění výkopových prací).
Zadávání veřejných zakázek v rámci dynamického nákupního systému se rozpadá do dvou základních fází - v prvé fázi se dynamický nákupní systém zavádí, a to formou otevřeného řízení, ve druhé fázi pak dochází v zavedeném dynamickém nákupním systému k zadávání jednotlivých veřejných zakázek dle pravidel tohoto systému.
Více v manuálu MVČR
Rámcová dohoda
Rámcová dohoda je na rozdíl od Dynamického nákupního systému předem daná smlouva, tzn. že při jejím uzavření musí být předem známí veškeří účastníci. V rámcové dohodě jsou pevně dané ceny a slevy, za které se ICT produkty nabízejí.
Seznam centrálních nákupů
Přepisu znaků do podoby, ve které se zobrazují v informačních systémech veřejné správy
Seznam agend veřejné správy dle registru RPP
Veřejná moc VS Veřejná správa
Metodika pro evidenci služeb VS, jejich úkonů a plánu digitalizace
Financováno z projektu Využívání prvků procesního řízení a zavedení standardů pro výkon agend veřejné správy ("PMA 3"), reg. č.: CZ.03.4.74/0.0/0.0/15_019/0004225. Projekt je realizován v rámci OPZ.
Tato metodika je určena ohlašovatelům agend, kteří realizují úpravu agend dle zákona č. 12/2020 Sb., o právu na digitální služby a o změně některých zákonů (dále jen „zákon o právu na digitální služby“). Metodika je zveřejněna také na stránkách Procesního modelování agend.
Co od vás potřebujeme
Abyste vyplnili katalog služeb veřejné správy (VS). K tomu musíte nejdříve udělat následující:
- Identifikovat služby VS a popsat jejich atributy v agendách, které ohlašujete.
- Rozložit služby VS na jednotlivé úkony a popsat jejich atributy.
- Definovat způsob, jakým dochází k interakci mezi OVM a klientem – určit obslužný kanál.
- Určit, kdy a jakými obslužnými kanály bude možné provést digitální úkon a využívat digitální službu.
Vzhledem k tomu, že údaje v katalogu služeb VS jsou referenční, je nutné je udržovat aktuální.
Co je katalog služeb VS
Katalog služeb VS je součást registru práv a povinností (RPP) a jako takový obsahuje soubor údajů o službách VS, úkonech a jejich obslužných kanálech. Na katalog služeb VS lze nahlížet dvěma způsoby – a to jako na klientskou aplikaci publikující údaje pro klienty a také jako na úřednickou aplikaci sloužící ke sběru a editaci údajů. Katalog služeb VS bude průběžně rozvíjen, aby plnil následující funkce:
- informační – poskytoval přehled o existujících službách VS a způsobu jejich vyřízení,
- publikační – poskytoval údaje nezbytné pro správné zobrazování služeb VS na portálech (řazení, kategorie, mohlo by vás také zajímat atd.),
- řídící – umožnil řízení dodávky služeb VS (stanovení plánu digitalizace, informace o odpovědnosti za službu usnadní koordinaci přechodu k digitální službě atd.),
- automatizační – umožnil sběr údajů nezbytných pro automatizaci.
Proč to potřebujeme
Pro potřeby plnění zákona o právu na digitální služby vzniká katalog služeb VS, který navazuje na evidenci služeb iniciovaných klientem (úkony na žádost). Katalog služeb VS se skládá ze všech služeb VS, nezáleží tedy na tom, jestli službu inicioval klient (subjekt práva), nebo jestli je služba vykonávaná z moci úřední.
V katalogu služeb VS se služby VS budou dělit na úkony. Pro každý úkon se následně budou evidovat obslužné kanály – způsoby, jakými lze daný úkon vykonat.
Cílem evidence služeb VS je přehledně informovat klienta o všech dostupných službách poskytovaných OVM.
Cílem evidence úkonů služeb VS je podpora rozvoje eGovernmentu – stanovení plánu digitalizace, který má proběhnout v letech 2021 až 2025. Na něj budou postupně navázané další procesy umožňující poskytování digitálních úkonů a služeb, které nejsou předmětem této metodiky. Bližší informace lze získat na https://archi.gov.cz/.
V jakém termínu
Podle zákona o právu na digitální služby má vláda do 1. 2. 2021 stanovit plán digitalizace služeb VS, proto je nutné, aby v první fázi (do konce roku 2020) katalog služeb VS obsahoval následující:
- evidenci všech služeb poskytovaných orgány veřejné moci – v první fázi bude kladen důraz na služby VS iniciované klientem a primárně takové, které realizuje OVM ohlašovatele,
- rozložení služeb VS na jednotlivé úkony a s tím spojené informace, jakými obslužnými kanály je lze vykonat,
- plán digitalizace – informace, jakými obslužnými kanály a kdy bude možné úkon digitálně vyřídit.
To vše musí být součástí ohlášených agend v RPP nejpozději do konce roku 2020. Následně bude nutné doplnit služby vykonávané z moci úřední a takové služby, za které reálně zodpovídá i jiné OVM než OVM ohlašovatele.
Stručný návod k vyplnění katalogu služeb VS
- Prvním krokem je zkontrolovat si rozsah kompetencí úřadu a určit si právní předpisy upravující vaše činnosti vůči externím subjektům, ať již jsou nebo ještě nejsou ohlášeny jako vaše agendy.
- Po té sestavte úplný seznam agend, kterých jste nebo byste měli být jako OVM ohlašovateli. Neuvažujte agendy, ve kterých sice působíte, ale ohlašuje je jiné OVM.
- Identifikujte všechny služby VS a ideálně je současně rozložte na jednotlivé úkony.
- K úkonům následně přiřaďte a popište příslušné obslužné kanály.
- Na závěr uveďte plán digitalizace úkonů na základě rozhodnutí odpovědných manažerů.
- Pokud plán digitalizace nelze stanovit (např. jde o výkon samostatné působnosti, nebo přenesené působnosti bez existence centrálního agendového informačního systému (AIS), je nutné alespoň uskutečnit kroky, které překážky digitalizace odstraní (např. novelizovat příslušný právní předpis)
Co k tomu potřebujete
Ke kompletní evidenci služeb VS, jejich úkonů a stanovení plánu digitalizace je nutné nejdříve identifikovat jednotlivé entity celé evidence, a to: službu VS, úkon a jeho obslužný kanál. Následující podkapitoly se zabývají definicí těchto pojmů:
Služba VS
Představuje funkci (činnost) úřadu, která je vědomě poskytnuta konkrétním OVM konkrétnímu příjemci služby podle příslušného právního předpisu tak, že přináší příjemci vnímanou hodnotu, ať už v podobě benefitu nebo splnění zákonné povinnosti. Evidují se pouze takové služby VS, během nichž dochází k interakci mezi OVM a klientem či naopak, nikoli k interakci mezi OVM a OVM. Na službu VS lze také pohlížet jako na dosažení práva či naplnění povinnosti klienta, které nelze splnit jinak než interakcí či sérií interakcí mezi klientem a OVM. Služba se dělí podle toho, zdali je iniciována klientem nebo vykonávaná z moci úřední. Každá služba se skládá z nejméně jednoho úkonu.
Při evidenci služeb VS postupně procházejte právní předpisy a identifikujte služby VS pomocí definičních znaků uvedených níže. Ke každé službě VS popište její atributy podle metodiky.
Definiční znaky služby VS
- Služba VS se řídí předem danými podmínkami, které jsou jasně definované alespoň jedním právním předpisem:
- např. služba rodičovský příspěvek vyplývá ze zákona č. 117/1995 Sb., o státní sociální podpoře.
- Pomocí služby VS má klient možnost realizovat některá svá práva nebo povinnosti, které mu vyplývají ze zákona a které nelze realizovat/splnit jinak než (sérií) interakcí mezi ním a OVM:
- např. klient má právo dle zákona č. 329/1999 Sb., o cestovních dokladech, si zažádat o vydání cestovního pasu,
- např. klient (provozovatel skládky) má zákonnou povinnost zasílat každoročně údaje o stavu vytvořené finanční rezervy, údaje o stavu volné kapacity skládky a údaje o poplatcích za uložený odpad krajskému úřadu příslušnému podle místa skládky na základě zákona č. 185/2001 Sb., o odpadech.
- Každá služba VS má výstup, který klient vnímá jako určitou hodnotu, a to buď ve formě dosažení benefitu nebo splnění zákonné povinnosti:
- např. výstup služby ve formě benefitu je pro klienta vydání cestovního pasu,
- např. klient (provozovatel skládky) má zákonnou povinnost zasílat každoročně údaje o stavu vytvořené finanční rezervy, údaje o stavu volné kapacity skládky a údaje o poplatcích za uložený odpad krajskému úřadu příslušnému podle místa skládky na základě zákona č. 185/2001 Sb., o odpadech. V tomto případě je pro klienta výstupem splnění zákonné povinnosti a zároveň se tak vyhne sankcím při nesplnění povinnosti vyplývající mu ze zákona.
- Služba VS je poskytovaná konkrétním OVM konkrétnímu příjemci:
- např. klient Šimon Trusina žádá o rodičovský příspěvek na příslušném pracovišti Úřadu práce.
- Služba VS je iniciována buďto klientem nebo je vykonávána z moci úřední:
- např. služba iniciovaná klientem – povinnost písemného ohlášení změny ve skutečnostech rozhodných pro trvání nároku na dávku státní sociální, podpory vyplývající ze zákona č. 117/1995 Sb., o státní sociální podpoře
- např. služba vykonávaná z moci úřední – dle zákona č. 300/2008 Sb. o elektronických úkonech a autorizované konverzi dokumentů, ministerstvo zneplatní přístupové údaje do datové schránky pověřené osobě v případě zrušení jejího pověření a o této skutečnosti ji informuje.
- Služba VS je v drtivé většině případů souborem více úkonů:
- např. služba volba výše rodičovského příspěvku zahrnuje soubor těchto úkonů: podání nové volby, výzva k doložení/doplnění žádosti, doložení/doplnění žádosti, výzva k seznámení se s podklady, seznámení se s podklady, zaslání rozhodnutí/oznámení.
Jedná se o více služeb, pokud:
- se mění klient služby:
- např. jednou službou je vydání povolení pro uzavřené nakládání s geneticky modifikovanými organismy dle zákona č. 78/2004 Sb., o nakládání s geneticky modifikovanými organismy a genetickými produkty, kdy žádá firma, která povolení ke své činnosti potřebuje; jinou službou je, že kdokoli může zaslat své písemné vyjádření k uvedené žádosti,
- dochází k interakci s více OVM:
- např. podle zákona č. 19/1997 Sb., o některých opatřeních souvisejících se zákazem chemických zbraní, je nutné, aby klient ztrátu nebo odcizení vysoce nebezpečných látek ohlásil Policii ČR a Státnímu úřadu pro jadernou bezpečnost, jedná se tedy o dvě služby,
- z využití jedné služby vyplývají pro klienta nová práva či povinnosti, které nelze splnit jinak než další novou interakcí s OVM, tedy další službou:
- např. výstupem jedné služby je vydání povolení pro uzavřené nakládání s geneticky modifikovanými organismy (GMO) dle zákona č. 78/2004 Sb., nabytím tohoto povolení klientovi vzniká nová povinnost, a sice písemně poskytnout nové informace týkající se rizik GMO a oznámit přijatá opatření Ministerstvu životního prostředí, přičemž poskytnutí těchto informací nelze provést jinak než novou interakcí klienta s OVM – jde proto o další službu VS,
- dojde ke změně výstupu služby:
- např. službou je získání rodičovského příspěvku čerpaného měsíčně v určité výši (výstupem služby je přiznání rodičovského příspěvku), jinou službou je žádost o změnu výše rodičovského příspěvku, protože jejím výstupem je pouze změna vyplácené částky,
- dojde ke změně typu služby:
- např. služba žádost o znepřístupnění datové schránky vycházející ze zákona č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi, je iniciovaná klientem, ale zároveň existuje služba znepřístupnění datové schránky vykonávaná z moci úřední.
Dosud ohlašované úkony na žádost v RPP představují v naprosté většině případů služby VS iniciované klientem.
Služby se nedefinují podle jednotlivých vlastností výstupu, ale pouze podle výstupu. Např. nezáleží na tom, zda je občanský průkaz vydáván na 5, 10 nebo 35 let – stále je výstupem služby „plastová kartička eObčanka“, a proto jde o tutéž službu. Také nezáleží na tom, co musí klient nebo OVM doložit, směrodatný je výstup služby. Pokud je výstup stejný, jedná se také o stejnou službu.
Při identifikaci a popisu služby VS je nutno mít stále na paměti uživatelskou přívětivost a dívat se na řešení problému pohledem klienta.
Úkon
Úkon představuje jednotnou a ucelenou interakci mezi klientem a OVM (úředníkem), která je realizována určeným obslužným kanálem na jednom OVM a která má právní následky. Pomocí úkonu či série úkonů klient usiluje o dosažení výstupu dané služby VS.
Doporučujeme definovat úkony společně s příslušnou službou VS. Jakmile tedy definujete a popíšete službu VS, rovnou ji rozložte na jednotlivé úkony podle definičních znaků uvedených níže. Dále popište atributy úkonu, které jsou stanovené touto metodikou, a zároveň stanovte příslušný obslužný kanál. V této fázi řešíme pouze první rozhodovací instanci, tzn. není např. nutné evidovat úkony týkající se odvolání. Postupným a uceleným popisem služeb, úkonů a obslužných kanálů se vyhnete popisům, které jsou nekompletní či duplicitní.
Definiční znaky úkonu
- Úkon představuje interakci mezi OVM (úředníkem) a klientem:
- např. podání žádosti o vydání cestovního pasu představuje jednu ucelenou interakci.
- Úkon je realizován jedním OVM:
- např. žádost o vydání cestovního pasu podá klient buď na vybraný obecní úřad obce s rozšířenou působností, úřad městské části Prahy, Ministerstvo vnitra, nebo zastupitelský úřad.
- Jeden úkon zahrnuje takové množství kroků, které lze vykonat společně najednou při jedné interakci, samostatně od jiných kroků a v jednom obslužném kanále:
- např. podání žádosti o rodičovský příspěvek včetně doložení náležitostí bez ohledu na způsob podání (osobně na úřadě, prostřednictvím datové schránky, elektronickou poštou s uznávaným elektronickým podpisem) lze realizovat najednou a není potřeba podání rozložit do vícero návštěv, zpráv atd.
- Úkon vykonává buďto klient anebo OVM:
- např. podání žádosti o příspěvek na bydlení vykonává klient,
- např. výzvu k doložení/doplnění žádosti o příspěvek na bydlení vykonává OVM.
- Ke každému úkonu se váže jeden či více obslužných kanálů, kterými lze nebo v budoucnu půjde úkon realizovat:
- např. podání žádosti volba výše rodičovského příspěvku lze učinit jak osobně na úřadě, tak i datovou schránkou a dalšími způsoby.
- Stejně jako služba má oporu v právním předpise:
- např. podání žádosti o příspěvek na dítě vychází z § 67 – 68 zákona č. 117/1995 Sb., o státní sociální podpoře.
Jedná se o více úkonů, pokud:
- se liší vykonavatel:
- např. podání žádosti je vykonávané klientem, ovšem výzva k doplnění/doložení je vykonávaná OVM, jedná se tedy o jiný úkon,
- mají různé právní následky:
- např. úkony vyplývající ze správního řádu „výzva k seznámení se s podklady“ a „zaslání rozhodnutí“ nelze spojit do jednoho úkonu, protože mají rozdílné právní následky – jde o naplnění (realizaci) jiných práv klienta,
- pouze část kroků lze nebo půjde vykonat jiným obslužným kanálem:
- např. podání a zaplacení správního poplatku lze učinit osobně na úřadě (v katalogu služeb VS evidováno jako jeden úkon), jakmile ale zaplacení správního poplatku lze nebo půjde provést elektronicky, je nutné úkon rozdělit na dva: podání žádosti a platba správního poplatku.
Pohlížejte na úkony jako na logický sled po sobě jdoucích kroků, na jejichž konci je výstup služby, tedy pro klienta požadované naplnění služby.
Ne všechny úkony musí nastat vždy (např. výzva k doplnění podání), některé úkony nastávají jen ve zvláštních případech (např. nahlédnutí do spisu). U služby mají být evidovány všechny úkony (interakce mezi klientem/OVM), které teoreticky mohou nastat.
Kdy jde o službu VS a kdy o úkon
- Služba běží od jejího iniciování až po doručení jejího výstupu – je tedy souborem všech možných interakcí OVM/klient, které se postupně (a opakovaně) mohou odehrát.
- Úkon je pouze jednou z interakcí OVM a klienta, která vede k dalšímu úkonu služby, pokud není závěrečným úkonem. Je jasně stanovený jeden vykonavatel (OVM nebo klient), jedná se tedy o jeden krok (o část služby).
Obslužný kanál
Posledním krokem evidence služeb VS je stanovení obslužného kanálu a zároveň popsání jednotlivých atributů obslužného kanálu. Prostřednictvím obslužných kanálů se také plánuje případná digitalizace úkonů, která má proběhnout v letech 2022 až 2025.
Jde o způsob či prostředek, jakým dochází k interakci mezi klientem a OVM. Typy digitálních obslužných kanálů definuje zákon o právu na digitální služby v § 4 odst. 1. Jedná se například o datovou schránku nebo o podání pomocí informačního systému veřejné správy, který umožňuje prokázání totožnosti klienta pomocí elektronické identifikace, jeho autorizace a zpětné prokázání vůle. Součástí popisu obslužného kanálu je i plán digitalizace: jakým obslužným kanálem a k jakému roku (2022 až 2025) plánuje ústřední správní úřad vyřízení úkonu.
Služby VS vycházející z procesních právních předpisů
- Řada služeb VS se řídí obecnými pravidly jako je např. správní řád a další předpisy. Implicitně v nich tedy musí existovat úkony, které zavádí tyto obecné právní předpisy.
- Aby tyto úkony každý ohlašovatel nemusel definovat znovu, správce katalogu je po předchozí konzultaci s gestorem příslušného procesního právního předpisu vytvoří a ohlašovatelé jiných agend se k nim přihlásí (přidají do svých služeb).
- Z hlediska služeb iniciovaných klientem je stěžejní správní řád, kde se jedná o úkony spojené s podáním žádosti a případným následným řízením – např.:
- výzva k doplnění podání,
- doplnění podání,
- nahlížení do spisu.
- Je důležité vědět, zda pro danou agendu platí správní řád bez výjimky, zda platí jen jeho část a zda se týká všech nebo jen určitých služeb VS.
- Seznamy těchto úkonů se budou průběžně doplňovat formou příloh k této metodice.
Atributy
Služby VS
Identifikátor služby
Automaticky (stejně jako v případě agendy nebo činnosti) generovaný kód sloužící pro databázové zpracování údajů.
Název služby
Název by měl klientovi stručně a jasně vystihnout, o jakou službu se jedná. Důležité je, aby byl nezaměnitelný s jinou službou, ale stále velmi jednoduchý, srozumitelný a zapamatovatelný. Měřítkem je, že název služby je používaný (bude používán) v běžném hovoru lidí. Při pojmenování služby vycházejte vždy z příslušného právního předpisu, slangové výrazy (např. rodičák nebo mateřská) nepoužívejte. Pomůckou při pojmenování služby vám může být fráze „Chci vyřídit..“, za kterou dosadíte název služby dle právního předpisu uvedený vždy v 1. pádě. (např. Chci vyřídit rodičovský příspěvek – název služby je tedy rodičovský příspěvek).
Popis služby
Pomocí tohoto atributu detailněji vysvětlíte účel služby VS.Smyslem není kopírování částí právního předpisu, ale krátký a přitom přesný popis, který je srozumitelný pro laickou veřejnost a nebude obsahovat nejasné nebo těžko dohledatelné termíny.Obsahem je pouze věcné popsání existence služby.
Typ služby
Typ služby stanovuje, zda je služba iniciovaná klientem nebo vykonávaná z moci úřední. Pokud se například jedná o službu iniciovanou klientem, měl by být začáteční úkon takové služby vykonáván klientem.Pomocí číselníku vyberte pouze jednu možnost. Pokud služba existuje v obou variantách (iniciovaná klientem i vykonávaná z moci úřední), je nutno ji uvést dvakrát.
Subjekt využívající službu
- Tento atribut stanovuje, kdo je dle právního předpisu oprávněný klient, který má nárok na využití služby VS.
- Z číselníku vyberte jednu či více možností:
- fyzická osoba,
- právnická osoba,
- podnikající fyzická osoba.
Právní předpisy
Zadejte příslušný právní předpis nebo více právních předpisů stanovující službu VS a jeho konkrétní části (paragraf, odstavec, písmeno). Pokud je to žádoucí, uvádějte i více částí právního předpisu.
Činnost
Uveďte všechny činnosti dle zákona o základních registrech, které jsou relevantní pro danou službu VS v celém jejím procesu (od zahájení až po ukončení). Přiřazením činnosti je služba VS vázána na konkrétní vnitřní procesy (mj. oprávnění na přístupy k základním registrům a/nebo údajům v jiných agendách) a dochází k předvybrání OVM poskytujících službu. Vazba mezi činností a službou VS je různá – jedné službě VS může odpovídat jedna činnost, ale zpravidla to tak není a služba VS odpovídá několika činnostem, nebo se v rámci jedné činnosti poskytuje více služeb VS.
Orgán veřejné moci
Orgány veřejné moci či kategorie orgánů veřejné moci (dále jen OVM) realizující službu VS se načítají z uvedených činností. Pokud výčet OVM není úplný, další OVM lze přidat doplněním další činnosti ke službě OVM. Naopak okruh OVM je možné zpřesnit jejich odebráním.
Působnost
Atribut slouží pro klasifikaci služeb - zda ji OVM vykonává v působnosti:
státní správa státní správa v přenesené působnosti samospráva
Působnost se určuje prostřednictvím číselníku s výše uvedenými hodnotami. Hodnotu je možno vybrat pro celou službu VS, nebo pro jednotlivé OVM pokud službu vykonávají v různých působnostech (např. vydání eObčanky vykonává Ministerstvo vnitra jako státní správa, ale obce s rozšířenou působností jako státní správa v přenesené působnosti).
Místní příslušnost
Informace, zda je místo poskytování služby VS pro klienta nějakým způsobem omezeno. Vysvětlení jednotlivých možností (typologie vychází ze správního řádu):
- není – klient si může vybrat OVM z dané kategorie (např. požádat o nový občanský průkaz lze na jakémkoli úřadu obce s rozšířenou působností či městské části v Praze).
- Tato možnost platí, pokud je OVM ústřední správní orgán, který nemá územní místně příslušná pracoviště.
- Dále sem patří možnost, kdy právní předpis příslušného OVM omezuje na nejbližší OVM (např. odevzdání občanského průkazu po zemřelém na nejbližším úřadu obce s rozšířenou působností či městské části v Praze).
- dle místa činnosti účastníka – klient musí službu VS vyřizovat u příslušného OVM dle místa, přičemž určující není trvalý pobyt klienta (např. vyřizování svatby se provádí na matričním úřadě podle místa svatby).
- dle místa trvalého pobytu (místa pobytu cizince) fyzické osoby – klient musí službu VS vyřizovat u příslušného OVM dle svého trvalého pobytu (např. podání daňového přiznání z příjmu fyzických osob k finančnímu úřadu příslušnému dle trvalého pobytu).
- dle místa dotčené nemovitosti – klient službu VS vyřizuje u příslušného OVM podle adresy dané nemovitosti (např. návrh na vklad do katastru nemovitostí se provádí na příslušném katastrálním úřadě dle adresy nemovitosti).
- dle sídla právnické osoby – klient službu VS vyřizuje u příslušného OVM podle adresy právnické osoby (např. poplatník daně z příjmů právnických osob je povinen podat přihlášku k registraci k dani u příslušného správce daně dle sídla právnické osoby).
- dle místa podnikání fyzické osoby – klient službu VS vyřizuje u příslušného OVM podle uvedeného místa podnikání dané agendy (např. k žádosti o koncesi k vedení spisovny se vyjadřuje státní oblastní archiv příslušný dle místa podnikání).
Místní příslušnost se může lišit u jednotlivých OVM:
- např. převzetí občanského průkazu do úschovy:
- obecní úřad obce s rozšířenou působností – dle místa činnosti účastníka,
- matriční úřad – dle místa trvalého pobytu (místa pobytu cizince) fyzické osoby.
Dle zvolených subjektů využívajících službu VS se mění možnosti místní příslušnosti. Vyberte jednu možnost pro každý typ subjektu využívajícího službu. Přípustné kombinace přehledně zobrazuje následující tabulka.
fyzická osoba | podnikající fyzická osoba | právnická osoba | |
---|---|---|---|
Není | x | x | x |
Dle místa činnosti účastníka | x | x | x |
Dle místa trvalého pobytu (místa pobytu cizince) fyzické osoby | x | x | |
Dle místa dotčené nemovitosti | x | x | x |
Dle sídla právnické osoby | x | ||
Dle místa podnikání fyzické osoby | x |
Relevantní pro
Každou službu VS je nutné klasifikovat s ohledem na to, jaké všechny informační povinnosti si její evidencí a (v budoucnu) detailním popisem plníte. Vyberete, zda je služba VS relevantní z hlediska Jednotné digitální brány
Na základě nařízení Evropského parlamentu a Rady (EU) 2018/1724 ze dne 2. října 2018, kterým se zřizuje jednotná digitální brána (Single digital gateway – SDG) pro poskytování přístupu k informacím, postupům a k asistenčním službám a službám pro řešení problémů a kterým se mění nařízení (EU) č. 1024/2012 jsou někteří gestoři, jejichž agendy jsou relevantní z hlediska SDG, povinni informovat o těchto službách v anglickém jazyce. Identifikace těchto služeb se provádí skrze tento atribut.
Úkonu
Identifikátor úkonu
Automaticky (stejně jako v případě služby VS) generovaný kód sloužící pro databázové zpracování údajů.
Název úkonu
Podobně jako u služby uvádějte srozumitelný a výstižný název úkonu, aby bylo klientovi jasné, co je účelem úkonu. Název úkonu by měl výstižně popsat konkrétní krok (např. podání žádosti, výzva k doložení/doplnění žádosti, atd.).
Popis úkonu
Pomocí tohoto atributu detailněji vysvětlíte účel úkonu. Obsahem je pouze věcné popsání úkonu.
Právní předpisy
Uveďte odkaz na paragraf a odstavec nebo písmeno právního předpisu, který stanovuje právo či povinnost konat úkon za účelem realizace služby. Můžete uvést více právních předpisů. Pokud je to žádoucí, uvádějte i více částí právního předpisu.
Vykonavatel úkonu
Kdo daný úkon vykonává (a iniciuje) – OVM nebo klient. Pomocí číselníku vyberete pouze jednu možnost.
Fáze úkonu
Pro každý úkon je nutno klasifikovat, jaké je jeho místo v sérii úkonů služby. Z číselníku vyberete: začáteční, prostřední, nebo koncová. Je možno vybrat více hodnot – např. pokud má služba VS pouze jeden úkon, půjde o „začáteční“ a současně i „koncová“.
Úkon je vhodný pro digitalizaci (nutno uvést zdůvodnění, pokud ne)
U každého úkonu je nutné uvádět, zda je či není vhodný k digitalizaci. Z číselníku vyberete jednu možnost (Ano/Ne). Vyberte „Ano“, pokud je možné úkon provádět digitálně nebo plánujete jeho digitalizaci. Jestliže nelze daný úkon provádět digitálně a ani v budoucnu neplánujete jeho digitalizaci, vyberte možnost „Ne“ a do textového pole uveďte důvod, proč digitalizace není možná (např. digitalizace úkonu je příliš ekonomicky náročná; klientela daného úkonu je zanedbatelně malá atd.).
Obslužného kanálu
Typ kanálu
- Jedná se o možnosti, jakými lze vykonat úkon (bez ohledu na vykonavatele úkonu).
- Ze seznamu vyberte jednu nebo více možností podle toho, jakými kanály lze úkon vykonávat, nebo jakými kanály plánujete jeho vykonávání:
- osobně,
- pošta,
- datová schránka,
- Czech POINT,
- uznávaný elektronický podpis (tj. kvalifikovaný elektronický podpis nebo zaručený elektronický podpis založený na kvalifikovaném certifikátu) zaslaný například emailem,
- samoobslužný portál (AIS),
- jiný způsob, pokud tak stanoví právní předpis,
- ostatní formy dálkového přístupu (např. veřejná datová síť, telefonicky atd.).
- Následně pro daný kanál popište zbývající atributy (jsou-li povoleny).
Pomocí tohoto atributu se také eviduje, zda a jakým způsobem mají dle zákona o právu na digitální služby (č. 12/2020 Sb., § 14 odst. 6) úkon poskytovat školy a školská zařízení.
Orgán veřejné moci
Okruh předvybraných OVM vychází z činností přiřazených ke službě VS. Pro každý typ obslužného kanálu se z předvybraných OVM uvádí jen takové OVM, kterému je úkon adresován nebo který úkon vůči klientovi vykonává.
Požadovaná úroveň důvěry
Tento atribut se vztahuje pouze na obslužný kanál samoobslužný portál (AIS), pro další obslužné kanály není relevantní. Vyberte jednu z úrovní záruky definovaných nařízením eIDAS (Nařízení Evropského parlamentu a Rady (EU) č. 910/2014):
- žádná,
- nízká,
- značná (např. identitní prostředek „jméno, heslo, SMS“),
- vysoká (např. eObčanka).
Plánovaný do
Tento atribut vyplňujte v případě, že daný obslužný kanál plánujete zrušit. Jedná se o nepovinný atribut. Uvádějte zde přesný den, měsíc a rok plánovaného zrušení obslužného kanálu.
Plánovaný od
- Pokud v budoucnu plánujete zavedení nového obslužného kanálu (např. nový samoobslužný portál), je nutné uvést den, měsíc a rok jeho plánovaného spuštění.
- Jedná se o povinný atribut.
Detailní popis služeb VS
Na základě konsolidace informačních povinností (zákon o právu na digitální služby, nařízení EU o Jednotné digitální bráně) se přechází k modelu, kdy se popisy služeb VS mohou udržovat aktuální pouze na jednom místě – v ekosystému RPP, odkud následně může kdokoli aktuální informace čerpat, ať už jde o rezortní informační weby, portály OVM (typicky obcí a krajů), nebo třetí stranu.
V rámci detailního popisu budou jednotlivé služby VS doplněny o informace jako:
- kdo o ně může žádat,
- co je potřeba doložit,
- jaký je poplatek,
- kde se vyřizují,
- atd.
Předchozí popis služeb VS realizovaný skrze vybrané „životní situace“ evidované na základě zákona č. 106/1999 Sb., o svobodném přístupu k informacím, a prováděcí vyhlášky č. 442/2006 Sb., kterou se stanoví struktura informací zveřejňovaných o povinném subjektu způsobem umožňujícím dálkový přístup, se od 1. 8. 2020 ruší. Pro orgány veřejné moci je důležitou změnou, že katalog služeb VS je přímo navázán na systém agend v RPP.
Detailní popis služeb VS není součástí této metodiky, bude realizován po ohlášení agendy a bude pro něj vydána zvláštní metodika.
Proč není detailní popis zanášen do AIS RPP Působnostního při registraci agendy?
- Pokud by tvorba detailního popisu jednotlivých služeb VS byla součástí procesu ohlášení agendy, prodloužila by se doba potřebná na ohlášení agendy. Oddělení tvorby detailního popisu služby VS od ohlášení agendy umožní registraci agendy bez ohledu na stav detailních popisů služeb VS, a tím nebude blokována změna ostatních parametrů agendy (které jsou využívány například pro řízení přístupu k základním registrům).
- Očekává se, že požadavek na aktualizaci jednotlivých detailních popisů služeb VS bude vyvolán i z jiných důvodů, než je změna právního předpisu definujícího agendu. V takovém případě nebude třeba přeregistrovat celou agendu, ale postačí pouze aktualizovat příslušný popis služby VS.
V případě jakýchkoli dotazů pište na e-mail: ukonynazadost@mvcr.cz.
Metodický pokyn k řízení záměru IT/ICT
Celý metodický pokyn je ke stažitelný jako samostatný soubor.
Komu je tento materiál určen
Primárně je materiál určen „Digitálním zmocněncům“ ústředních správních úřadů a vedoucím pracovníkům IT:
- Ředitel IT odboru
- Vedoucí IT oddělení
Materiál je ovšem doporučen k seznámení dalším pracovníkům v členění dle pozic/rolí níže:
- Digitální zmocněnec
- Enterprise Architekt, konzultant, analytik
- Manažer kvality (QA)
- Manažer kybernetické bezpečnosti
- Manažer provozu
- Právník
- Projektový manažer
- Rozpočtový specialista
- Vedení úřadu (předseda, státní tajemník, náměstek ekonomické sekce)
- Vlastník agendy/procesu
- Zakázkář
Účel dokumentu
Tento dokument má několik hlavních cílů:
- Sjednotit pohled na IT záměr pojmenováním hlavních procesních resp. pracovních kroků od detekce potřeby změny přes přípravu, realizaci, provoz až po ukončení provozu (tyto kroky lze rovněž pojmenovat „pracovními balíčky“).
- Jasně nastavit pravidla pro vedení závazných centrálních evidencí v jednotlivých krocích vlákna, nezbytných pro řízení Informační koncepce ČR (IKČR) i Informační koncepce ústředního správního úřadu. Zároveň poskytnout informaci o stavu jednotlivých systémů, které zajišťují/budou zajišťovat koordinaci a řízení IKČR/eGovernmentu.
- Vytvořit informační rozcestník vazeb vlákna záměru na hlavní legislativní dokumenty a důležité metodiky.
- Popsat vlákno záměru v kontextu metod řízení Informačních koncepcí ČR/úřadu a v kontextu celkového řízení IT/ICT, ve kterém probíhá současně svazek takových vláken v různých stavech, včetně vazby na další metodické dokumenty (např. „Metody řízení ICT“, normy ITIL a IT4IT atd.).
Základní principy a pojmy
- Klíčovým pojmem pro tento materiál je tzv. „vlákno záměru“. Vláknem záměru nazýváme základní proces konkrétní změny v IT, který je samostatně řiditelný, samostatně rozpočtovaný a definovaný svým výstupem – typicky novým informačním systémem, významnou změnou stávajícího informačního systému, jeho dílčí části, způsobu provozování IS (přechod na cloud), změnou procesů podporovaných informačním systémem apod. Vše co podléhá usnesení vlády č.86/2020 je předmětem záměru, který je dokumentován v katalogu Digitálního Česka.
- Vlákno záměru – logická posloupnost procesních resp. pracovních kroků (činností, aktivit a jejich výstupů) spouští typicky požadavek vedení na změnu IT podpory klientů úřadu (digitální služba), nebo změna podpory vnitřní agendy/procesu úřadu. Vlákno je v praxi často vyvoláno změnou legislativy.
- Pro vlákno platí, že některé kroky pro některé záměry nemusí být relevantní (např. změna legislativy) a některé kroky lze provádět souběžně, ale nelze měnit pořadí kroků.
- Zároveň platí, že následující krok „dědí“ vlastnosti a výstupy kroku předcházejícího. Např. je-li legislativní předpis relevantní pro krok 3, přirozeně se předpokládá jeho relevance pro výstupy kroků 4, 5, 6 atd.
- Celkové řízení digitální transformace/IT je pak cyklický proces (smyčka), zahrnující strategické řízení (řízení informační koncepce), řízení celého svazku všech vláken v různých stavech (různých krocích), podpůrných procesů (řízení zdrojů, kvality, celková kybernetická bezpečnost) a uzavření smyčky zpětné vazby (z měření a hodnocení zpět ke změně koncepce a plánování). Tento cyklus a řízení celkového svazku vláken je v souladu s „Metodami řízení ICT“, vydanými MV ČR viz. diagram v příloze.
Vlákno IT/ICT záměru a jeho „životní“ cyklus
Vlákno záměru v celkovém kontextu evidencí, legislativy a rolí
Vazby vlákna záměru na povinné centrální, a doporučené lokální evidence
V této kapitole jsou popsány povinnosti a doporučení, které se vážou na jednotlivé evidence spojené s řízením vlákna. Většina, nikoli však všechny, jsou uvedené na předchozím schématu.
Popis je proveden v číslovaném seznamu, který je totožný s jednotlivými kroky/etapami cyklu:
- V rámci prvního kroku se úřadům doporučuje zavést jednotnou (strukturovanou) evidenci požadavků na změny v oblasti digitalizace. Evidence by měla detekovat připravované změny v legislativě vč. předpokládaného termínu účinnosti změny. Rovněž by měla zahrnovat vnější požadavky na změny, a to ze zpětné vazby od klientů služeb úřadu (vč. jiných úřadů), i požadavků vyplývajících z povinností dobrého hospodáře (hodnocení efektivity a výkonnosti agend a procesů úřadu), nebo ze změny strategií a koncepčních dokumentů (např. Informační koncepce ČR, Informační koncepce úřadu a dalších obdobných dokumentů). Správcem takové evidence by měl být digitální zmocněnec úřadu, do evidence by měly přispívat všechny organizační složky úřadu a obsah by měl být předmětem jednání vedení úřadu alespoň 1x za čtvrtletí. Doporučuje se rovněž tyto požadavky – pokud z nich již vyplývá záměr změny (byť prozatím částečně nejasný) – přeformulovat do záměru a tento zaevidovat ve formě evidenčního listu záměru v katalogu „Digitální Česko“, ve stavu D - „Námět“. To umožní konzultovat a zpřesňovat záměr s pracovníky „Kompetenčního centra programu Digitální Česko“. Z hlediska struktury popisu záměru postačuje název záměru, nepovinně pak jeho popis a kontaktní osobu.
- Druhým krokem je kvalifikace záměru, převážně, ale nikoli výlučně, uvnitř úřadu. Záměr je v této etapě nutné podrobněji strukturovaně popsat, vč. identifikace spolupracujících úřadů. Záměr získává v katalogu Digitálního Česka stav C – „Koncept“. Kvalifikaci schvaluje obvykle vedení úřadu na návrh digitálního zmocněnce. Kvalifikované záměry (koncepty) již vstupují do implementačních plánů Digitálního Česka, proto je dokumentace záměru ve stavu konceptu (C) v katalogu „Digitální Česko“ povinná. Strukturovaný popis záměru ve stavu konceptu musí minimálně obsahovat tyto údaje:
- Název záměru
- Stručný popis záměru
- Časové rozlišení realizace změny (datum od-do s přesností odhadu na čtvrtletí)
- Cíl „Digitálního Česka“ (více cílů), který záměr plní. Pozn. V rámci návazné interní evidence úřadu je důležité záměr navázat na cíle informační koncepce úřadu, popř. cíle jiných strategických a koncepčních dokumentů.
- Gesční úřad (výčet spolupracujících úřadů, je-li relevantní)
- Odpovědnou a kontaktní osobu
- Odhad celkových externích výdajů na realizaci změny
- Odhad externích výdajů na udržitelnost po dobu provozu (na 4 roky od ukončení realizace)
- Úprava legislativy – krok nemusí být součástí životního cyklu všech záměrů. Je potřeba dodržovat Legislativní pravidla vlády a související Obecné zásady pro hodnocení dopadů (RIA) a postupovat podle Zásad pro tvorbu digitálně přívětivé legislativy.
- Evidence v gesci Legislativní rady vlády
- Pokud je v plánu zpracování nové zákonné normy, musí být záměr zanesen do Plánu legislativních prací vlády, popř. do Výhledu legislativních prací vlády
- Pokud záměr souvisí s implementací Směrnice Evropského parlamentu a Rady (EU), potom má být součástí Přehledu implementačních prací vlády
- Pokud je potřeba vytvořit nebo změnit vyhlášku, je potřeba ji zařadit do Plánu přípravy vyhlášek
- Evidence dopadů změny legislativy v rámci katalogu programu Digitální Česko
- Podle postupu prací aktualizujte a zpřesňujete evidované údaje v Katalogu záměrů, zejména případné změny v termínech realizace.
- Doplňte k záměru úlohu (ticket) RIA a připojte do něj zpracovaný formulář RIA viz https://www.vlada.cz/cz/ppov/lrv/ria/aktualne/vzorove-zpravy-ria-zpracovane-dle-pozadavku-obecnych-zasad-ria-138671/
- Významné milníky z hlediska životního cyklu záměru:
- Schválení návrhu nové legislativy vládou jako vládního návrhu – je možné postoupit k dalším pracím, které jsou spojeny s přípravou investičních výdajů
- Schválení legislativy Parlamentem České republiky a podepsání Prezidentem České republiky – je nutné kontrolovat změny, mezi vládou schváleným návrhem a finálním znění legislativy a zohlednit tyto změny při další realizaci
- Kvalifikace záměru v kontextu IKČR a OHA – příprava podkladů pro rozhodnutí OHA. Tento krok je rovněž závislý na povaze záměru. Zpracování formuláře OHA a získání stanoviska OHA MV se řídí ustanoveními zákona 365/2000 Sb. (viz tabulka v další kapitole). V případě nejasností konzultujte záměr s Odborem hlavního architekta MV ČR. Zpracované formuláře v současnosti nemají vazbu na evidenci záměru v katalogu Digitální Česko, nicméně se do budoucna počítá s elektronizací formulářů OHA a integrací obou evidencí.
- Alokace finančních zdrojů pro záměr (rozpočet vs. ESF fondy, provozní vs. investiční výdaje), ohlášení vládě. V tomto kroku je nutné znát způsob financování záměru (rozpočtová kapitola, ESF+nezpůsobilé výdaje v rozpočtu, nadpožadavky..). Z hlediska evidence v katalogu DČ je důležité znát nejen realizační výdaje, ale rovněž výdaje na udržitelnost záměru, pracnost realizace (interní) a pracnost udržitelnosti (interní). Z těchto podkladů lze poté kalkulovat celkové náklady na vlastnictví (TCO). Nutnou součástí evidence je formulář ohlášení záměru učinit výdaj dle usnesení vlády č.86/2020. Formulář lze vygenerovat jako úlohu v katalogu DČ.
- Příprava realizace (další nutná stanoviska, veřejná soutěž). V tomto kroku dominuje většinou příprava zadávací dokumentace dle ZVZ. Důležitou součástí mohou být analýzy a stanoviska týkající se kybernetické bezpečnosti záměru jako celku a podklady pro rozhodnutí o realizaci záměru v Cloudu nebo On Premise.
- Realizace záměru (projektové řízení realizace). Pro všechny záměry evidované v evidenci DČ záměry je nezbytné jmenovat odpovědnou osobu za realizaci a doporučuje se aplikace standardní metodiky řízení projektu v souladu s mezinárodními standardy (PMI, PRINCE2).
- Ukončením realizace se uzavírá hlavní implementační část záměru, ve které musí proběhnout především předem stanovené akceptační testy. Akceptační testy nesmí být pouhou formalitou, ale musí otestovat skutečnou funkčnost výstupu záměru, který bude věcný správce přebírat. S ukončením realizace souvisí také dopracování dokumentace, předání výsledků projektu do provozu, převzetí realizovaného záměru od projektového týmu provozním týmem. Viz doporučení ITIL procesní blok č. 3.Vždy by měly obsahovat:
- Název akceptačního testu
- Popis akceptačního testu
- Soubor kroků a milníků akceptačního testu s očekávaným vstupem a výstupem
- Zodpovědnou osobu za akceptaci
- V tomto kroku je nutné dopracovat provozní dokumentaci, a to dle požadavků zákona 365/2000 Sb. a vyhlášky 529/2006 Sb. https://www.zakonyprolidi.cz/cs/2006-529#f3147008 a nastavit odpovědnosti za provozní činnosti (procesy). V této etapě se také začínají sledovat stanovená SLA, KPI a další ukazatele, které hodnotí, zda výstup záměru pracuje tak, jak bylo navrženo a odsouhlaseno akceptačními testy. Viz. ITIL procesní blok č. 4.
- Provoz, provozní dohled, realizace drobných změn a provozní podpora. Pro provoz je doporučením řídit se standardy ITIL (řízení kontinuity, konfigurací, incidentů, problémů atd.)
- Hodnocení provozu. Součástí hodnocení provozu by měla být hodnotící zpráva.
- Ukončení životního cyklu a vyřazení. Důležité je zejména vyřazení z evidence ISVS v RPP.
Vazby kroků řízení vlákna záměru k základní legislativě a metodikám
Relevance dokumentu ke kroku vlákna je označena křížkem, následující kroky tuto relevanci dědí:
Název předpisu | Odkaz (hyperlink) | 01. Detekce potřeb a úvodní formulace záměru (nový systém, velká změna) | 02. Kvalifikace záměru uvnitř ÚSÚ/OVM (dle IK OVM) vč. posouzení legislativní shody | 03. Analýza dopadů (RIA) a změna legislativy | 04. Kvalifikace záměru v kontextu IKČR a OHA | 05. Alokace finančních zdrojů pro záměr (rozpočet vs ESF fondy), ohlášení vládě | 06. Příprava realizace (další nutná stanoviska, veřejná soutěž) | 07. Realizace záměru (projektové řízení realizace) | 08. Ukončení realizace, vyhodnocení (akceptační test) | 09. Plánování provozu vč. drobných změn a zahájení provozu | 10. Provoz, provozní dohled, realizace drobných změn a provozní podpora | 11. Hodnocení provozu | 12. Ukončení životního cyklu a vyřazení |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Informační koncepce ČR | https://archi.gov.cz/ikcr-dokument:ikcr | X | X | X | |||||||||
Informační koncepce úřadu | X | X | X | X | |||||||||
Metodika Programu Digitální Česko | https://www.mvcr.cz/webpm/soubor/metodika-r-i-zeni-programu-digitalni-cesko.aspx | X | X | X | X | X | x | X | X | X | |||
Metody řízení ICT veřejné správy | https://archi.gov.cz/metody-dokument:metody | x | X | X | X | X | X | X | |||||
Národní architektonický plán | https://archi.gov.cz/nap-dokument:nap | X | X | X | |||||||||
Strategické a metodické dokumenty vztahujcí se ke konkrétní detekované potřebě | https://www.databaze-strategie.cz/ | X | X | X | X | X | X | X | X | ||||
Usnesení vlády ČR č. 86/2020 o uložení povinností informovat vládu v souvislosti s výdaji v oblasti informačních a komunikačních technologií | https://www.mvcr.cz/soubor/usneseni-vlady-c-86-2020-sb-ze-dne-27-ledna-2020.aspx | X | X | ||||||||||
Vyhláška č. 323/2002 Sb., o rozpočtové skladbě | https://www.zakonyprolidi.cz/cs/2002-323 | X | |||||||||||
Zákon. 250/2017 O elektronické identifikaci | https://www.zakonyprolidi.cz/cs/2017-250 | X | X | X | X | X | X | ||||||
Zákon 110/2019 O zpracování osobních údajů | https://www.zakonyprolidi.cz/cs/2019-110 | X | X | X | X | X | X | X | |||||
Zákon 111/2009 O základních registrech.. | https://www.zakonyprolidi.cz/cs/2009-111 | X | X | X | X | X | X | ||||||
Zákon 12/2020 o právu na digitální služby | https://www.zakonyprolidi.cz/cs/2020-12 | X | X | X | X | X | X | ||||||
Zákon 181/2014 O kybernetické bezpečnosti | https://www.zakonyprolidi.cz/cs/2014-181 | X | X | X | X | X | X | X | X | ||||
Zákon 218/2000 Sb. o rozpočtových pravidlech | https://www.zakonyprolidi.cz/cs/2000-218 | X | X | X | |||||||||
Zákon 297/2016 O službách vytvářejících důvěru | https://www.zakonyprolidi.cz/cs/2016-297 | X | X | X | X | X | X | ||||||
Zákon 300/2008 O elektronických úkonech a datové konverzi | https://www.zakonyprolidi.cz/cs/2008-300 | X | X | X | X | ||||||||
Zákon 365/2000 Sb. o informačních systémech veřejné správy | https://www.zakonyprolidi.cz/cs/2000-365 | X | X | X | X | X | X | X | X | X | |||
Zákon 499/2004 O. archivnictví a spisové službě | https://www.zakonyprolidi.cz/cs/2004-499 | X | X | X | X | X | X | ||||||
Zákony a vyhlášky vážící se k detekované potřebě | X | X | X | X | X | X | X | X | X | X | X |
Zapojení rolí do jednotlivých kroků vlákna
„Povinné“ zapojení je označeno „P“, doporučené zapojení je označeno „D“:
01. Detekce potřeb a úvodní formulace záměru (nový systém, velká změna) | 02. Kvalifikace záměru uvnitř ÚSÚ/OVM (dle IK OVM) vč. posouzení legislativní shody | 03. Analýza dopadů (RIA) a změna legislativy | 04. Kvalifikace záměru v kontextu IKČR a OHA | 05. Alokace finančních zdrojů pro záměr (rozpočet vs ESF fondy), ohlášení vládě | 06. Příprava realizace (další nutná stanoviska, veřejná soutěž) | 07. Realizace záměru (projektové řízení realizace) | 08. Ukončení realizace, vyhodnocení (akceptační test) | 09. Plánování provozu vč. drobných změn a zahájení provozu | 10. Provoz, provozní dohled, realizace drobných změn a provozní podpora | 11. Hodnocení provozu | 12. Ukončení životního cyklu a vyřazení | |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Digitální zmocněnec | P | P | P | P | P | D | D | P | D | D | D | P |
Projektový manažer | D | P | P | P | D | |||||||
Manažer provozu (technický správce) | D | D | P | P | P | P | ||||||
Enterprise Architekt, konzultant, analytik | D | D | P | P | D | P | D | D | D | D | ||
Manažer kvality (QA) | D | D | D | D | D | P | D | P | P | D | P | D |
Manažer kybernetické bezpečnosti | D | P | D | P | P | D | P | P | D | P | ||
Právník | P | D | P | P | D | |||||||
Rozpočtový specialista | D | P | D | D | ||||||||
Ředitel IT odboru, Vednoucí IT oddělení | D | P | D | P | P | D | D | P | P | D | P | |
Vedení úřadu | P | P | D | P | P | D | ||||||
Vlastník agendy/procesu (věcný správce) | P | P | P | P | P | D | D | |||||
Zakázkář | D | P | D | P | D |
Přehled a kontrolní seznam (checklist) pro řízení vlákna
Check list je ke stažení v klasickém dokumentu Check list
Tento check-list shrnuje jednotlivé pracovní balíčky definované v „životním cyklu záměru ICT“. Ačkoliv jsou jednotlivé balíčky očíslované a seřazeny tak, aby byla zřejmá jejich souslednost, nemusí každý ICT záměr splnit každý pracovní balíček. Důležité je pouze je projít a zajistit všechny potřebné výstupy a vstupy, pokud jsou pro daný ICT záměr relevantní.
Název pracovního balíčku | Vstupy | Výstupy | Zpracováno v rámci záměru? | |||
---|---|---|---|---|---|---|
Povinné | Nepovinné | Povinné | Nepovinné | Volný text | Check-list | |
01. Detekce potřeb a úvodní formulace záměru (nový systém, velká změna) | - Informační koncepce ČR - Záměr v katalogu DČ | - Požadavky vedení úřadu | - Změna záměru v katalogu DČ | Zavedení do interní databáze záměrů | https://spcss.archirepo.com\\ /digitalnicesko/webapp/object/id-el-219fab6c-14be-4ab9-9873-0d4d51a7b0f6 | ☐Záměr zadán do katalogu digitálního Česka ☐Zmapovány potřeby (sběr požadavků) |
02. Kvalifikace záměru uvnitř ÚSÚ/OVM (dle IK OVM) | - Informační koncepce úřadu - Záměr v katalogu DČ - Evidence RPP – agendy, ISVS, oprávnění | - Změna záměru v katalogu DČ - Potřebné úpravy evidence RPP – agendy, ISVS, oprávnění | Změna v interní databázi záměrů | ☐Záměr aktualizován v katalogu digitálního Česka ☐Soulad s Informační koncepcí úřadu ☐Soulad s informacemi v RPP ☐Soulad s rejstříkem ISVS ☐Přehled dopadů pro nelegislativní materiály |
||
03. Úprava legislativy | - Analýza legislativního prostředí pro záměr - Dopady změn legislativy - Metodika RIA a Zásady digitálně přívětivé legislativy | - Důvod změny či zachování legislativy - Potřebné úpravy evidence RPP – agendy, ISVS, oprávnění - Výsledky dopadové analýzy (RIA) - Návrh změn legislativy | ☐RIA (formulář úlohy katalogu DĆ) ☐Upravená legislativa ☐Úpravy informací v RPP |
|||
04. Kvalifikace záměru v kontextu IKČR a OHA | - Informační koncepce ČR a její navazující dokumenty - Formuláře OHA | - Schválený formulář OHA - Potřebné úpravy evidence RPP – agendy, ISVS, oprávnění | ☐Soulad s informační koncepcí ČR ☐Vyplněný formulář OHA ☐Schválený formulář OHA ☐Úpravy informací v RPP ☐Úpravy informací v rejstříku ISVS |
|||
05. Alokace finančních zdrojů pro záměr (rozpočet vs. ESF fondy), ohlášení vládě | - Informace na vládu - Rozpočtové systémy úřadu | - Struktury ESIF | - Vzetí na vědomí vládou ČR - Změna záměru v katalogu DČ - Kalkulace 5ti letého TCO (celkové náklady na vlastnictví) | Studie proveditelnosti | ☐Záměr aktualizován v katalogu digitálního Česka ☐Zajištěné financování ☐Informace dle ÚV86 – úloha v katalogu DČ |
|
06. Příprava realizace (další nutná stanoviska, veřejná soutěž) | - Schválený formulář OHA - Žádosti o vyjádření dotčených subjektů - Dokumenty k zadávacímu řízení | - Studie proveditelnosti | - Schválení realizace dotčenými subjekty - Evidence v NEN - Zadávací dokumentace - Ukončení zadávacího řízení - Změna záměru v katalogu DČ | ☐Zakázka zveřejněna v NEN ☐Vytvořená zadávací dokumentace ☐Záměr aktualizován v katalogu digitálního Česka ☐Realizační report 10-20 % plnění (úloha v katalogu DČ) |
||
07. Realizace záměru (projektové řízení realizace) | - Projektový tým - Metody řízení ICT | - Sestavený tým – dodavatel + zadavatel - Změna záměru v katalogu DČ | ☐Záměr aktualizován v katalogu digitálního Česka ☐Realizační report 20-90% plnění (úloha v katalogu DČ) |
|||
08. Ukončení realizace, vyhodnocení (akceptační test) | - Dokumentace systému - Provozní smlouva - Změna záměru v katalogu DČ | ☐Realizační report = 100% (úloha v katalogu DČ) ☐Akceptační testy ☐Provozní dokumentace ☐Smlouva o provozu a podpoře |
||||
09. Plánování provozu vč. drobných změn a zahájení provozu | - Dokumentace systému - Provozní smlouva | - Plán změn | ||||
10. Provoz, provozní dohled, realizace drobných změn a provozní podpora | - Dokumentace systému - Provozní smlouva - Plán změn | |||||
11. Hodnocení provozu | - Dokumentace systému - Provozní smlouva - Plán změn | - Hodnocení provozu | ||||
12. Ukončení životního cyklu a vyřazení | - Hodnocení provozu | - Zpětné poučení z realizace záměru |
Přílohy
Vlákno v kontextu řízení informačních koncepcí ČR a úřadu
Vlákno v kontextu celkového řízení IT/ICT úřadu
Vlákno záměru v kontextu metodik ITIL a IT4IT
Co je a co není ISVS
Úvod
Zákon č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů (dále jen „zákon o ISVS“) stanoví práva a povinnosti, které souvisejí s vytvářením, užíváním, provozem a rozvojem informačních systémů veřejné správy (dále jen „ISVS“). Se správou ISVS jsou spojeny některé významné povinnosti, např. povinnost vytvářet informační koncepci orgánu veřejné správy, řídit se Informační koncepcí České republiky a jejích navazujících dokumentů, ucházet se o stanovisko MV (OHA) k projektu ISVS nebo povinnosti podle zákona č. 181/2014 Sb., o kybernetické bezpečnosti. Vzhledem k zákonem uloženým povinnostem, které se vztahují na každý ISVS, resp. jeho správu, jsou orgány veřejné správy postaveny před zásadní úkol identifikovat informační systémy, které jsou ISVS, u kterých vykonávají úlohu správce ve smyslu zákona o ISVS.
Předmět tohoto materiálu
Dosavadní praxe ukazuje, že ne vždy je pro orgány veřejné správy snadné určit, které ze spravovaných informačních systémů jsou ISVS či nikoliv, popř. do jaké kategorie spadají. Na potřebu rozlišovat jednotlivé druhy informačních systémů mohou orgány veřejné správy narazit právě při zpracování informační koncepce, tj. dokumentu, v němž mají být uvedeny dlouhodobé cíle v oblasti řízení kvality a bezpečnosti spravovaných ISVS, obecné principy pořizování, vytváření a provozování ISVS. V informační koncepci má být také uvedena charakteristika každého ISVS, který orgán veřejné správy spravuje; ke každému ISVS musí vést orgán veřejné správy provozní dokumentaci1). Orgán veřejné správy má dále povinnost předávat údaje o spravovaných ISVS do příslušné části základního registru práv a povinností (RPP), která nahradila někdejší informační systém o informačních systémech veřejné správy, tj. do tzv. rejstříku ISVS (dále jen „RISVS“). Správcem tohoto základního registru je Ministerstvo vnitra.
Zpracování informační koncepce a předání údajů do RPP jsou nezbytnými podmínkami pro provedení atestace dlouhodobého řízení ISVS.
Určení, které ze spravovaných informačních systémů jsou ISVS, popř. do jaké kategorie spadají, je tedy nezbytné zejména s ohledem na naplňování povinností stanovených zákonem o ISVS.
Seznam použitých právních předpisů
Zákon č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů.
Zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů
Zákon č. 181/2014 Sb., o kybernetické bezpečnosti, ve znění pozdějších předpisů
Zákon č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů, ve znění pozdějších předpisů.
Vyhláška č. 529/2006 Sb., o požadavcích na strukturu a obsah informační koncepce a provozní dokumentace a o požadavcích na řízení bezpečnosti a kvality informačních systémů veřejné správy (vyhláška o dlouhodobém řízení informačních systémů veřejné správy).
Vyhláška č. 530/2006 Sb., o postupech atestačních středisek při posuzování dlouhodobého řízení informačních systémů veřejné správy.
Vyhláška č. 53/2007 Sb., o technických a funkčních náležitostech uskutečňování vazeb mezi informačními systémy veřejné správy prostřednictvím referenčního rozhraní (vyhláška o referenčním rozhraní).
Slovník použitých pojmů a zkratek
Použité pojmy
Informační systém – funkční celek nebo jeho část zabezpečující cílevědomou a systematickou informační činnost. Každý informační systém zahrnuje data, která jsou uspořádána tak, aby bylo možné jejich zpracování a zpřístupnění, a dále nástroje umožňující výkon informačních činností
Informační systémy veřejné správy - funkční celek nebo jeho část zabezpečující cílevědomou a systematickou informační činnost pro účely výkonu veřejné správy - § 2 písm. b) zákona o ISVS.
Informační koncepce České republiky – vytváří MV a schvaluje Vláda ČR, stanoví cíle České republiky v oblasti informačních systémů veřejné správy a obecné principy pořizování, vytváření, správy a provozování informačních systémů veřejné správy v České republice na období 5 let - § 5a odst. 1 zákona o ISVS.
Navazující dokumenty Informační koncepce České republiky – návazné dokumenty dle usnesení vlády ČR ze dne 3. října 2018, č. 629, které rozvíjí principy a cíle Informační koncepce České republiky, tj. Metody řízení ICT veřejné správy ČR, Slovník pojmů eGovernmentu, Národní architektonický rámec a Národní architektonický plán (zveřejněno na internetové stránce https://archi.gov.cz).
Informační koncepce orgánu veřejné správy – v této informační koncepci orgány veřejné správy stanoví své dlouhodobé cíle v oblasti řízení kvality a bezpečnosti spravovaných informačních systémů veřejné správy a vymezí obecné principy pořizování, vytváření, správy a provozování svých informačních systémů veřejné správy – viz § 5a odst. 2 zákona o ISVS.
Orgán veřejné správy – státní orgány (např. ministerstva, jiné správní úřady) a územní samosprávné celky – viz § 1 odst. 1 zákona o ISVS.
Provozní dokumentace – dokumentace ISVS, která popisuje funkční a technické vlastnosti informačního systému a blíže rozpracovává oprávnění a povinnosti jeho správce, provozovatele a uživatele – viz § 2 písm. s) zákona o ISVS.
Provozní informační systém - informační systém zajišťující informační činnosti nutné pro vnitřní provoz příslušného orgánu, například účetnictví, správu majetku nebo elektronickou poštu– viz § 2 písm. p) zákona o ISVS.
Referenční rozhraní – souhrn právních, technických, organizačních a jiných opatření vytvářejících jednotné integrační prostředí informačních systémů veřejné správy, které poskytuje kvalitní soustavu společných služeb informačních systémů veřejné správy, včetně služeb výměny oprávněně vyžadovaných informací mezi jednotlivými informačními systémy, a to i se systémy mimo Českou republiku – viz § 2 písm. h) zákona o ISVS.
Vazba mezi informačními systémy veřejné správy – vzájemné nebo jednostranné poskytování služeb informačních systémů veřejné správy, například sdílení dat – viz § 2 písm. o) zákona o ISVS; pro účely tohoto metodického pokynu automatizované, vzájemné nebo jednostranné poskytování služby mezi ISVS různých správců ISVS.
Webová služba (web service) – skupina technologií a metod, které spojují informační systémy prostřednictvím internetu a umožňují jim spolu efektivně komunikovat a vyměňovat si informace.
Použité zkratky
ISVS – informační systém (systémy) veřejné správy.
Informační systémy veřejné správy
Jak určit ISVS
Předpokladem toho, aby určitý informační systém mohl být označen za ISVS, je především naplnění materiálních znaků ISVS, tedy faktický stav, kdy předmětný informační systém splňuje definiční znaky ISVS stanovené zákonem o ISVS. Absence formálního označení informačního systému za ISVS nehraje při určování typu informačního systému roli, byť, jak bude zmíněno níže, je řada informačních systémů veřejné správy v příslušných zákonech výslovně označena za informační systémy veřejné správy.
ISVS v zákoně o ISVS
V souladu s § 2 písm. b) zákona o ISVS je ISVS funkční celek nebo jeho část zabezpečující cílevědomou a systematickou informační činnost pro účely výkonu veřejné správy. Jsou jimi i informační systémy zajišťující činnosti podle zvláštních zákonů. Pro určení, zda konkrétní informační systém je zároveň ISVS, je nutné posoudit vztah tohoto informačního systému k výkonu veřejné správy. V této souvislosti je nezbytné vymezit pojem veřejná správa.
Veřejnou správu můžeme charakterizovat jako správu veřejných záležitostí, která sleduje naplňování veřejných cílů a je vykonávána ve veřejném zájmu (je to tedy protipól správy soukromé, kterou vykonává každá fyzická nebo právnická osoba, jež naopak sleduje soukromé cíle, a to ve svém soukromém zájmu).
Veřejnou správu lze pojímat ve dvou směrech, a to jako určitou veřejnou činnost (tzv. funkční pojetí veřejné správy) a dále jako soustavu orgánů (subjektů), které tuto činnost vykonávají (tzv. organizační či institucionální pojetí veřejné správy).
Pro účely vymezení obsahu pojmu veřejná správa ve vztahu k ISVS podle zákona
o ISVS je rozhodné pojetí funkční, podle něhož představuje veřejná správa veřejně prospěšnou činnost, která sleduje naplnění určitého veřejného (státního, obecního atd.) zájmu.
Forma činnosti veřejné správy může mít podobu tzv. vrchnostenské (výsostné) veřejné správy. V tomto případě jde o činnost nařizovací (autoritativní), která má povahu veřejné moci2), kdy orgán veřejné moci (např. orgán obce) zasahuje do právních poměrů jiných osob (fyzických nebo právnických). Pro vrchnostenskou veřejnou správu je typická existence vztahů nadřízenosti a podřízenosti, ve kterých orgán veřejné správy vždy stojí výše nad tou osobou, o jejichž právech nebo povinnostech rozhoduje. Klasickým výsledkem vrchnostenské veřejné správy jsou správní rozhodnutí vydaná ve správním řízení3), ale i další úkony správních orgánů, které zasahují do práv a povinností adresátů veřejné správy (např. různá osvědčení, veřejnoprávní smlouvy, opatření obecné povahy, apod.).
Veřejná správa však může mít i další formu činnosti, která spočívá v zajišťování určitých veřejných potřeb. V případě této pečovatelské či obhospodařovací činnosti mluvíme o nevrchnostenské (nevýsostné, fiskální) veřejné správě, pro níž jsou naopak typické rovnoprávné vztahy mezi orgány veřejné správy a jejími adresáty (jde např. o správu státního či obecního majetku). Při nevrchnostenské veřejné správě vstupují orgány veřejné správy do soukromoprávních vztahů (např. občansko-právních).
Kategorie ISVS
Zákon o ISVS samotný popisuje toliko jedinou kategorii ISVS, a sice provozní ISVS (§ 2 písm. t) zákona ISVS), zbývající ISVS zvláště nepojmenovává ani nečlení. Toto členění zavádí až zákon o základních registrech, který rozlišuje základní registry (§ 2 písm. a) zákona ZR), tj. čtveřici specifických informačních systémů veřejné správy, které samy neslouží k výkonu konkrétních činností veřejné správy, nýbrž představují zdroj závazných informací pro tyto činnosti, dále agendové informační systémy, které slouží k výkonu konkrétních činností veřejné správy (§ 2 písm. f) zákona o ZR a konečně tzv. informační systém základních registrů jakožto svébytný informační systém veřejné správy mající jakožto součást tzv. referenčního rozhraní kategorii komunikačního uzlu (§ 2 písm. g) zákona o ZR).
ISVS a jejich úprava v právních předpisech
Skutečnost, že nějaký informační systém je ISVS, nemusí zákon výslovně stanovit, neboť je popsán materiálními (faktickými) znaky (§ 2 písm. b) zákona o ISVS). Přesto některé zákony stanovují, že konkrétní informační systém je ISVS.
Na druhou stranu však může být ISVS takový informační systém, který sice nesouvisí s výkonem veřejné správy, avšak je zákonem za ISVS výslovně prohlášen.
Pro jednoznačné určení ISVS je nejjednodušší situace v případech, kdy právní předpis upravuje vedení ISVS (který splňuje znaky ISVS uvedené v § 2 písm. b) zákona o ISVS), výslovně jej takto označuje, případně s odkazem na zákon o ISVS. Není tomu tak však ve všech případech.
Následující příklady dokumentují, jakými způsoby právní předpisy upravují vedení ISVS:
- Právní předpis upravuje vedení konkrétního informačního systému, zároveň jej jako ISVS označuje a odkazuje na zákon o ISVS:
Například zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, v § 14 odst. 1 stanoví:
„(1) Informační systém datových schránek je informačním systémem veřejné správy, který obsahuje informace o datových schránkách a jejich uživatelích.“
Poznámka pod čarou č. 4:
Zákon č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů.“
- Právní předpis upravuje vedení konkrétního registru (evidence, rejstříku apod.), tj. v názvu není pojem „informační systém“, nebo „systém“; právní předpis registr, evidenci, rejstřík jako ISVS označuje a odkazuje na zákon o ISVS:
Například zákon č. 455/1991 Sb., o živnostenském podnikání (živnostenský zákon), v § 60 odst. 1 stanoví:
„(1) Živnostenský rejstřík je informačním systémem veřejné správy38d) vedeným v elektronické podobě….Správcem živnostenského rejstříku je Živnostenský úřad České republiky.“
Poznámka pod čarou č. 38d:
Zákon č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů“
- Právní předpis upravuje vedení konkrétního informačního systému, registru, evidence, rejstříku, seznamu, databáze, portálu apod., označuje jej jako ISVS, na zákon o ISVS neodkazuje.
Například zákon č. 182/2006 Sb., o úpadku a způsobech jeho řešení (insolvenční zákon), v § 419 odst. 1 stanoví:
„(1) Insolvenční rejstřík je informačním systémem veřejné správy, jehož správcem je Ministerstvo spravedlnosti (dále jen „ministerstvo“).“
- Právní předpis upravuje vedení ISVS, ale jako ISVS jej výslovně neoznačuje.
Např. zákon č. 311/2006 Sb., o pohonných hmotách a čerpacích stanicích pohonných hmot a o změně některých souvisejících zákonů (zákon o pohonných hmotách)v § 6 odst. 1 stanoví:
„(1) Ministerstvo vede evidenci čerpacích stanic a výdejních jednotek…..“
Některé informační systémy veřejné správy jsou v praxi označovány názvem, který v právním předpisu uveden není. Příkladem je administrativní registr ekonomických subjektů (obsah uveden v § 7 odst. 1 a 2 zákona č. 304/2013 Sb., o veřejných rejstřících právnických a fyzických osob) nebo tzv. jednotný identitní prostor – katalog autentizačních a autorizačních služeb (JIP/KAAS), který je v § 56a odst. 1 zákona o ZR označen jako autentizační informační systém.
ISVS bez úpravy v právních předpisech
Vedení ISVS nemusí být výslovně upraveno zvláštním právním předpisem (tedy právním předpisem odlišným od zákona o ISVS), resp. existenci ISVS žádný právní předpis nemusí výslovně zmiňovat.
Například obce podle zákona č. 565/1990 Sb., o místních poplatcích, vybírají místní poplatky, např. od držitelů psů. V souvislosti s touto činnosti řada obcí (resp. obecní úřady jakožto správci místních poplatků) vede jako informační systém evidenci držitelů psů, jako plátců místního poplatku. Tento informační systém je ISVS, a je vedený z rozhodnutí daného orgánu veřejné správy na podporu jím prováděné správní činnosti, tj. slouží pro výkon veřejné správy.
Evidence ISVS v rejstříku ISVS v RPP
Je třeba zdůraznit, že ISVS bez zaevidování v RISVS pro potřeby řízení eGovernmentu fakticky neexistuje a není možné, aby plnil svoji úlohu v rámci propojeného datového fondu VS a aby podporoval poskytování digitální služby příslušné agendy VS. Evidenci v RISVS a vyplnění příslušného identifikátoru OHA vyžaduje v rámci žádosti o stanovisko OHA.
Co není kritériem pro určování ISVS
Dostupnost
Na příkladech uvedených v předchozí kapitole je možné demonstrovat, že rozhodující pro určení ISVS není skutečnost, zda se jedná o veřejný nebo neveřejný informační systém, popř. zda je tato vlastnost v právním předpisu výslovně uvedena. Například evidence Rejstříku trestů, není veřejným informačním systémem, insolvenční rejstřík nebo živnostenský rejstřík jsou veřejně přístupné s určitými omezeními, katastr nemovitostí je veřejným informačním systémem, přesto jsou všechny ISVS. Míra zveřejnění údajů tedy není kritériem pro určování toho, zda se jedná o ISVS.
Outsourcing
Kritériem pro určování ISVS není ani to, zda je tento systém provozován přímo úřadem (orgánem veřejné správy) nebo jiným, třeba i komerčním subjektem, například s využitím outsourcingu.
V některých případech právní předpisy určitou formu outsourcingu připouštějí, a to například slovy „vedením ISVS může (daný orgán veřejné správy) pověřit právnickou osobu“, případně „jím zřízenou právnickou osobu“ [viz § 2 písm. d) zákona o ISVS], v jiných se o takové možnosti nezmiňují, a přesto se tak děje.
V dalších případech zákon přímo stanoví provozovatele, například zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů v § 14 odst. 2 stanoví:
„(2) Správcem informačního systému datových schránek je ministerstvo. Provozovatelem informačního systému datových schránek je držitel poštovní licence.“
Zákon č. 13/1997 Sb., o pozemních komunikacích:
„§ 22a odst. (1) Provoz systému elektronického mýtného a výběr mýtného zajišťuje Ministerstvo dopravy. Ministerstvo dopravy může pověřit provozem systému elektronického mýtného a výběrem mýtného organizaci zřízenou Ministerstvem dopravy nebo právnickou osobu, u níž funkci zakladatele vykonává jménem státu Ministerstvo dopravy, (dále jen "provozovatel systému elektronického mýtného") na základě souhlasu vlády.
§ 22b odst. (2) Ministerstvo dopravy a provozovatel systému elektronického mýtného spolupracují při provozování systému a výběru elektronického mýtného s Policií České republiky. Za tím účelem vytvoří provozovatel systému elektronického mýtného především na síti dálnic organizační a technické předpoklady pro dohled na bezpečnost a plynulost silničního provozu, monitorování a vyhodnocování dopravní situace.
Kdy se zákon o ISVS neuplatní?
Zákon o ISVS se neuplatní v případě, není-li určitý informační systém informačním systémem veřejné správy. Např. operační systém, webový prohlížeč, textový a tabulkový editor nejsou samy o sobě ISVS.
Zákon o ISVS se také neuplatní v případě, je-li v něm výslovně stanovena výjimka. Přestože jsou provozní informační systémy podle § 2 písm. t) zákona o ISVS považovány také za informační systémy veřejné správy, zákon o ISVS je podle svého § 1 odst. 4 ze své působnosti výslovně vylučuje. Z této výluky jsou ovšem vyňaty některé provozní informační systémy, na ty se zákon o ISVS vztahuje, jak bude pojednáno níže.
Zákon o ISVS se také neuplatní v případě, je-li v něm výslovně stanovena výjimka pro některé orgány nebo některé jejich působnosti. Např. § 1 odst. 2 zákona o ISVS zcela vylučuje z působnosti tohoto zákona např. systémy spravované zpravodajskými službami nebo Národním úřadem pro kybernetickou a informační bezpečnost, § 1 odst. 3 zákona o ISVS vylučuje z působnosti tohoto zákona např. systémy spravované bezpečnostními sbory, výjimka se nicméně v tomto případě neuplatní u vazeb takových informačních systémů na jiné informační systémy.
Pomůcka pro určování ISVS
Při posuzování, zda konkrétní informační systém je ISVS či nikoli, je možné si pomoci následujícími otázkami:
- Bylo by nefunkčností informačního systému bezprostředně narušeno nebo ohroženo plnění povinnosti vyplývající z kompetencí daného orgánu veřejné správy?
- Jsou v informačním systému uloženy údaje o vykonávané správní činnosti nebo údaje pro podporu výkonu u této činnosti?
Pokud jsou odpovědi na tyto otázky ANO, s největší pravděpodobností se v případě posuzovaného informačního systému jedná o ISVS.
Vždy však bude ISVS takový informační systém, který je za něj zákonem výslovně prohlášen, byť by nesplňoval znaky ISVS podle § 2 písm. b) zákona o ISVS.
V případě, že vyhodnotíte vámi spravovaný informační systém jako ISVS, musíte dále zjistit, do jaké míry se na vás zákon o ISVS vztahuje. Ten v § 1 stanoví, na které ISVS se tento zákon nevztahuje, resp. vztahuje ve stanoveném rozsahu.
Příklady ISVS
Ministerstvo vnitra je správcem například následujících ISVS:
Podle zákona č. 111/2009 Sb., o základních registrech
- Základní registr obyvatel
- Základní registr agend, orgánů veřejné moci, soukromoprávních uživatelů údajů a některých práv a povinností
podle zákona č. 133/2000 Sb., o evidenci obyvatel a rodných číslech a o změně některých zákonů (zákon o evidenci obyvatel)
- informační systém evidence obyvatel,
- registr rodných čísel – ISVS, který je samostatnou funkční částí informačního systému evidence obyvatel.
podle zákona č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů
- informační systém, jehož prostřednictvím je zajišťován výkon působnosti kontaktních míst veřejné správy (CzechPOINT),
- portál veřejné správy,
V případě obcí jsou ISVS například
- evidence plátců místních poplatků podle zákona č. 565/1990 Sb., o místních poplatcích,
ISVS v informační koncepci
Orgán veřejné správy má ve své informační koncepci podle zákona stanovit své dlouhodobé cíle v oblasti řízení kvality a bezpečnosti spravovaných ISVS a vymezit obecné principy pořizování, vytváření a provozování ISVS. Vyhláška č. 529/2006 Sb., o dlouhodobém řízení informačních systémů veřejné správy, pak dále upravuje povinnost orgánu veřejné správy v informační koncepci charakterizovat všechny své ISVS, jejichž je správcem. Informační koncepce se vytváří pro celý orgán veřejné správy, nikoliv pro jednotlivé ISVS.
Úplná struktura informační koncepce a příklady informačních koncepcí jsou dostupné z https://archi.gov.cz/znalostni-baze:znalostni_baze .
Správce, provozovatel a uživatel
Informační koncepci zpracovává orgán veřejné správy vždy s ohledem na ty ISVS, u nichž je správcem, (§ 2 písm. c) zákona o ISVS), tyto ISVS do své informační koncepce zahrne.
Zákon o ISVS rozlišuje dvě role subjektu ve vztahu k ISVS, a to správce [§ 2 písm. c) zákona o ISVS] a provozovatele [§ 2 písm. d) zákona o ISVS. Upravuje zejména povinnosti orgánu veřejné správy jako správce ISVS, povinnosti provozovatele jsou uvedeny v § 9e zákona o ISVS.
Správcem ISVS je orgán veřejné správy, pokud zvláštní zákon nestanoví jinak. Tak se stalo například v případě Rady pro výzkum a vývoj, která je správcem Informačního systému výzkumu, vývoje a inovací, neboť tak stanoví zákon č. 130/2002 Sb., o podpoře výzkumu a vývoje z veřejných prostředků (Rada pro výzkum, vývoj a inovace je odborným a poradním orgánem vlády pro oblast výzkumu, vývoje a inovací, tedy nikoliv orgánem veřejné správy ve smyslu zákona ISVS).
Provozovatelem ISVS může být jakýkoliv subjekt, „pokud to jiný zákon nevylučuje“ – viz § 2 písm. d) zákona o ISVS.
Orgán veřejné správy může být i v roli uživatele ISVS, s tím počítá § 2 písm. e) zákona o ISVS.
Pro zpracování informační koncepce je nutné tyto role odlišovat, resp. je nutné odlišit správce od zbylých dvou rolí, tj. role provozovatele a role uživatele.
V některých případech by mohlo být obtížné odlišit provozovatele a uživatele, a to na základě definice provozovatele v zákonu o ISVS – provozovatelem je subjekt, který „zajišťuje funkčnost technických a programových prostředků tvořících informační systém veřejné správy“ – viz § 2 písm. d) zákona o ISVS. Striktní odlišování provozovatele a uživatele však nemá při zpracování informační koncepce praktický význam, neboť – jak je uvedeno výše – informační koncepce se „povinně“ zabývá pouze těmi ISVS,
u nichž je orgán veřejné správy v roli správce.
Pokud však orgán veřejné správy bude považovat za účelné, například pro komplexnost přístupu, uvést v informační koncepci všechny ISVS, se kterými pracuje (i jako provozovatel nebo jako uživatel), není mu v tom bráněno.
Doporučuje se, aby orgán veřejné správy uvedl do informační koncepce všechny informační systémy, kterých je správcem, tedy ISVS i provozní. Při posuzování, které informační systémy veřejné správy podléhají povinnosti uvádět je do informační koncepce, je třeba postupovat i s ohledem na to, že existuje povinnost uvádět do informační koncepce takové provozní informační systémy, které mají vazby na informační systémy veřejné správy, které nejsou provozními informačními systémy.
Souhrnně - v informační koncepci daného orgánu veřejné správy
- musejí být uvedeny ISVS, u nichž je daný orgán správcem,
- musejí být uvedeny provozní IS vybraných kategorií, u nichž je daný státní orgán správcem,
- mohou být uvedeny ISVS, u nichž je daný orgán provozovatelem, případně uživatelem,
- mohou být uvedeny provozní informační systémy, u nichž je daný orgán správcem,
- mohou být uvedeny provozní informační systémy, u nichž je daný orgán provozovatelem
Součástí informační koncepce by měly být i „kombinované“ informační systémy zahrnující zpracování více agend úřadu, z nichž některé jsou výkonem veřejné správy v úzkém slova smyslu (subsystém kombinovaného systému je ISVS) a další jsou vysloveně provozní (subsystém kombinovaného systému je provozním IS), např. výběr správních poplatků spojený s pokladnou a účetnictvím úřadu.
Webové stránky a portály
Orgán veřejné správy může pro tyto účely nahlížet na své webové stránky a portály jako ISVS nebo může považovat zpřístupnění informací prostřednictvím webových stránek nebo portálu za jednu z funkcionalit (činností) konkrétního ISVS. Pokud zvolí první přístup, je vhodné, aby definoval jednotlivé agendy na webu nebo portálu jako subsystémy. V každém případě by měly být webové stránky i portály uvedeny v informační koncepci.
Provozní informační systémy
Dřívější znění zákona o ISVS sice provozní informační systémy zmiňovala, avšak tyto systémy byly z působnosti zákona výslovně vyňaty s tím, že se o informační systémy veřejné správy vůbec nejedná.
Nynější právní úprava provozní informační systémy působnosti zákona o ISVS z velké části své působnosti podrobuje. V § 2 písm. t) zákona o ISVS je stanoveno, že provozní informační systémy jsou, a to bezvýjimečně, informačními systémy veřejné správy. Vybrané kategorie provozních informačních systémů, spravované státními orgány, jsou podrobeny působnosti zákona o ISVS (až na výslovné výjimky) stejně jako ostatní informační systémy veřejné správy; jedná se o (i) informační systémy pro řízení a rozvoj lidských zdrojů a odměňování, (ii) elektronické systémy spisové služby, (iii) informačních systémy pro vedení účetnictví nebo řízení finančních zdrojů, a (iv) systémy elektronické pošty (§ 1 odst. 4 zákona o ISVS). Ostatní provozní informační systémy jsou sice z působnosti zákona o ISVS vyňaty, nicméně ze zmíněného výčtu je zřejmé, že kategorie provozních informačních systémů, které jsou státními orgány nejčastěji spravovány, podléhají působnosti zákona o ISVS nepochybně.
Činnosti, pro jejichž zajištění se tyto IS používají, bezprostředně neslouží pro výkon veřejné správy v úzkém slova smyslu.
Výše uvedené systémy by byly neprovozními systémy v případě, kdy je předmětná činnost kompetencí daného orgánu veřejné správy. Tak je třeba odlišit
evidenci majetku orgánu veřejné správy (jedná se o provozní informační systém)
informační systém např. o (správních) rozhodnutích o přidělení nebo odnětí dotací (v tomto případě by se jednalo o neprovozní ISVS).
V obou případech se jedná o informační systémy, kterými se sleduje (statický a dynamický) stav majetku, ovšem v prvním případě pouze majetku spravovaného orgánem veřejné správy, kdežto ve druhém případu o kompetenci orgánu veřejné správy (přičemž v praxi může jít o jeden a tentýž orgán veřejné správy).
Závěrečné doporučení
Z hlediska praxe, například při zpracování informační koncepce, může být pro orgán veřejné správy výhodnější informační systémy nerozdělovat na ty, které jsou provozními ISVS anebo jinými ISVS Striktní dělení není nezbytné i s ohledem na tu skutečnost, že provozní ISVS je stále ISVS, ač se na něj nevztahují veškeré povinnosti zákona.
Další relevantní strategické dokumenty
Pro dlouhodobé řízení informačních systémů veřejné správy je klíčová především Informační koncepce České republiky, výslovně předpokládaná § 5a odst. 1 zákonem o ISVS, a její navazující dokumenty zmíněné výše.
Metodické materiály k řízení rizik
Klasifikace modelů, pohledů a prvků
Přehled dimenzí klasifikace a segmentace modelů a pohledů
Všechny architektonické výstupy - modely, pohledy na ně a varianty těchto pohledů musí být v lokálních úložištích úřadů i v centrálním architektonickém úložišti NA VS ČR klasifikovány dle jednotné sady atributů.
Ať už je přístup k modelu v kterémkoli úložišti zprostředkován v menu nebo navigaci jakoukoli kombinací (pořadím) níže uvedených dimenzí, vždy musí být model povinně klasifikován všemi níže uvedenými atributy, pokud není v pravidlech pro některý atribut stanoveno jinak. Linearizovaný klasifikační řetězec modelu (pohledu) se může stát technickou, kódovou součástí jeho označení.
Organizace VS a jejich modely jsou pro účely řízení a governance NA VS ČR klasifikovány v těchto skupinách dimenzí:
A) Klasifikace modelovaných (modelujících) subjektů veřejného sektoru B) Klasifikace architektonických modelů C) Klasifikace pohledů na model
Zvláštní formou klasifikace úřadů a jejich modelů je jejich:
D) Segmentace úřadů a modelů podle podobnosti
Následuje výčet definovaných klasifikačních a segmentačních dimenzí v jednotlivých skupinách. Podrobnější vysvětlení dimenzí, jejich původu a významu a k nim přípustných hodnot se nachází v odpovídajících kapitolách celkové koncepce metodiky NA VS ČR.
A) Klasifikace modelovaných (modelujících) subjektů veřejného sektoru se opírá o následující dimenze:
- Klasifikace modelujících organizací podle pozice v systému veřejné správy (EU, centrální ČR, ústřední, krajské, ORP apod.)
- Jednoznačná identifikace modelovaného (modelujícího) úřadu – OVM nebo podniku či jiné organizace veřejného sektoru podle tzv. kódu organizace z číselníku OVM v ISDS.
- Dělení architektur podle rozsahu/vazeb modelovaných organizací (architektura vlastní, společná s kontrolovanými organizacemi a architektury rozšířeného úřadu.
Název atributů úřadu | Význam atributu | Hodnoty atributu |
---|---|---|
POZICE | Pozice ve struktuře VS ČR | EUN, CNT, KRJ, (PRG), (STM), ORP, OST, PRV, KLI, OVM |
KÓD ORGANIZACE | Jednoznačný kód organizace z číselníku OVM | Kód organizace podle ISDS |
ROZSAH | Vlastní, společná nebo rozšířená architektura úřadu | VLST, SPOL, ROZS |
NÁZ_ROZS | Název rozšíření | text |
Každý úřad může mít pouze jeden jediný model vlastní architektury (VLST) a jediný model společné architektury s podřízenými organizacemi (SPOL). Úřad ale může mít neomezeně mnoho architektur „rozšířeného úřadu“ podle účelu, proto atribut (ROZS) musí být vždy doplněn o název (NÁZ_ROSZ).
Příklad klasifikace modelující organizace, s hodnotami společnými pro všechny kombinace atributů modelů a pohledů, uvedených níže.
Příklad 1: „KRJ KMORSLEZ ROZS_DOPRU“ – Moravskoslezský kraj v roli modelující rozšířený úřad (v tomto případě pro dopravní úřad společně s Ministerstvem dopravy).
Příklad 2: „ORP BENESOVMU SPOL“ – MÚ Benešov v roli modelující architekturu svého úřadu společně se všemi podřízenými organizacemi.
B) Klasifikace architektonických modelů má následující dimenze:
- Dělení modelů (a jejich pohledů) podle jejich úlohy v metodice tvorby a užití NA VS ČR (meta-model, referenční modely, vzorové (povinné) modely, anonymizované příklady a zejména individuální modely úřadů).
- Dělení modelů podle míry podrobnosti a účelu architektur (architektury úřadu – enterprise, architektury řešení – solution a design řešení).
Metamodel je jeden, jednotný a společný pro všechny modely architektury úřadu (Enterprise Architecture) vytvářené v rámci NA VS ČR. Proto nevyžaduje žádné další klasifikace dle atributů v této kapitole.
Implicitní hodnoty „IM“ a „EA“ musí být uvedeny v atributech modelu, ale nepředpokládá se, že by se stávaly součástí jejich technického, kódového označení. Naopak – u specifických druhů modelů (jiných než IM) případně modelů podrobnější architektur než je EA se zahrnutí do kódového názvu modelu vyžaduje.
Název atributů modelu | Význam atributu | Hodnoty atributu |
---|---|---|
DRUH | Druh (účel, typ) modelu (metamodel, referenční, vzorový, příkladový, individuální, …) – individuální je implicitní a neuvádí se. Ostatní obecné kódy se uvádějí namísto kódu organizace. | MM, RM, VM, PM a IM |
ÚROVEŇ | Úroveň modelu v hierarchii architektur podniku dle podrobnosti (z angličtiny) – implicitně bez označení je EA. Atribut nebude využit, nahradí ho atribut pohledu „účel“. | EA, SA, SD |
Příklad klasifikace modelu, složená vždy z klasifikace modelujícího úřadu a vlastní klasifikace modelu:
Příklad 1: „KRJ RM VLST“ – označuje referenční model vlastní (malé) architektury pro organizace na krajské úrovni územní samosprávy. Nelze ale dovodit, zda je to RM pro krajské úřady nebo některé typy jimi zřizovaných organizací, to se pozná až z názvu modelu a pohledu.
C) Na klasifikaci modelů navazuje klasifikace (dělení) pohledů na model:
- Členění pohledů uvnitř modelu (enterprise) architektury úřadu podle rozsahu a účelu (strategické, segmentové a schopnostní)
- Dělení pohledů podle fází architektur, které zobrazují (minulá, stávající, cílová a přechodné-tranzitní architektury)
- Dělení podle domén modelu, k nimž se pohled převážně odkazuje (motivační, byznys-procesní, IS – datová a aplikační, technologická – IT technologie a komunikační infrastruktura, bezpečnostní, případně výkonnostní, architektura implementace a migrace).
- Aplikovaný úhel pohledu, resp. definice pohledu podle metodiky NA VS ČR
- Název pohledu, zpřesňující a rozvíjející informaci z úhlu pohledu.
- Rozlišování míry podrobnosti variant pohledů téhož úhlu pohledu na model (Přehledová -L0, Základní - L1 a Detailní - L2)
Název atributů pohledu | Význam atributu | Hodnoty atributu |
---|---|---|
ÚČEL | Členění pohledů uvnitř modelu (enterprise) architektury úřadu. Týmž atributem lze vyjádřit i architektury nižší úrovně – architekturu řešení (SOL) a design řešení (DES). | STR, SGM, SCH, SOL, DES |
FÁZE(Typ, Rok) | Vztah pohledu vzhledem k časové ose (minulé, současné, budoucí přechodové a cílové architektury). Období záměru fáze architektury (vyjádření minulosti, současnosti nebo budoucnosti AS2013, TB2020). Bez uvedení představuje neznámou minulost nebo cílovou budoucnost v nekonečnu. | ASrrrr, TBrrrr |
DOMÉNA | Označení převažující domény (vrstvy) pohledu na model (zkratky z angličtiny) | BA, AA, DA, TA, IA, SA, PA, IM |
ÚHEL_POHLEDU | Název (kód) typu úhlu pohledu (definice pohledu) – např. aplikační katalog, mapa schopností, matice CRUD, a další | Bude vytvořen číselník úhlů pohledů (viewpoints) |
NÁZEV_POHLEDU | Název pohledu na model (konkrétní instance), je-li třeba | text |
DETAIL | Míry podrobnosti variant pohledů téhož úhlu pohledu na model | L0, L1 a L2 |
Vztah pohledu k převažující doméně modelu je jednoznačně dán zvoleným typovým úhlem pohledu, proto je třeba pohled doménou klasifikovat, ale do kódového označení pohledu nemusí vstupovat.
Příklad: „STR TB2020 AA APLMAPA L0“ představuje strategický, tj. celostní pohled typu aplikační mapa na aplikační architekturu v redukovaném detailu (pouze vybrané principiální instance aplikačních komponent).
Celkově bude ale výše uvedená aplikační mapa klasifikována následovně:
- plná klasifikace: „ORP BENESOVMU SPOL IM EA STR TB2020 AA APLMAPA L0“
- redukované kódové označení: „_ BENESOVMU SPOL _ _ STR TB2020 _ APLMAPA L0“, kde podtržítka ukazují místa vynechaných (implicitních a odvoditelných) kódů. Ve skutečném kódovém označená by se tato podtržítka nevyskytovala a měl by následující podobu: „ BENESOVMU SPOL STR TB2020 APLMAPA L0“.
D) Segmentace úřadů podle podobnosti a přenositelnosti nejlepších praxí, podle dimenzí:
- kategorií veřejných funkcí úřadu/podniku
- skupiny agend a agend
- odvětví veřejné správy/sektoru
- velikosti úřadů/podniků veřejného sektoru
Segmentace vychází z poznání typických vlastností úřadu jako celku, ale nejčastěji se projeví při modelování jeho částí, odkud se zpětně převezme do vyhodnocování celku.
Každý model musí být klasifikován podle všech těchto atributů s uvedením všech identifikovaných hodnot.
Segmentace modelů NA VS ČR začne být plně a povinně využívána až poté, co OHA MV po pilotních projektech uvolní k použití odpovídající číselníky.
FUNKCE | Dle užívaného členění funkcí veřejného sektoru. | STAT, UZEM_SAMO, ZAJM_SAMO, ZAKON, SOUD, V_SLUZ, V_PODNIK, atp. |
AGENDA | Skupiny agend a agendy | Dle číselníku vytvořeného v návaznosti na RPP |
ODVĚTVÍ | Odvětví veřejné správy | Dle zvláštního číselníku, jako (DOTACE, POJIST, INVEST, PROF_SLUZ, VEDA, atd.) |
VELIKOST | Kategorie podle počtu zaměstnanců úřadu, vždy do …: | 10, 50, 200, 1000, 5000, VICE |
Hledání příslušnosti úřadu k segmentům je pomůckou pro modelování, analýzu a podporu rozhodování, zejména pro identifikaci potenciálních oblasti architektury k využití známých nejlepších praxí, pro sjednocování a sdílení.
Segmentace obsahu modelu (vícenásobná klasifikace do segmentů) není do kódového označování zahrnována, v uvedeném příkladu architektury SPOL by představovala velmi rozsáhlý řetězec.
U modelů skutečných architektur (IM) vyjadřuje segmentace vlastnosti obsahu modelu, tedy jaké segmenty byly v organizaci identifikovány. Naproti tomu u zvláštních modelů, tj. segmentových RM-referenčních, segmentových VM-vzorech a segmentových PM-příkladech je třeba v názvu a v kódovém označení pohledu na model uvést, pro jaké segmenty úřadů VS jsou určeny, jaké Know-How nebo závazná pravidla obsahují.
Atributy modelů, pohledů a prvků
Klasifikace dle principu Šanonu
- Každý úřad má svůj šanon, podle kterého je jasně identifikovatelný (Klasifikace modelovaného úřadu)
- Zcela výjimečně je možné modelovat na centrální úrovni systém, který patří k EU, nebo k CZ, nikoli ke konkrétnímu úřadu.
- Každý úřad má JEDEN svůj celkový model, popisující úřad jako celek ve zjednodušené formě (Klasifikace modelu úřadu)
- Každý úřad má mnoho pohledů na své modely (Klasifikace pohledu - diagramu).
- Každý úřad má jeden model (diagram) pro jeden provozovaný informační systém ve veřejné správě (Klasifikace informačního systému)
- Model jest soubor objektů a vazeb mezi objekty zobrazené v předem definovaných definic pohledů
- Model jest v šanonu oddělovací papír (záložka) se svojí klasifikací a jsou jednotlivé pohledy na model jako samostatné listy
- Každý model obsahuje kromě své klasifikace i klasifikaci modelujícího úřadu
- Jedná se jen o klasifikace modelů, ne o klasifikace pohledů či objektů
- Fyzicky je model přenosový soubor dle standardu TOGAMEFF
Rozcestník:
- Úřad
- Model
- Pohled
- Obecný prvek
- Obecná vazba
- Byznys funkce
- Informační systém
Klasifikace modelujícího úřadu. Ten kdo modeluje za sebe a své podřízené organizace
Název atributu CZ | Název atributu EN | Hodnoty atributu EN | Hodnoty atributu CZ2 | Popis atributu |
---|---|---|---|---|
identifikace_uradu | agency_ID | agency_ID | Jednoznačný identifikátor uradu ve VS | |
uroven_VS | agency_PS_level | agency_PS_level | Úroveň úřadu v hierarchiii VS | |
EUN | EUN | Evropská unie | ||
CNT | CNT | eGovernment ČR | ||
AGN | USU | (Agency) Ústřední správní úřad | ||
CTY | KRJ | (County) Kraj, krajský úřad a krajská korporace | ||
PRG | PRG | Praha - jako kombinace KRJ a ORP | ||
MUN | ORP | (Municipality) Obec (převážně s rozšířenou působností, ale i ostatní) | ||
GOV | OVM | (Government-all institutions) souhrnná kategorie pro modely, platné pro všechna OVM | ||
OTH | OST | (Others) pomocná kategorie pro jiné než uvedené (doplněk množiny) | ||
CLI | KLI | (Clients) pomocná kategorie pro referenční modely typového klienta | ||
PRV | PRV | (Private) pomocná kategorie pro individuální a refereční modely soukromoprávních subjektů - součástí veřejnoprávních korporací nebo mimo stojící | ||
PUB | VER | (Public) pomocná kategorie pro subjekty, které jsou součástí veřejného sektoru, ale nejsou OVM (a nebo možná i včetně nich ???) | ||
ALL | VSE | (All - everyone) pomocná kategorie pro RM a PT, platné pro všechny bez rozdílu |
Klasifikace modelů úřadu
Název atributu CZ | Název atributu EN | Hodnoty atributu EN | Hodnoty atributu CZ | Popis atributu |
---|---|---|---|---|
Zděděné atributy úřadu | ||||
identifikace_uradu | agency_ID | Jednoznačný identifikátor uradu ve VS | ||
uroven_VS | agency_PS_level | Úroveň úřadu v hierarchiii VS | ||
Základní atributy modelu | ||||
druh_modelu | model_type | Druh (typ) modelu z hlediska míry abstrakce a účelu | ||
MM | MM | Meta-model, definuje způsob modelování na národní, korporátní i lokální (případně mezinárodní) úrovni | ||
RM | RM | Referenční model, definuje klasifikaci (taxonomii) a způsob modelování ve svém rozsahu působnosti | ||
IM | IM | Individuální model architektury konkrétní organizace (konceptuální, logický nebo fyzický, ale vždy konkrétně individuální) | ||
PT | VM | (Pattern) Vzorový model - povinný architektonický vzor | ||
EX | PM | (Example) Příklad individuálního modelu, obvykle (ale ne nutně) anonymizovaný (pak nemá identifikátor subjektu) | ||
rozsah_modelu | model_scope | |||
OWN | VLST | (Own) Vlastní model úřadu, identifikovaného nebo typového subjektu veřejné správy nebo soukromé sféry | ||
GRP | SPOL | (Group) Společný model skupiny subjektem VS ovládaných/ovlivňovaných organizací | ||
EXT | ROZS | (Extended) Rozšířený model dodávky veřejných služeb, zahrnující všechny konkrétní a typové subjekt nutné pro realizaci služby | ||
rozsireni_nazev | model_scope-name | |||
text | text | Jméno vystihují řetězec dodávky služby, například "dopravní úřady" - tj. MD a DÚ na KÚ. | ||
identifikace | Identifikace modelu (textový popis-název modelu) | |||
model_ID | Technické unikátní označení modelu úřadu (jednoho z více modelů úřadu) | |||
model_name | Jméno vystihující vlastnosti modelu | |||
model_version | Verze jednoho a téhož modelu úřadu | |||
Doplňkové atributy modelu | ||||
aktualizace_modelu_datum | model_update_date | |||
platnost_modelu_datum | model_valid_to | |||
odpovedna_osoba | odpovědná osoba za model | |||
model_resp_pers_ID | identifikátor osoby v organizaci (v celé veřejné správě), služební číslo státního zaměstnance. | |||
model_resp_pers_name | jméno (a příjmení) osoby | |||
centralni_sdilene_sluzby | je obsahem modelu centrální sdílená služba? | |||
agendy | Vykonávané agendy | |||
stav | Stav modelu v časovém horizontu |
Klasifikace pohledů, zejména diagramů (obrázků modelu) úřadu.
Název atributu CZ | Název atributu EN | Hodnoty atributu EN | Hodnoty atributu CZ | Popis atributu |
---|---|---|---|---|
Zděděné atributy úřadu | ||||
identifikace_uradu | agency_ID | Jednoznačný identifikátor uradu ve VS | ||
uroven_VS | agency_PS_level | Úroveň úřadu v hierarchiii VS | ||
Zděděné atributy modelu | ||||
druh_modelu | model_type | Druh (typ) modelu z hlediska míry abstrakce a účelu | ||
rozsah_modelu | model_scope | |||
rozsireni_nazev | model_scope-name | |||
identifikace | model-name | Identifikace modelu (textový popis-název modelu) | ||
aktualizace__modelu_datum | model_ mnt_date | |||
platnost_modelu_datum | model_valid_to | |||
odpovedna_osoba | model_resp_person | odpovědná osoba za model | ||
Základní atributy diagramu | ||||
ucel_diagramu | view_purpose | Vyjadřuje současně míru rozsahu a podrobnosti pohledu na model | ||
STR | STR | Strategická architektura celého úřadu a jeho vize | ||
SGM | SGM | Segmentová architektura významné části úřadu | ||
CAP | SCH | (Capability) Schopnostní architektura určité vertikální nebo horizontální schopnosti úřadu | ||
SOL | RES | (Solution) Podrobnější architektura dílčího řešení (pro funkční specifikaci zadání nebo dokumentaci výsledku) | ||
DES | DES | (Design) Detailní návrh provedení (konstrukce, programování, …) části řešení | ||
typ_hlediska | view_viewpoint_ID | Označení typového hlediska tohoto pohledu | ||
ID from list | ID z číselníku | Seznam typových (předefinovaných) hledisek dle NAR | ||
domena_diagramu | view_domain | Vůdčí (převažující) doména, pokud ji lze uvést | ||
MA | Motivation & Strategy | |||
PA | Performance arch. | |||
BA | Business arch. | |||
AA | Application arch. | |||
DA | Data (Information) arch. | |||
TA | IT Technology arch. | |||
IA | Comm. Infrastructure arch. | |||
RS | Risk&Secutiry architecture | |||
SC | Standardization&Compliance&Sustainability | |||
IM | Implementation&Migration | |||
jmeno_diagramu | Název konkrétního artefaktu, katalogu, matice nebo diagramu | |||
view_ID | Technické unikátní označení pohledu na model úřadu (jednoho z mnoha pohledů na jeden model úřadu) | |||
view_name | Jméno vystihující vlastnosti pohledu | |||
view_version | Verze jednoho a téhož pohledu na model úřadu | |||
typ_artefaktu | view_type | Typ architektonického výtvoru (katalog, matice, diagram) | ||
CAT | KAT | Katalog | ||
MTX | MAT | Matice | ||
DGM | DIA | Diagram (grafický) | ||
uroven_detailu | view_detail_level | Úroveň podrobnosti modelu při stanoveném rozsahu (L0, L1 a L2) | ||
L0 | L0 | Agregovaný | ||
L1 | L1 | Základní | ||
L2 | L2 | Detailní | ||
cas_horizont | view_horizon_state | Umístění pohledu v čase (zda byl vytvářen jako pohled na současnost minulost nebo návrh budoucnosti). | ||
TGT | cil | (Target) Cílová architektura na konci horizontu (To_Be) | ||
BSL | akt | (Baseline) Výchozí aktuální architektura (As-Is) | ||
TRN | pre | (Transition) Přechodová architektura v průběhu času do horizontu (také To-Be) | ||
HST | hst | (History) architektura někdy v minulosti (As-it-was) | ||
cas_horiz_datum | view_horizon_date | Rok nebo datum, kterého stav (aktuální, přechodný nebo cílový) diagram ukazuje | ||
date | datum | |||
Doplňkové atributy diagramu | ||||
odp_osoba_pohled | view_resp_person | odpovědná osoba za diagram nebo jiný artefakt | ||
ID_odp_osoby_pohled | view_resp_pers_ID | |||
jmeno_diagramu | view_resp_pers_name | |||
platnost_diagramu_datum_od | view_valid_from | Datum, od kterého je návrh stavu (aktuální, přechodný nebo cílový) považován za platný, směrodatný | ||
platnost_diagramu_datum_do | view_valid_to | Datum, do kterého je návrh stavu (aktuální, přechodný nebo cílový) považován za platný, směrodatný | ||
date | datum | |||
aktualizace_diagramu_datum | view_ update_date | Datum dne, kdy byl návrh diagramu (aktuální, přechodný nebo cílový) naposledy aktualizován | ||
date | datum |
Klasifikace každého (jakéhokoli) prvku modelu úřadu.
Název atributu CZ | Název atributu EN | Hodnoty atributu EN2 | Hodnoty atributu CZ | Popis atributu |
---|---|---|---|---|
Zděděné atributy úřadu | ||||
identifikace_uradu | agency_ID | Jednoznačný identifikátor uradu ve VS | ||
uroven_VS | agency_PS_level | Úroveň úřadu v hierarchiii VS | ||
Zděděné atributy modelu | Atributy platí i pro obraz libovolného prvku, je-li v modelu | |||
druh_modelu | model_type | Druh (typ) modelu z hlediska míry abstrakce a účelu | ||
rozsah_modelu | model_scope | |||
rozsireni_nazev | model_scope-name | |||
identifikace | model-name | Identifikace modelu (textový popis-název modelu) | ||
aktualizace__modelu_datum | model_ mnt_date | |||
platnost_modelu_datum | model_valid_to | |||
odpovedna_osoba | model_resp_person | odpovědná osoba za model | ||
Zděděné atributy diagramu | Atributy platí i pro obraz libovolného prvku, je-li v pohledu na model | |||
ucel_diagramu | view_purpose | Vyjadřuje současně míru rozsahu a podrobnosti pohledu na model | ||
typ_hlediska | view_viewpoint_ID | Označení typového hlediska tohoto pohledu | ||
domena_diagramu | view_domain | Vůdčí (převažující) doména, pokud ji lze uvést | ||
jmeno_diagramu | view_name | Název konkrétního artefaktu, katalogu, matice nebo diagramu | ||
typ_artefaktu | view_type | Typ architektonického výtvoru (katalog, matice, diagram) | ||
uroven_detailu | view_detail_level | Úroveň podrobnosti modelu při stanoveném rozsahu (L0, L1 a L2) | ||
cas_horizont | view_horizon_state | Umístění pohledu v čase (zda byl vytvářen jako pohled na současnost minulost nebo návrh budoucnosti). | ||
cas_horiz_datum | view_horizon_date | Rok nebo datum, kterého stav (aktuální, přechodný nebo cílový) diagram ukazuje | ||
odp_osoba_pohled | view_resp_person | odpovědná osoba za diagram nebo jiný artefakt | ||
aktualizace__diagramu_datum | view_ update_date | Datum dne, kdy byl návrh diagramu (aktuální, přechodný nebo cílový) naposledy aktualizován | ||
platnost_diagramu_datum_od | view_valid_from | Datum, od kterého je návrh stavu (aktuální, přechodný nebo cílový) považován za platný, směrodatný | ||
platnost_diagramu_datum | view_valid_to | Datum, do kterého je návrh stavu (aktuální, přechodný nebo cílový) považován za platný, směrodatný | ||
Základní atributy prvku (objektu, konceptu, elementu) modelu | ||||
Identifikace konceptu z metamodelu | ||||
concept_ID | Metamodel_ Identifikátor modelovaného objektu/subjektu v meta - modelu úřadu | |||
concept_name | Metamodel_Označení, jméno prvku metamodelu | |||
Identifikace prvku (instance) v modelu | ||||
element_model_ID | Metamodel_ Identifikátor modelovaného objektu/subjektu v meta - modelu úřadu | |||
element_ext_ID | Metamode_Identifikátor modelovaného objektu/subjektu v reálném světě (v organizaci, ve státě) | |||
element_name | Metamodel_Označení, jméno prvku metamodelu | |||
Atributy standardizace | ||||
Standard_Y_N | Zda je modelovaný prvek prohlášen v organizaci za standard | |||
Standard_from | Datum, od kdy je prvek prohlášen za standard | |||
Standard_to | Datum, do kdy je prvek prohlášen za standard | |||
Std_related_element | Identifikátor prvku, který je standardem pro modelovaný prvek | |||
Next_std_eval | Datum plánovaného příštího vyhodnocení standardu pro prvek | |||
Std_resp_pers_ID | ID osoby zodpovědné za udržování standardu pro prvek | |||
Std_resp_pers_name | Jméno osoby zodpovědné za udržování standardu pro prvek | |||
Zodpovědnost a platnost údajů prvku | ||||
element_resp_pers_ID | identifikátor osoby v organizaci (v celé veřejné správě), služební číslo státního zaměstnance. | |||
element_resp_pers_name | jméno (a příjmení) osoby | |||
element_ update_date | Datum dne, kdy byly údaje prvku naposledy aktualizovány | |||
element_valid_from | Datum, od kterého je návrh stavu prvku považován za platný, směrodatný | |||
element_valid_to | Datum, do kterého je návrh stavu prvku považován za platný, směrodatný |
Klasifikace vazeb mezi prvky modelu úřadu (obecná).
Název atributu CZ | Název atributu EN | Hodnoty atributu EN2 | Hodnoty atributu CZ | Popis atributu |
---|---|---|---|---|
Zděděné atributy úřadu | ||||
identifikace_uradu | agency_ID | Jednoznačný identifikátor uradu ve VS | ||
uroven_VS | agency_PS_level | Úroveň úřadu v hierarchiii VS | ||
Zděděné atributy modelu | Atributy platí i pro obraz libovolné vazby prvků, je-li v modelu | |||
druh_modelu | model_type | Druh (typ) modelu z hlediska míry abstrakce a účelu | ||
rozsah_modelu | model_scope | |||
rozsireni_nazev | model_scope-name | |||
identifikace | model-name | Identifikace modelu (textový popis-název modelu) | ||
aktualizace__modelu_datum | model_ mnt_date | |||
platnost_modelu_datum | model_valid_to | |||
odpovedna_osoba | model_resp_person | odpovědná osoba za model | ||
Zděděné atributy diagramu | Atributy platí i pro obraz libovolné vazby prvků, je-li v pohledu na model | |||
ucel_diagramu | view_purpose | Vyjadřuje současně míru rozsahu a podrobnosti pohledu na model | ||
typ_hlediska | view_viewpoint_ID | Označení typového hlediska tohoto pohledu | ||
domena_diagramu | view_domain | Vůdčí (převažující) doména, pokud ji lze uvést | ||
jmeno_diagramu | view_name | Název konkrétního artefaktu, katalogu, matice nebo diagramu | ||
typ_artefaktu | view_type | Typ architektonického výtvoru (katalog, matice, diagram) | ||
uroven_detailu | view_detail_level | Úroveň podrobnosti modelu při stanoveném rozsahu (L0, L1 a L2) | ||
cas_horizont | view_horizon_state | Umístění pohledu v čase (zda byl vytvářen jako pohled na současnost minulost nebo návrh budoucnosti). | ||
cas_horiz_datum | view_horizon_date | Rok nebo datum, kterého stav (aktuální, přechodný nebo cílový) diagram ukazuje | ||
odp_osoba_pohled | view_resp_person | odpovědná osoba za diagram nebo jiný artefakt | ||
platnost_diagramu_datum_od | view_valid_from | Datum, od kterého je návrh stavu (aktuální, přechodný nebo cílový) považován za platný, směrodatný | ||
platnost_diagramu_datum | view_valid_to | Datum, do kterého je návrh stavu (aktuální, přechodný nebo cílový) považován za platný, směrodatný | ||
aktualizace__diagramu_datum | view_ update_date | Datum dne, kdy byl návrh diagramu (aktuální, přechodný nebo cílový) naposledy aktualizován | ||
Základní atributy vazby mezi prvky modelu | ||||
Identifikace typu vaby z metamodelu | ||||
rel_type_ID | Metamodel_ Identifikátor modelovaného tyou vazby v meta - modelu úřadu | |||
rel_type_name | Metamodel_Označení, jméno typu vazby v metamodelu | |||
Identifikace instance vazby v modelu | ||||
relation_ID | Identifikátor konkrétní vazby v modelu | |||
relation_name | Jméno konkrétní vazby v modelu | |||
Zodpovědnost a platnost údajů vazby | ||||
relation_resp_pers_ID | identifikátor osoby v organizaci (v celé veřejné správě), služební číslo státního zaměstnance. | |||
relation_resp_pers_name | jméno (a příjmení) osoby | |||
relation_ update_date | Datum dne, kdy byly údaje vazby naposledy aktualizovány | |||
relation_valid_from | Datum, od kterého je návrh stavu vazby považován za platný, směrodatný | |||
relation_valid_to | Datum, do kterého je návrh stavu vazby považován za platný, směrodatný |
Klasifikace byznysových prvků modelu úřadu.
Název atributu CZ | Název atributu EN | Hodnoty atributu EN2 | Hodnoty atributu CZ | Popis atributu |
---|---|---|---|---|
Zděděné atributy úřadu | ||||
identifikace_uradu | agency_ID | Jednoznačný identifikátor uradu ve VS | ||
uroven_VS | agency_PS_level | Úroveň úřadu v hierarchiii VS | ||
Zděděné atributy modelu | Atributy platí i pro obraz informačního systému, je-li v modelu | |||
druh_modelu | model_type | Druh (typ) modelu z hlediska míry abstrakce a účelu | ||
rozsah_modelu | model_scope | |||
rozsireni_nazev | model_scope-name | |||
identifikace | model-name | Identifikace modelu (textový popis-název modelu) | ||
aktualizace__modelu_datum | model_ mnt_date | |||
platnost_modelu_datum | model_valid_to | |||
odpovedna_osoba | model_resp_person | odpovědná osoba za model | ||
Zděděné atributy diagramu | ||||
ucel_diagramu | view_purpose | Vyjadřuje současně míru rozsahu a podrobnosti pohledu na model | ||
typ_hlediska | view_viewpoint_ID | Označení typového hlediska tohoto pohledu | ||
domena_diagramu | view_domain | Vůdčí (převažující) doména, pokud ji lze uvést | ||
jmeno_diagramu | view_name | Název konkrétního artefaktu, katalogu, matice nebo diagramu | ||
typ_artefaktu | view_type | Typ architektonického výtvoru (katalog, matice, diagram) | ||
uroven_detailu | view_detail_level | Úroveň podrobnosti modelu při stanoveném rozsahu (L0, L1 a L2) | ||
cas_horizont | view_horizon_state | Umístění pohledu v čase (zda byl vytvářen jako pohled na současnost minulost nebo návrh budoucnosti). | ||
cas_horiz_datum | view_horizon_date | Rok nebo datum, kterého stav (aktuální, přechodný nebo cílový) diagram ukazuje | ||
odp_osoba_pohled | view_resp_person | odpovědná osoba za diagram nebo jiný artefakt | ||
platnost_diagramu_datum_od | view_valid_from | Datum, od kterého je návrh stavu (aktuální, přechodný nebo cílový) považován za platný, směrodatný | ||
platnost_diagramu_datum | view_valid_to | Datum, do kterého je návrh stavu (aktuální, přechodný nebo cílový) považován za platný, směrodatný | ||
aktualizace__diagramu_datum | view_ update_date | Datum dne, kdy byl návrh diagramu (aktuální, přechodný nebo cílový) naposledy aktualizován | ||
Zděděné atributy obecného prvku modelu | ||||
Identifikace konceptu z metamodelu | ||||
Identifikace prvku (instance) v modelu | ||||
Atributy standardizace | ||||
Zodpovědnost a platnost údajů prvku | ||||
Specifické atributy byznys funkce (procesu) |
Klasifikace aplikačních komponent a služeb (IS) v modelu úřadu.
Název atributu CZ | Název atributu EN | Hodnoty atributu CZ2 | Hodnoty atributu CZ | Popis atributu |
---|---|---|---|---|
Zděděné atributy úřadu | ||||
identifikace_uradu | agency_ID | Jednoznačný identifikátor uradu ve VS | ||
uroven_VS | agency_PS_level | Úroveň úřadu v hierarchiii VS | ||
EUN | EUN | Evropská unie | ||
CNT | CNT | eGovernment ČR | ||
AGN | USU | (Agency) Ústřední správní úřad | ||
CTY | KRJ | (County) Kraj, krajský úřad a krajská korporace | ||
PRG | PRG | Praha - jako kombinace KRJ a ORP | ||
MUN | ORP | (Municipality) Obec (převážně s rozšířenou působností, ale i ostatní) | ||
GOV | OVM | (Government-all institutions) souhrnná kategorie pro modely, platné pro všechna OVM | ||
OTH | OST | (Others) pomocná kategorie pro jiné než uvedené (doplněk množiny) | ||
CLI | KLI | (Clients) pomocná kategorie pro referenční modely typového klienta | ||
PRV | PRV | (Private) pomocná kategorie pro individuální a refereční modely soukromoprávních subjektů - součástí veřejnoprávních korporací nebo mimo stojící | ||
PUB | VER | (Public) pomocná kategorie pro subjekty, které jsou součástí veřejného sektoru, ale nejsou OVM (a nebo možná i včetně nich ???) | ||
ALL | VSE | (All - everyone) pomocná kategorie pro RM a PT, platné pro všechny bez rozdílu | ||
Zděděné atributy modelu | Atributy platí i pro obraz informačního systému, je-li v modelu | |||
druh_modelu | model_type | Druh (typ) modelu z hlediska míry abstrakce a účelu | ||
rozsah_modelu | model_scope | |||
rozsireni_nazev | model_scope-name | |||
identifikace | model-name | Identifikace modelu (textový popis-název modelu) | ||
aktualizace__modelu_datum | model_ mnt_date | |||
platnost_modelu_datum | model_valid_to | |||
odpovedna_osoba | model_resp_person | odpovědná osoba za model | ||
Zděděné atributy diagramu | Atributy platí i pro obraz informačního systému, je-li v pohledu na model | |||
ucel_diagramu | view_purpose | view_purpose | Vyjadřuje současně míru rozsahu a podrobnosti pohledu na model | |
typ_hlediska | view_viewpoint_ID | view_viewpoint_ID | Označení typového hlediska tohoto pohledu | |
domena_diagramu | view_domain | view_domain | Vůdčí (převažující) doména, pokud ji lze uvést | |
jmeno_diagramu | view_name | view_name | Název konkrétního artefaktu, katalogu, matice nebo diagramu | |
typ_artefaktu | view_type | view_type | Typ architektonického výtvoru (katalog, matice, diagram) | |
uroven_detailu | view_detail_level | view_detail_level | Úroveň podrobnosti modelu při stanoveném rozsahu (L0, L1 a L2) | |
cas_horizont | view_horizon_state | view_horizon_state | Umístění pohledu v čase (zda byl vytvářen jako pohled na současnost minulost nebo návrh budoucnosti). | |
cas_horiz_datum | view_horizon_date | view_horizon_date | Rok nebo datum, kterého stav (aktuální, přechodný nebo cílový) diagram ukazuje | |
odp_osoba_pohled | view_resp_person | view_resp_person | odpovědná osoba za diagram nebo jiný artefakt | |
platnost_diagramu_datum | view_valid_to | view_valid_to | Datum, do kterého je návrh stavu (aktuální, přechodný nebo cílový) považován za platný, směrodatný | |
aktualizace__diagramu_datum | view_ update_date | view_ update_date | Datum dne, kdy byl návrh diagramu (aktuální, přechodný nebo cílový) naposledy aktualizován | |
Zděděné atributy obecného prvku modelu | ||||
Identifikace konceptu z metamodelu | ||||
Identifikace prvku (instance) v modelu | ||||
Atributy standardizace | ||||
Zodpovědnost a platnost údajů prvku | ||||
Specifické atributy informačního systému | ||||
identifikace IS | IS_ID | identifikace IS | ||
nazev_IS | IS_name | Označení (jméno, názov) IS u klienta | ||
Dodavatel | IS_vendor | Dovavatel | ||
platforma_IS | IS_platform | Výchozí standardní balík nebo vývojová platforma | ||
pocatek provozu | IS_start_date | Datum prvního produktivního startu | ||
a další ….. | ||||
Klasifikace aplikačních komponent IS | ||||
appl_srvc_layer | Klasifikace aplikačních komponent a služeb IS podle typů klientů a "vzdálenosti" od nich a jejich obsluhy | |||
Externí FO | Portály klientů (agendové i průřezové) - podpora komunikace a obsluhy klientů, 1. linie, samoobslužné a asistované | |||
Externí MO | Agendově specifické aplikace obsahující byznys logiku, algoritmy, rozhodování, … | |||
Externí BO | Agendové Back-Office, platby, spisovky, plánování kontrol, saldokontní účetnictví apod. | |||
Interní FO | Portály zaměstnanců (agendové, provozní i průřezové) - podpora komunikace a obsluhy zaměstnanců, 1. linie, samoobslužné a asistované, SSC | |||
Interní MO | Specifické aplikace pro správu interních zdrojů | |||
Interní BO | Průřezové aplikace pro správu interních zdrojů (nad rámec Rozpočetnictví) | |||
Rozpočetnictví | Základní podpora řízení zdrojů a rozpočetnictví (ERP) | |||
appl_user_platf_layer | Klasifikace aplikačních komponent a služeb IS podle vzdálenosti od uživatelů | |||
UI&Access | ||||
Composite | ||||
BI&dec_supp | ||||
Transaction | ||||
Generic IT | ||||
Platform | ||||
Atributy eGovernmentu | ||||
poskytovane_sluzby | poskytuje systém centrální služby? | |||
cerpane_sluzby | čerpá systém centrální služby? | |||
vrstvy | jakých vrstev architektury se model týká? | |||
spravce_modelu | správce modelu | |||
vecny_spravce | věcný správce modelovaného systému | |||
technicky_spravce | technický správce modelovaného systému | |||
provozovatel | provozovatel modelovanoho systému | |||
architekt | architekt modelovaného systému | |||
strategie | jaké strategicke iniciativy je systém součástí | |||
legislativa | jaká legislativa ovlivňuje modelovaný systém | |||
agendy | jaké agendy systém podporuje? | |||
narodni_dc | využívá systém služeb národních datových center? | |||
soukroma_dc | využívá systém služeb soukromých datových center? | |||
cms | využívá systém služeb CMS? | |||
portal | je součástí systému portál? | |||
typ | Centrální aplikační služba, Provozní, Agendový, Bezpečnostní, Samoobslužny portál, Samosprávný portál | Centrální aplikační služba, Provozní, Agendový, Bezpečnostní, Samoobslužny portál, Samosprávný portál |
Seznam záměrů digitálního Česka
o požadavcích na strukturu a obsah informační koncepce a provozní dokumentace a o požadavcích na řízení bezpečnosti a kvality informačních systémů veřejné správy (vyhláška o dlouhodobém řízení informačních systémů veřejné správy).
Diskuze
existuje návod na zveřejňování formulářů dle § 4 odst. 3 zákona 12/2020 Sb.? Případně bližší informace ke způsobu zveřejňování (lhůta, schválení, apod.)?
Děkuji
zveřejňování formulářů se děje v rámci ohlášení detailního popisu služeb v AISK https://rpp-ais.egon.gov.cz/AISK/katalogy/dashboard.
Detailní popisy je nutné udělat co nejdříve, ale poslední termín je 1.2.2025.
S pozdravem,
Tomáš Šedivec