NAP/dokument

(sem pak logo DČ)

Informační koncepce České republiky

Návazný dokument č. 4

Národní architektonický plán ČR

Úvod

Co je Informační koncepce České republiky

Informační koncepce České republiky (dále jen „IKČR“) je základním dokumentem, který stanovuje na základě zmocnění podle § 5a odst. 1 zákona 365/2000 Sb., o informačních systémech veřejné správy, cíle České republiky v oblasti informačních systémů veřejné správy (dále také jen ISVS) 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.

IKČR v příloze 7: Metody řízení ICT veřejné správy ČR definuje pravidla, včetně orgánů a rolí odpovědných za jejich uplatňování v celém životním cyklu ICT služeb veřejné správy, tedy definuje pravidla strategického řízení IT, plánování, přípravy a implementace ICT projektů, provozu ICT služeb, řízení ekonomiky a bezpečnosti ICT služeb a pravidla kontroly a auditu (governance) ICT. IKČR v této příloze současně definuje základní požadavky na řízení a rozvoj orgánů veřejné moci a jejich útvarů informatiky tak, aby byly lépe schopny naplňovat cíle rozvoje služeb informačních systémů veřejné správy a řídit jejich životní cyklus.

Aby bylo možno tyto cíle efektivně realizovat, IKČR zavádí Národní architekturu VS ČR a Národní architektonický plán VS ČR jako prostředky pro popis architektury orgánů veřejné správy a architektury informačních systémů veřejné správy a jako základní nástroje pro formulaci cílů a principů Informační koncepce ČR a informačních koncepcí jednotlivých orgánů veřejné správy.

IKČR v příloze 9: Národní architektonický rámec zavádí závaznou metodiku modelování, udržování a používání popisu architektury orgánů veřejné správy.

IKČR v příloze 10: Národní architektonický plán orgánům veřejné správy – správcům informačních systémů - poskytuje jasnou a konkrétní představu toho, jak bude vypadat informatika VS ČR ve stanoveném horizontu 5 let, které prvky informatizace veřejné správy budou centrální a sdílené, které lokální prvky musí být jednotné podle předložených vzorů a které mohou být libovolné, jejich vzájemné vazby a návaznosti při současném dodržení stanovených architektonických principů.

IKČR v příloze 8: Slovník pojmů zavádí jednotný výklad pojmů a jejich případných synonym z platné legislativy, potřebných jako jeden z nástrojů koordinovaného budování eGovernmentu podle Národního architektonického plánu a pro koordinované řízení informatiky veřejné správy.

Orgány veřejné správy podle IKČR a jejích příloh vytvářejí svou informační koncepci.

Struktura dokumentu Národní architektonický plán

Strukturu kapitol 1až 7 definuje následující obrázek.

Kapitola 1 představuje východiska pro formulování v koncepci dále uvedených pravidel, a to jak z pohledu definice klíčových nových pojmů z oblasti architektury úřadů, tak zejména souhrn cílů a principů rozvoje eGovernmentu a rozvoje profese informatiky ve veřejné správě ČR. Kapitola je rozšířeným shrnutím podstatných myšlenek IKČR.

Kapitola 2 – představuje cílovou vizi eGovernmentu a jeho ICT podpory po naplnění IKČR a tohoto Národního architektonického plánu.

Kapitola 3 nahlíží na architekturu veřejné správy ČR tzv. „shora“ a přináší jak definice klíčových pojmů a prvků architektury VS, tak přehled centrálních sdílených služeb eGovernmentu, dostupných pro použití v lokálních architektách úřadů.

Kapitola 4 se zaměřuje na formulování pravidel pro návrh správné architektury úřadů, včetně jejich IT podpory, s využitím sdílených prvků e Governmentu a pro naplnění cílů a rozvoje principů eGovernmentu a informatizace VS ČR.

Kapitola 5 možná ještě něco – rozdělení kap. 4 – zejména asi osamostatněné referenční modely a povinné vzory

Kapitola 6 – centrální a lokální repozitory

Kapitola 7 – Roadmapa NAP

zbytek je standardní folklór

Struktura kapitol dokumentu Informační koncepce ČR

Působnost Informační koncepce ČR a Národního architektonického plánu

ke zvážení

Informační koncepce ČR je závazná pro všechny státní orgány a orgány územních samosprávných celků, které § 1 odst. 1 zákona o ISVS souhrnně označuje pojmem orgány veřejné správy, tj. na „státní orgány nebo orgány územních samosprávných celků“, tedy včetně obcí a krajů.

V návaznosti na požadavky stanovené prováděcím právním předpisem předpokládaným v § 5a odst. 2, větě třetí, zákona o ISVS, představuje IKČR základní obsahový rámec pro vytvoření, resp. aktualizaci vlastních informačních koncepcí jednotlivých orgánů veřejné správy, s jejichž vytvářením § 5a odst. 2 zákona o ISVS počítá.

Informační koncepce České republiky v oblasti samosprávy se vyznačuje některými odlišnostmi, které jsou dány definicí samosprávy. Jedná se zejména o:

• Každá obec či kraj jsou samostatné subjekty a je jim možno ukládat povinnosti pouze zákony
• Rozhodování obce je kolektivní (rozhoduje zastupitelstvo)
• Obec může vykonávat mimo samosprávných činností i přenesenou působnost
• Velikost samosprávných subjektů je velmi rozlišná – od krajů, které mají i více než milion obyvatel až po obce, které mají jen stovku obyvatel

Tyto odlišnosti se projevují v odpovídajících kapitolách IKČR a mají vliv na její uplatnění v orgánech územně samosprávných celků.

Úřadem se pro účely této IKČR rozumí každý orgán, který je povinnou osobou z hlediska této koncepce. Pokud není uvedeno jinak, jsou to v souladu se zákonem o ISVS tzv. orgány veřejné správy (OVS), jak je zmíněno výše.

Ostatních orgánů veřejné moci, které nejsou OVS, například škol nebo nemocnic, se tato IKČR netýká, ale mohou ji s výhodou užívat jako doporučení.

Odbor Hlavního architekta eGovernmentu Ministerstva vnitra ČR

ke zvážení

Odbor Hlavního architekta eGovernmentu Ministerstva vnitra ČR (dále jen „OHA“), jako nadresortní architektonický útvar eGovernmentu, rozpracovává principy stanovené vládou ČR v této IKČR do referenčních modelů, závazných architektonických vzorů a dalších dokumentů Národního architektonického plánu.

Tyto informace následně slouží orgánům veřejné správy k sestavování informačních koncepcí jejich úřadů a z nich vyplývajících projektových záměrů. OVS jsou podle příslušných ustanovení zákona o ISVS povinny požádat OHA o schválení návrhů dokumentací programů obsahujících pořízení nebo technické zhodnocení informačních systémů veřejné správy, investičních záměrů akcí pořízení nebo technického zhodnocení informačních systémů veřejné správy nebo projektů informačních systémů veřejné správy určených k výkonu státní správy. Organizační složky státu jsou i nadále povinny žádat o schválení záměrů výdajů na ICT podle příslušných ustanovení usnesení vlády ze dne 2. listopadu 2015, č. 889.

OHA vydává v návaznosti na požadavky zákona o ISVS a výše zmíněného usnesení vlády stanoviska k těmto žádostem zejména na základě posouzení shody architektury předkládaných záměrů s cíli a pravidly IKČR a návazných dokumentů OHA.

Periodicita a aktualizace dokumentu

ke zvážení

Informační koncepce ČR bude Ministerstem vnitra vyhodnocována a aktualizována každé dva roky, vždy s výhledem na následujících 5 let, má tedy charakter tzv. klouzavého plánu.

Po každé aktualizaci bude předkládána vládě znovu ke schválení spolu s informací o dosažení definovaných cílů.

Vztah IKČR k legislativě a základním strategickým materiálům

ke zvážení

Jelikož je Informační koncepce ČR dokumentem vzniklým na základě § 5a odst. 1 zákona o ISVS, rozpracovává především nároky, postupy a pojmový aparát tohoto zákona, zahrnuje však v mezích svého obsahu předpokládaného ustanovením § 5a odst. 1 zákona o ISVS současně nároky ostatních právních předpisů, popř. nelegislativních dokumentů (usnesení vlády, strategických dokumentů, apod.) upravujících výkon veřejné správy včetně její elektronizace.

Předpokládá se, že IKČR bude následována změnou vyhlášek, zejména č. 529/2006, o dlouhodobém řízení informačních systémů veřejné správy, pro plánování dlouhodobého rozvoje ISVS dle potřeb výkonu služeb úřadu a jejích změn, společně s aktualizací vzorů lokálních informačních koncepcí.

IKČR není strategií, ale rozpracovává zejména vládou schválenou Strategii rozvoje ICT služeb VS, z 2. listopadu 2015, dále Strategický rámec rozvoje VS 2014+ Akční plán eGovernmentu EU 2016-2020 a další platné strategie.

Jednotlivá v IKČR zdůrazněná témata a oblasti architektury eGovernmentu nebo řízení informatizace VS ČR budou dále rozpracována v navazujících koncepčních a metodických materiálech. Takovými budou zejména:

• Národní architektonický rámec, s metodikou modelování a metodikou rozvoje architektonických schopností
• Metodika řízení portfolia projektů
• Metodika řízení programů
• Metodika řízení projektů
• Metodika ICT Governance, včetně řízení rizik
• Metodika rozvoje lidských zdrojů v ICT
• Metodika nákupu ICT
• a další …

Základní pojmy řízení architektury veřejné správy a úřadu

Pro rozvoj všech schopností a dovedností veřejné správy, včetně rozvoje digitálních služeb VS, je nezbytné řídit veřejnou správu jako propojený komplexní systém služeb, poskytovaných orgány veřejné správy, s nadhledem a v celkových souvislostech. Protože většina transformačních kroků státu je stejně jako u podnikových korporací v současné době umožněna jen s pomocí ICT, je celková architektura orgánů veřejné správy, jejich úřadů a veřejnoprávních korporací, současně prostředkem vývoje a řízení transformačních změn a současně prostředkem dlouhodobého řízení a rozvoje ICT na podpor těchto změn.

Architektura veřejné správy jako socio-ekonomicko-technického systému je souborem prvků, které tvoří strukturu systému, jejich vzájemných vazeb, jejich chování (fungování) a principů a pravidel jejich vzniku a vývoje v průběhu času.

Architektura úřadu (EA) jako manažerská metoda je prostředkem celostního poznávání organizace na podporu rozhodování, zejména při plánování strategických změn, ale také na podporu řízení výkonnosti, kvality a zodpovědnosti.

Představuje popis struktury a chování úřadu (kdo jsme), plánovaných změn (odkud a kam jdeme) a jejich informatické podpory (k čemu nám je a má být ICT jako celek a jednotlivé informační systémy veřejné správy).

Zavedení tzv. Národní architektury veřejné správy (NA) a Národního architektonického plánu jejího rozvoje (NAP) touto IKČR vychází z nutnosti systematicky popsat současný a budoucí stav architektury VS tak, aby její popis podporoval řízení reforem VS i změn její ICT podpory.

Národní architektura VS ČR je souhrn architektur a popisů architektury všech jednotlivých úřadů veřejné správy, včetně všech centrálních sdílených prvků eGovernmentu.

Národní architektonický plán (NAP) bude tvořit popis současného stavu jednotlivých úřadů veřejné správy a centrálních prvků eGovernmentu, popis návrhů jejich cílového stavu, z nich plynoucí rozdíl, tedy rozsah očekávaných změn a plán, jak budou tyto změny realizovány.

Pro všechny modely a další dokumenty, popisující Národní architekturu VS bude využíván společný název Národní architektonický plán.

Národní architektonický rámec (NAR), jako metodický a myšlenkový rámec pro jednotný a koordinovaný popis Národní architektury VS ČR, obsahuje návody, postupy, předlohy a vzory tvorby, údržby a užití popisu architektury.

Národní architektonický rámec vychází z mezinárodně uznávaných standardů tvorby a údržby architektury úřadů TOGAF a ArchiMate, spravovaných The Open Group a užívaných jako východisko pro architekturu veřejné správy ve většině zemí.

NAR vydá a bude aktualizovat OHA MV, který bude v souladu s NAR koordinovat vznik a aktualizaci součástí NAP a zabezečí jejich centrální uložení a prezentaci vybraných znalostí z NAP, tj. například modelů a akčních plánů jednotlivých OVM, ve společné znalostní bázi a portálu NAP.

Definice, cíle a základní architektonické principy eGovernmentu ČR

Bude upraveno podle IKČR nebo odstraněno

Definice eGovernmentu jako moderní elektronicky podpořené veřejné správy:

„Veřejná správa je zajišťována sadou ICT služeb, které jsou sdílené, vzájemně sladěné, důvěryhodné, propojené, přístupné, bezpečné, dostupné a efektivní“.

Posláním eGovernmentu je:

„Co nejefektivnějším způsobem poskytovat klientům veřejné správy služby, co nejvíce jim usnadňující jak dosažení jejich práv a nároků, tak splnění jejich povinností a závazků ze vztahu k veřejné správě“.

Úlohou úřadů a úředníků, podporovaných informačními systémy, je být služebníky a rádci, průvodci klientů na cestě za splněním jejich povinností a dosažením jejich nároků.

Tyto definice vycházejí z toho, že Government je správní činnost související s poskytováním veřejných služeb, řízením veřejných záležitostí na místní i centrální úrovni a zajišťováním záležitostí ve veřejném zájmu. Pokud je poskytování veřejných služeb zajišťováno elektronicky a dochází k digitální interakci mezi veřejností a veřejnou správou hovoříme o eGovernmentu, elektronické veřejné správě, která využívá informační a komunikační technologie k poskytování elektronických veřejných služeb občanům a podnikům. V širším slova smyslu považujeme za eGovernment veškeré elektronizované procesy veřejné správy, včetně interního zpracování agend a provozních procesů.

Cílem veřejného zájmu jsou tedy rychlejší, dostupnější, spolehlivější a levnější služby veřejné správy, které jsou díky jejich elektronické formě lépe obsahově a procesně sladěné, jsou sdílené subjekty veřejné správy, důvěryhodné pro obě strany interakce, propojené za účelem pokrytí životních situací a dostupné odkudkoliv zabezpečenou formou komunikace.

IKČR navazuje zejména na cíle eGovernmentu formulované ve Strategickém rámci rozvoje veřejné správy ČR pro období 2014-2020 a jeho akčních plánech a ve Strategii rozvoje ICT služeb veřejné správy (usnesení vlády ze dne 2. listopadu 2015, č. 889).

Základní architektonické principy

Pouze odkaz na IKČR

Etapy naplňování cílové vize informatizace VS ČR

ke zvážení

Výchozí požadavky:

• IT systémy se mají konsolidovat, tj. má klesat jejich počet odstraňováním duplicit a nárůstem jejich sdíleného užívání
• I když jich zůstane mnoho, mají být propojeny a poskytovat konzistentní služby jako celek
• Budou federalizované (federované)
• Uplatní se účinná centrální IT governance (při zachování lokální zodpovědnosti)

Přes klesající počet postupně se vzájemně konsolidujících ISVS bude základem informatizace veřejné správy stále velký počet autonomních a modulárních řešení, které se však společně při podpoře dodávky externích služeb klientům VS nebo interních služeb pro úředníky budou chovat jako jeden propojený celek.

Konsolidace a transformace informatizace veřejné správy se podle této vize odehraje ve dvou velkých etapách.

První etapa, dosažitelná v blízkém horizontu jednotek let:

• Aplikační dekompozice monolitických řešení na procesně ucelené aplikační moduly, vhodné pro sdílení nebo záměnu, politicky (legislativně) parametrizovatelné a vytvoření Katalogu sdílitelných certifikovaných ICT služeb.
• Interoperabilita a integrace aplikací pro maximální využití propojeného datového fondu.
• Sdílení údajů mezi ISVS výhradně prostřednictvím PPDF (neveřejné údaje) nebo VDF (veřejné údaje, zveřejněné jako Otevřená data)

• Současně zahájení přesunu výpočetního výkonu zejména do Národních datových center, korporátních (resortní a krajských) datových center a do státní i soukromé části eGovernment Cloudu (IaaS, PaaS).
• Transformace IT útvarů úřadů z převážně provozního řízení na převážně strategické řízení IT a řízení nákupu a dodávky IT služeb svým klientům.

Druhá etapa, dosažitelná později:

• Postupná transformace a migrace sdílitelných aplikací do cloudové infrastruktury, odkud budou poskytovány jako sdílená služba (SaaS),
• Rostoucí integrace, automatizace a otevřenost i pro další poskytovatele (zprostředkovatele) veřejných služeb.
• Přesun další části výpočetního výkonu do eGov Cloudu, státního i soukromého.

Architektonická vize eGovernmentu ČR

Vize architektury veřejné správy představuje cílovou podobu, jak bude zhruba eGovernment ČR vypadat a fungovat, až se podaří realizovat podstatnou část opatření uvedených v této IKČR. Vize architektury veřejné správy zejména ukazuje, jak budou existující a dobudované pilíře eGovernmentu používány k realizaci užitečných služeb veřejné správy pro její klienty na jedné straně a pro efektivní správu jejích zdrojů na druhé straně.

V průběhu horizontu této IKČR tj. v letech 2018 až 2022, se budou stále více prosazovat níže uvedené trendy změn, směřující k cílové vizi eGovernmentu a jeho IT podpory.

Tato IKČR představuje vizi eGovernmentu, které navazuje a opírá se mimo jiné o následující vizi Akčního plánu eGovernmentu EU 2016-2020:

Do roku 2020 budou orgány veřejné správy a veřejné instituce v Evropské unii otevřené a měly by podporovat začlenění a všem občanům a podnikům v EU budou bez ohledu na hranice poskytovat uživatelsky vstřícné, účinné, komplexní digitální veřejné služby. Ke koncipování a poskytování lepších služeb, které vyhovují potřebám a požadavkům občanů a podniků, se budou využívat inovativní přístupy. Orgány veřejné správy budou využívat příležitosti, které jim nové digitální prostředí nabízí, aby usnadnily své interakce se zúčastněnými stranami i mezi sebou navzájem.

Formulování a naplňování takové vize je nikdy nekončící proces, jehož nedílnou součástí je efektivní informatizace, schopná inspirovat a následně realizovat IT podporu transformačních rozhodnutí politiků a vedení úřadů.

Celková architektonická vize informační podpory eGovernmentu

Veřejná správa ČR plně využije potenciál konsolidace a sdílení služeb na všech čtyřech vrstvách své architektury.

Architektura veřejné správy bude plně podporovat orientaci na služby klientům a přitom informačními technologiemi plně a rovnocenně jak klienta při samoobslužných funkcích, tak úředníka v asistenčních a interních funkcích.

Bude zdůrazněna zodpovědnost úřadů veřejné správy za kvalitu výkonu svých služeb. Z pohledu občana bude veřejná správa sjednocována do dvou základních vnímaných oblastí - jako služby státu, dostupné kdekoli (v přímé i přenesené působnosti, zcela bez místní příslušnosti), a služby samosprávy, srozumitelně spojené s místem života a s jeho lidským společenstvím (obcí).

Obě tyto klíčové kategorie individuálních věcných služeb veřejné správy pro klienty budou prezentovány v univerzálních i místních kontaktních místech pomocí tzv. Katalogů služeb, orientovaných primárně na řešení životních událostí klientů.

Současně a v návaznosti na to budou přibývající centrální a sdílené ICT služby publikovány pro potřeby řízení informatiky úřadů v podobě Katalogu ICT služeb veřejné správy. Prvním a základním předobrazem tohoto katalogu je tato Informační koncepce.

Klíčovým trendem optimalizace veřejné správy bude hledání jednoty a podobnosti a hledání potenciálu k úsporám a efektivitě pomocí sdílení, a to na všech vrstvách architektury veřejné správy.

To ukazuje následující schéma, stavící do kontrastu a ke vzájemnému doplnění místní individuální funkce úřadu a odpovídající sdílené funkce. Potenciál pro poskytování a využívání sdílených služeb, a to jak centrálních, korporátních (v ministerstvu, kraji nebo ORP) nebo místních služeb, sdílených celým úřadem, existuje na všech úrovních veřejné správy a ve všech vrstvách architektury veřejné správy.

605x362px

1. Potenciál sdílení na všech vrstvách architektury veřejné správy a jednotlivých úřadů

Podstata změn v byznys architektuře

Další vývoj eGovernmentu zavádí transakční samoobsluhu pro subjekty práva a její efektivní asistovanou alternativu pro elektronicky handicapované .

Individuální služby veřejné správy, představující konkrétní výstup procesů výkonu veřejné správy, prostřednictvím kterého klient (občan nebo zástupce organizace) využívá svá legislativní oprávnění (nároky) nebo naplňuje své legislativní povinnosti (závazky), budou stále více zaměřeny na praktické řešení individuální životní situace, která klientovi ve vztahu k veřejné správě nastala nějakou životní událostí, ať již z jeho vůle, z moci úřední, působením třetí osoby nebo z vyšší moci.

Součástí této změny bude rychle rostoucí podíl těchto služeb, které bude moci klient získat a být obsloužen v univerzálních kontaktních místech, ať již samoobslužných (jako Portál občana v PVS, a to v internetu a mobilní) nebo asistovaných (jako CzechPOINT, Call-centrum veřejné správy a také univerzální přepážky úřadů územních samospráv).

Všechny služby veřejné správy tedy musí být postupně upravovány tak, aby byly rovnocenně kdykoli a odkudkoli dosažitelné všemi obslužnými kanály.

Všechny lokální a resortní agendové portály (jako ePortál, Portál farmáře, eAgri, BusinesInfo, EPO, eHealth a eJustice, a další) budou postupně ve federativním uspořádání připojeny k centrálnímu PVS-Portálu občana, který tak bude jediným společným vstupním bodem ke všem elektronickým službám VS ČR.

Elektronické služby budou důsleně realizovány v autentizovaných prostorech obslužných kanálů, s plným využitím předvyplněných údajů z propojeného a z veřejného datového fondu VS. Elektronizace obsluhy klientů a výměny informací ve veřejné správě bude řešena tak, že bude přirozenou součástí práce úředníků, nebude je nijak zatěžovat navíc, nýbrž naopak jejich práce bude elektronizací usnadněna a urychlena, a to jak při:

• vlastním výkonu agendových služeb nebo služeb pro řešení životní situace
• výměně informací mezi úřady
• asistenci klientům při podání nebo převzetí dokumentů
• interních provozních úkonech zaměstnance a úřadu.

Elektronické služby pro klienty budou vycházet z jednotné a státem garantované elektronické identifikace občanů ČR (NIA) a identifikací občanů EU (eIDAS).

Důležitou roli ve zvyšování právního povědomí občanů i úředníků sehrají služby eSbírka a eLegislativa, jako jedny z klíčových znalostních systémů eGovernmentu.

Otevřená data se stanou pro orgány veřejné správy přirozeným a primárním způsobem zveřejňování informací, které jsou evidovány v ISVS při výkonu agend a lze je poskytovat veřejnosti jako informace podle zákona č. 106/1999 Sb., o svobodném přístupu k informacím, nebo podle zvláštních předpisů, jako je kupříkladu zákon 123/1998 Sb., o právu na informace o životním prostředí.

Otevřená data se též stanou pro orgány veřejné správy primárním způsobem získávání veřejných informací potřebných při výkonu agend, které jsou evidovány jinými orgány veřejné správy při výkonu jejich agend evidovány v jimi spravovaných ISVS.

V oblast provozních procesů veřejné správy bude pokračovat jejich korporátní i celostátní sjednocování a centralizace, s možností vzniku korporátních i celostátních center sdílených služeb, zejména v oblastech účetnictví a rozpočetnictví, nákupu a logistiky, personalistiky a mezd, správy majetku, informačních technologií, právních a komunikačních služeb apod.

Bude se zvyšovat míra vnitřní elektronizace provozních procesů i elektronická výměna dokumentů v obchodním styku, nejdříve pak zavedení eFakturace. Dostatek včas dostupných elektronických provozních a ekonomických informací povede k další optimalizaci a automatizaci provozních procesů (správa nemovitostí, controlling atd.)

Společně s tím poroste v těchto oblastech podíl samoobslužně elektronicky vykonávaných procesů, tzv. zaměstnaneckých samoobsluh, tak, aby do konce horizontu této koncepce byly procesy týkající se jednotlivých zaměstnanců, jejich vybavení a pracovního prostředí plně elektronické, tj. bezpapírové, s výjimkou samozřejmé podpory elektronicky handicapovaných zaměstnanců. Tyto vnitřní elektronické služby budou vycházet z jednotné identity úředníků v rámci tzv. autentizačního informačního systému podle § 56a zákona o základních registrech (JIP/KAAS) a budou postupně formovat jednotný Portál úředníka a naplňovat ho obsahem.

Byznys architektura úřadů, zejména pak přehledová mapy schopností či procesů, se stane východiskem pro návrhy, plánování a řízení transformačních změn úřadů směrem k naplňování této vize, ale také východiskem pro navazující detailní modelování a optimalizaci procesů a služeb veřejné správy pro řešení životních událostí klientů, pro řízení a zlepšování výkonnosti a kvality těchto služeb a zodpovědnosti za ně.

Veřejná správa se při řízení celého úřadu naučí nesoustředit se na jednotlivé nepropojené celky, ale naopak na co největší komplexitu při rozhodování i při výkonu veřejné správy. Znamená to především, že se naučí myslet v tzv. “multiagendovém přístupu”, tedy, že veškeré procesy, které lze použít ve více agendách, budou takto použity, a naopak u procesů, kde to zatím nelze, se bude hledat řešení, jak toho docílit. Cílem je poskytování komplexní služby klientovi, nehledě na to, v jaké je to agendě, nebo jaké prostředky jsou na poskytování služby vázány.

Za tímto účelem se bude v úřadě prosazovat architektura jako celostní disciplína jdoucí napříč celým úřadem - a de facto i nad něj - a také se zavde řízení procesů napříč všemi agendami, nikoliv po jednotlivých agendách či souborech činností. To znamená i zvýšení spolupráce odborných gestorů v úřadu mezi sebou.

Konkrétně je třeba nanejvýš vhodné společné činnosti a principy dělat v celém úřadě opravdu tak, aby byly společné. Kupříkladu, principy výkonu spisové služby jsou stejné pro celý úřad a pro všechny agendy, i když v jednotlivých agendách mohou být samozřejmě odlišnosti (jiný AIS integrovaný na ESSL apod.), nicméně budou nastaveny společné principy, a ty také společně kontrolovány. To samé platí o ekonomice, rolích úředníků apod.

Podstata změn v aplikační architektuře

Informační systémy veřejné správy budou primárně sloužit pro podporu výkonu veřejné správy nebo pro samotný výkon veřejné správy. Budou poskytovat vhodné prostředky a funkce pro úředníka, který je zodpovědný za výkon činností v daných agendách nebo pro klienta, který se samoobslouží. Ideální informační systém by měl úředníka či klienta provázet jeho činnostmi a v maximální míře mu jeho práci usnadnit, třeba automatizováním činností, u kterých je to možné.

Neznamená to primárně plně automatizované rozhodování veřejné správy, ovšem maximální usnadnění rozhodování úředníkům a obsluhy klientům. Úředník nemá čas trávit administrativou, nebo dokonce získáváním či ověřováním rozhodných skutečností, to za něj bude dělat systém, ať už na základě žádosti či práva subjektu údajů, nebo z moci úřední. Informační systém úředníkovi nabídne vždy relevantní informace a podklady pro rozhodování, je-li vůbec správní rozhodování v dané věci na místě. Výsledkem pak bude možnost připravit úředníkovi rozhodnutí v dané věci s využitím aktuálních a relevantních údajů.

Část změn aplikační architektury bude vyplývat přímo ze změn byznys architektury výkonu služeb veřejné správy. Tzn., že aplikace na podporu těchto služeb budou stále jednotnější z hlediska podpory řešení životních situací napříč resorty a napříč obslužnými kanály.

Aplikační podpora jednotlivých tzv. elementárních nebo atomických služeb veřejné správy musí být realizována tak, aby cílově bylo možno tyto služby dynamicky procesně orchestrovat do univerzálních obslužných kanálů kontaktních míst veřejné správy pro konfigurovatelné (složené) služby komplexního řešení individuálních životních situací klientů VS a otevřít je poskytovatelům služeb třetích stran pomocí otevřených API.

Aplikační podpora bude realizována tak, aby zajišťovala zveřejňování údajů jako otevřená data a umožnila využívání otevřených dat ostatními orgány veřejné správy, pro jejichž potřeby je především nutno zajistit dostupnost otevřených dat.

Dále budou aplikace AIS upraveny tak, aby podporovaly službu pro subjekt práva s elektronickou identifikací, poskytující mu všechny údaje, které jsou o něm vedeny v neveřejných evidencích, jak ji přináší novela zákona o ISVS, účinná od 1. 7. 2018.

Sjednotí se a budou silně konsolidovat jak aplikace na podporu klienta, zejména celostátní Portál občana v PVS, i s ním federalizované portály ústředních správních úřadů a portály samospráv, tak aplikace na podporu práce úředníka, zejména transakční Portál úředníka, umožňující navigaci a jednotný uživatelský zážitek ke všem klíčovým systému úřadu, kde úředník působí a postupně i k rostoucímu množství do Portálu úředníka integrovaných služeb centrálních sdílených interních informačních systémů veřejné správy.

Před integrací v obslužných aplikacích občana a úředníka, tzv. Front-Office integrace, má přednost integrace výměnou elektronických informací mezi úřady, tzv. Back-Office integrace.

Bude docházet ke generační obnově velkých agendových systémů, jejich komponentizaci a flexibilnímu otevírání službám více dodavatelů.

Současně bude v úřadech samotných napříč agendami, i v celém eGovernmentu napříč úřady a resorty identifikováno stále více aplikačních služeb, které budou poskytovány jako centrální sdílené služby, a to zejména jako sdílené služby eGovernment cloudu.

Příkladem jsou ISVS pro podporu služeb, realizovaných v přenesené působnosti. Výrazně se zvýší zodpovědnost úřadu ohlašovatele agendy za aplikační podporu agendy i zodpovědnost za data agendy. Tato koncepce předpokládá, že každý ohlašovatel agendy s přenesenou působností se stane věcným a technickým správcem odpovídajícího centrálního elektronického registru (agendového IS), připojeného k Propojenému datovému fondu. Společně s přenesením agendy na úřady územních samospráv (KÚ, ORP, obce) nabídne pro jejich uživatele jím garantovanou dostupnou centrální aplikační službu, integrovatelnou s lokálními systémy (zejména eSSL, ERP) úřadu. V žádném případě není možné požadovat dvojí pořizování dat, samosprávní úřad může užívat i lokální aplikaci, pokud bude odpovídat za její legislativní přizpůsobování a bude využívat nabídnuté datové rozhraní na centrální ISVS (registr) takové služby. Ohlašovatel agendy prostřednictvím jím garantované centrální aplikační služby též zajistí poskytování údajů vedených v centrální aplikační službě v podobě otevřených dat.

Úměrně sjednocování a centralizaci provozních procesů veřejné správy na úroveň korporací a státu se budou sjednocovat, případně konsolidovat, případně centralizovat aplikace podporující tyto procesy. Podstatnou součástí změn v těchto aplikacích bude rapidně rostoucí podpora zaměstnaneckých samoobsluh.

S rozvojem eGovernment cloudu poroste nabídka SaaS služeb eGC (Software as a Service, služby na aplikační úrovni), zaměřená zejména na standardizované implementace provozních informačních systémů (jako je e-mail, eSSL, ERP, PIS) a standardní agendy obcí. Na SaaS služby eGC budou kladeny stejné architektonické požadavky jako na ISVS provozované on-premise.

Podstata změn v datové architektuře

Bude se výrazně rozšiřovat rozsah dostupných referenčních a zejména autoritativních údajů v rámci propojeného (státního) datového fondu ČR.

V souvislosti s rostoucí výměnou elektronických údajů a zodpovědností za jejich kvalitu, i s jejich rostoucím ohrožením a ochranou, dojde k podstatnému nárůstu IT profesí, spojených se správou dat a údajů.

Bude docházet k posunu zaměření úsilí od stávajícího soustředění na referenční údaje, přes transakční údaje a dokumenty, k analytickým a statistickým údajům a efektivní podpoře jejich automatizovaného sběru a využití při řízení veřejné správy.

V případech, kde zákon umožňuje zveřejnění údajů o subjektech a objektech práva vedených v základních registrech či jejich rozšíření ve smyslu výše uvedeného, budou tyto údaje poskytovány v podobě otevřených dat a v podobě propojených otevřených dat.

Na podporu národní i mezinárodní interoperability služeb veřejné správy bude docházet k postupnému sjednocování prvků konceptuálních datových modelů datového fondu jednotlivých ISVS a úřadů a jim odpovídajících legislativních pojmů.

Sémantický slovník pojmů jako prostředek harmonizace sémantiky dat vedených v jednotlivých ISVS bude vytvářen na bázi výčtů údajů vedených k agendám v Registru práv a povinností dle § 51 odst. 5 písm. g), h) a i) zákona o základních registrech a bude je postupně rozpracovávat do podoby sdílených informačních modelů (ontologií), které budou propojeny na údaje vedené k agendám a též propojovány se slovníky a ontologiemi vznikajícími z iniciativy EU (např. ISA Core Vocabularies). Logická schémata dat vedených v ISVS popisujících jejich strojové (syntaktické) vyjádření na logické úrovni budou propojena na pojmy sémantického slovníku pojmů, čímž bude realizováno propojení sémantiky (významu) dat napříč jednotlivými ISVS. Díky propojení sémantického slovníku pojmů na údaje vedené k agendám a jejich propojení na legislativu bude též realizováno propojení sémantiky s legislativou.

Sémantický slovník pojmů bude využíván především pro otevřená data. Údaje zveřejňované jako otevřená data budou muset být opatřena publikovaným logickým schématem popisujícím strojově čitelným způsobem jejich datové struktury. Prvky logického schématu pak bude možné propojovat strojově čitelným způsobem na sémantický slovník pojmů a propojení publikovat jako otevřená data.

S využitím sémantického slovníku pojmů bude rozšířena funkcionalita NKOD o zobrazování kvalitnější dokumentace sémantiky datových sad a širší možnosti vyhledávání souvisejících datových sad. Konzumenti otevřených dat budou využívat sémantický slovník pojmů pro integraci otevřených dat získaných od různých poskytovatelů.

Podstata změn v IT technologické architektuře

Zásadním trendem na úrovni technologické vrstvy je využití sdílených platforem výpočetního výkonu a datových úložišť, a to jak on-premise (virtualizace), tak v prostředí cloudových služeb.

eGovernment cloud nabídne ekonomicky výhodné, standardizované a bezpečné služby sdílených platforem (PaaS – na úrovni operačních systémů a databází) a infrastrury (IaaS – výpočetní výkon, datová úložiště, umístění v DC). Postupně tak bude docházet k využití služeb eGC pro všechny ISVS a provozní informační systémy (migrace do eGC). To umožní úřadům kompletně oddělit „komoditní“ komponenty architektury informačních systémů a zaměřit své síly na specifické komponenty, které souvisejí s jejich agendami a kompetencemi.

Bude pokračovat budování sítě státních center sdílených služeb a regionálních datových center propojených bezpečnou datovou komunikační infrastrukturou, která budou poskytovat sdílené ICT služby orgánům veřejné správy.

Svou úlohu budou i nadále plnit současně provozovaná a nově budovaná Národní datová centra, která splní kvalifikační předpoklady. Do takových NDC budou umísťovány především všechny centralizované ISVS pro služby státní správy v přenesené působnosti, poskytující své aplikační služby přes CMS.

Obě formy sdílených technologických služeb (NDC a eGC) se budou vzájemně doplňovat, IKČR zdůrazňuje jejich kompatibilitu a provázanost.

Pro zajištění dostupnosti otevřených dat poskytovaných z ISVS za účelem jejich využívání v jiném ISVS bude vytvořeno společné úložiště v rámci NDC nebo eGC.

Podstata změn v komunikační infrastruktuře

Rozvoj bezpečné a spolehlivé komunikační infrastruktury CMS/KIVS zabezpečí splnění rostoucích nároku OVS na bezpečnou publikaci aplikačních služeb státu a přístup k nim, jak pro klienty VS, tak i pro jednotlivé OVS.

Architektura a sdílené služby veřejné správy ČR

Tato kapitola nahlíží na architekturu veřejné správy ČR tzv. „shora“ a přináší jak definice klíčových pojmů a prvků architektury VS, tak přehled centrálních sdílených služeb eGovernmentu, dostupných pro použití v lokálních architektách úřadů.

Základní pojmy a prvky architektury veřejné správy ČR

Základní pojmy architektury VS ČR

Tato kapitola Informační koncepce ČR shrnuje jednotlivé pojmy, smysl a postupy, které vedly ke vzniku této koncepce. V rámci koncepce používáme některé pojmy poněkud volněji než v odkazovaných zákonných předpisech, primární je totiž postižení smyslu a účelu těchto pojmů z hlediska popisu architektury VS ČR na všech jejích úrovních.

• Orgán veřejné správy (OVS)
  • státní orgán nebo orgán územních samosprávných celků
• Orgán veřejné moci (OVM)
  • státní orgán, územní samosprávný celek a fyzická nebo právnická osoba, byla-li jí svěřena působnost v oblasti veřejné správy,
• Soukromoprávní uživatel údajů (SUU)
  • podnikající fyzická osoba nebo právnická osoba, která není orgánem veřejné moci a je podle jiného právního předpisu oprávněna využívat údaje ze základního registru nebo z agendového informačního systém.

Informační systémy veřejné správy (zákon o ISVS)

• ISVS je 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.
• Správce ISVS je osoba nebo její součást, která poskytuje služby informačního systému veřejné správy a za informační systém veřejné správy odpovídá.
• Provozovatel ISVS je osoba nebo její součást, která zajišťuje funkčnost technických a programových prostředků tvořících informační systém veřejné správy.
• Uživatel ISVS je osoba nebo její součást, která do informačního systému veřejné správy zapisuje data nebo data, případně i provozní údaje obsažené v informačním systému veřejné správy, využívá.

Agendy

• Agenda je ucelená oblast působnosti orgánu veřejné moci nebo ucelená oblast působení soukromoprávního uživatele údajů,
• Ohlašovatel agendy orgán veřejné moci, který ohlašuje agendu pro potřeby její registrace
• Kategorie OVM je skupina orgánů veřejné moci nebo soukromoprávních uživatelů údajů, kteří vykonávají stejné činnosti v ohlášených agendách
• OVM / SUU působící v agendě je OVM nebo SUU vykonávající agendu a v agendě registrovaný buď identifikátorem OVM / SUU nebo kategorií OVM / SUU

Agendové informační systémy

• Agendovým informační systém (AIS) je ISVS, který slouží k výkonu agendy, využívání elektronických formulářů nebo elektronické identifikaci
• Správce AIS je OVM - správce ISVS který je buď ohlašovatelem příslušné agendy (centralizovaný AIS) nebo v agendě působí (decentralizovaný AIS)
• Soukromoprávní uživatel údajů (SUU) přistupuje pouze prostřednictvím AIS, který vybuduje ten, kdo má zákonné zmocnění.

Souhrn klíčových pojmů, se kterými IKČR pracuje, je obsahem Dodatku 9 - Klíčové pojmy eGovernmentu ČR.

Domény Národní architektury veřejné správy

ke zvážení – možná ponechat jenom v NAR

Pro modelování Národního architektonického plánu VS ČR i pro formulování principů a pravidel IKČR využívá následující architektonické domény architektury úřadů (a celé veřejné správy ČR), viz obrázek 2 níže.

420x244px

2. Struktura domén Národního architektonického plánu (EA)

Architektonické domény jsou děleny na horizontální domény (také nazývané vrstvy), odpovídající čtyřvrstvé vizi architektury VS a na vertikální domény, představující složky motivace a governance veřejné správy.

Horizontální domény (vrstvy) základních prvků architektury:

• Byznys architektura – tedy architektura všech součástí výkonu veřejné správy a podpůrných provozních funkcí, zejména zaměřená na působnost OVM, služby, procesy, organizaci, role a zodpovědnosti.
• Architektura informačních systémů, členěná na:
  • Informační (datovou) a
  • Aplikační architekturu
• Technologická architektura, pro potřeby VS ČR dále dělená dle čtyřvrstvé vize architektury na:
  • architekturu IT technologií, také zvanou platformovou a
  • architekturu komunikační infrastruktury a datových center

Vertikální domény motivačních složek architektury:

• Architektura strategie a směrování, původně také zvaná motivační architektura (v užším smyslu), nyní jedna ze složek motivace úřadu
• Architektura výkonnosti, s měřítky dosahování strategie i provozní efektivity
• Architektura rizik a bezpečnosti, postihující specifické bezpečnostní atributy napříč doménami včetně požadavků na kybernetickou bezpečnost
• Architektura shody s pravidly a udržitelnosti, obsahující všechny prvky regulace fungování úřadů, od právních předpisů, přes normy a standardy až po vlastní zásady udržitelnosti.

Poslední doménou modelování je světle červená oblast v obrázku č. 2, která představuje tzv. akční plán architektury úřadu (Roadmap) a umožňuje vizualizovat balíčky práce, projekty a jimi dosahované stavy architektury (přechodné a cílové).

Přístup k popisu architektury VS ČR

Koncepce nemá za cíl definovat vše, co se týká veřejné správy, ale jen vymezenou část týkající se principů návrhu řešení ISVS a procesů správy (životního cyklu) ISVS v kontextu působnosti OVM – správce ISVS.

IKČR popisuje nejen samotné ISVS, ale i procesy a agendy, které ISVS podporuje, služby, které ISVS poskytuje, hardware (též HW) a software (též SW), který ISVS využívá a infrastrukturu, prostřednictvím které ISVS fyzicky komunikuje s okolím – vše s využitím nástrojů architektury úřadu (obecně Enterprise architektury, dále jen „EA“).

Veřejná správa funguje na odlišném principu než soukromoprávní subjekty. Výkon veřejné správy se řídí zásadou, dle které veřejná moc může konat jen tehdy, stanoví-li to zákon, a jen způsobem stanoveným zákonem. Jinými slovy, co není zákonem povoleno, je zakázáno. Proto jako první součást řízení dlouhodobého rozvoje ISVS musí být legislativní / právní vymezení (viz Dodatek A).

Dekompozice a kontexty ISVS:

• Každý ISVS má prvky ze všech čtyřech vrstev architektury
• Na každé vrstvě architektury obsahuje ISVS více různých prvků (aktivních, pasivních a chování), které je třeba identifikovat, klasifikovat a řídit
• ISVS nikdy není izolován, vždy je součástí architektury větších celků, a to:

• úřadu, jednotlivé organizace,
• korporace, resortu nebo územního celku (kraje a obce),
• veřejné správy ČR,
• veřejné správy EU.

Čtyři vrstvy služeb ISVS znázorňuje následující obrázek:

161x219px

3. Typové služby na čtyřech úrovních architektury veřejné správy

Na všech vrstvách architektonické dekompozice struktury a služeb ISVS je potřeba při plánování a řízení jeho vybudování nebo následného rozvoje mít znalosti a činit rozhodnutí zejména v následujících otázkách:

1. Podporované agendy/služby veřejné správy jsou?

• Centrální nebo lokální procesy
• Vlastní nebo sdílené služby
• Speciální nebo univerzální obslužné kanály
• Asistované nebo on-line služby
• Využívají sdílené údaje: Propojený a Veřejný datový fond (PPDF a VDF)

2. Informační systémy (Aplikace a data)

Aplikace

• Logicky centralizované / distribuované
• Vyvinuté na zakázku / Off the Shelf
• On Premise (vlastní) / Cloud (pronajaté)

Data

• Referenční, autoritativní a vlastní data spravovaného ISVS

3. Platformy

• Platformy (Databáze, Aplikační servery apod.)

• On Premise / NDC / Cloud

• Výpočetní výkon a datové úložiště

• On premise / NDC / Cloud

4. Infrastruktura

• Datové centrum

• On premise / NDC / Cloud

• Síťové připojení do eGovernmentu

• (KIVS, komerční DC a Internet), CMS

Podstatné principy základních prvků eGovernmentu následují popsané po jednotlivých vrstvách architektury VS a poté podle jednotlivých klíčových tematických okruhů.

Přístup k popisu byznys architektury eGovernmentu

Výkon a služby veřejné správy byly dlouhou dobu poskytovány v místě příslušného OVM jeho úředníky - tuto formu vládnutí můžeme nazvat cizím názvem „Government“. S rostoucím využitím informačních technologií se z „obyčejného“ Governmentu stává jeho elektronická forma eGovernment neboli elektronické vládnutí či vládnutí za pomoci elektronických prostředků. Jinými slovy, základní zdroje každého OVM (úředníci, úřadovny, budovy atd.) jsou rozšířeny o prvky elektronického vládnutí. Některé z těchto prvků si spravuje samo OVM, jiné využívá jako sdílenou službu ve správě jiného OVM.

Například:

1. Základní registry - Dle zákona o základních registrech (č. 111/2009 Sb.) OVM, působící v určité agendě, a spravující pro výkon této působnosti agendový informační systém (AIS) a vede v tomto AIS údaje dle zákonného zmocnění, má právo a povinnost na čerpání (využívání) referenčních údajů ze základních registrů, aniž by ověřoval jejich správnost, natož pak požadoval poskytnutí těchto údajů od subjektů práva. Tedy datový kmen samotného úřadu je rozšířen pro evidované subjekty a objekty práva o referenční údaje ze ZR se zaručnou platností.
2. Elektronická identita - Dle zákona o elektronické identifikaci (č. 250/2017 Sb.), účinného od 1. 7. 2018, provádí úřad resp. jím spravovaný ISVS identifikaci a autentizaci klienta veřejné správy, o kterém vede údaje pomocí Národního bodu elektronické identifikace s definovanou úrovní záruky (tzv. Level of Assurance „LoA“). Jednotlivé úřady tedy jako sdílenou centrální službu státu dostávají identifikaci a autentizaci klientů – fyzických osob, nemusí se starat o vydávání identifikačních prostředků ani jejich využívání v procesu identifikace a autentizace fyzických osob.
3. Elektronické úkony a doručování - Zákonem č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, byla všem OVM zřízena navíc ke stávajícím obslužným kanálům datová schránka. OVM byla uložena povinnost přijímat úkony učiněné datovou schránkou jinými FO nebo PO a doručovat jiným PO nebo FO primárně do existující datové schránky. Každý úřad tak získal centrální, státem zdarma poskytovanou, službu elektronického podání a doručení s definovanými právními účinky.
4. Poskytování údajů - Klient má právo na poskytování o něm vedených údajů z informačních systémů úřadů, což upravuje zákon o ISVS a od 1. 7. 2018 řeší mj. tzv. Portál občana, což bude transakční část portálu veřejné správy (dále také „PO“ a „PVS“) s využitím publikace povinných údajů z ISVS přes eGovernment Online Service Bus (dále také „eGSB“). Jednotlivý úřad využívající se sebou spravovanými ISVS tento způsob publikace nebude muset řešit tuto povinnost samostatně.
5. Zveřejňování informací - Orgány veřejné správy zveřejňují informace dle zákona č. 106/1999 Sb., o svobodném přístupu k informacím, nebo dalších zvláštních předpisů upravujících poskytování informací veřejnosti, například zákona č. 123/1998 Sb., o právu na informace o životním prostředí, jako otevřená data. Pro zveřejňování otevřených dat zajišťuje stát pro všechna OVS službu Národního katalogu otevřených dat (NKOD).

Působnost úřadu je definována jemu legislativně přiznanou působností v jednotlivých agendách. Každou z agend působnosti úřadu je pak účelné rozdělit na procesy a funkce dle v obrázku níže uvedených kategorií. Působnost úřadu je potom tvořena kompozicí jednotlivých agend, které se v jednotlivých procesech a funkcích překrývají a mohou je sdílet.

602x165px

4. Základní procesní (funkční) součásti každé agendy

Obecně platí, že:

• Agenda je tvořena přinejmenším výše uvedenými kategoriemi funkcí a služeb
• Z rozdílných vlastností jednotlivých kategorií funkcí v agendách vyplývají nároky na jejich různou aplikační podporu a přirozená komponentizace ISVS
• Mnohé z agendových funkcí mají být v rámci organizace mezi agendami sdíleny, například obslužné kanály a agendové zázemí (kmenová data, platební styk, účetnictví agend, apod.)
• Na rozdíl od doručování dokumentů se výměna údajů nerealizuje prostřednictvím správy případů, spisů a dokumentů.

Ve vztahu agendy k ostatním kategoriím procesů a funkcí úřadu platí přinejmenším tato pravidla:

• Zatímco odborné agendové procesy (tzv. Middle-Office) zůstanou specifické, ostatní procesy by měly být v úřadu jednotné a sdílené
• Obdobně to platí pro všechny ostatní vrstvy architektury (aplikace a data, IT technologie a komunikační infrastruktura), které své služby staví právě na podporu výkonu byznys procesů úřadu a kopírují odvozeně jejich strukturu a potřeby.

Přístup k popisu architektury informačních systémů eGovernmentu

Obsahová (funkční) podpora služeb veřejné správy (jednotlivých agend) službami informačních systémů je předmětem tzv. Aplikační vrstvy architektury veřejné správy. Součástí aplikační vrstvy jsou i údaje a jejich metadata udržované v těchto informačních systémech.

Přestože zákon o ISVS hovoří o informačním systému veřejné správy tak, že chápe a eviduje ISVS jednotlivě jako jeden monolitický celek, tato IKČR ukazuje, že tak ISVS vystupuje pouze z pohledu logické podpory jedné agendy funkcemi informačních technologií. ISVS má přirozeně svoji strukturovanou vnitřní výstavbu a pro správné plánování rozvoje jednotlivých ISVS úřadu i celého aplikačního portfolia úřadu je nutné aplikační strukturu každého ISVS procesně orientovaným způsobem dekomponovat do logických celků, kterým by měly odpovídat i fyzické aplikační komponenty. Jejich vzájemné integrace a spolupráce pak tvoří logický ISVS. Dlouhodobě řídit ISVS ve skutečnosti znamená řídit životní cyklus jeho jednotlivých komponent.

Na druhou stranu, pokud jeden ISVS potřebuje pro své funkce několik komponent, nikde není předepsáno, že je nutné obdobné komponenty (například komunikace s klienty ve Front-Office nebo příjem plateb v Back-Office) budovat pro každý logický ISVS vždy znovu a znovu. Naopak základní pravidlo této IKČR stanovuje, že:

Obdobné, funkčně použitelné komponenty musí být v úřadu mezi jeho jednotlivými ISVS vždy sdíleny a nesmějí se budovat nebo udržovat v provozu vícenásobně, pokud se neprokáže jinak (například z důvodu odlišné dostupnosti nebo odlišné ochrany údajů).

Vedle agendových informačních systémů (AIS) a IS spisových služeb má každý úřad celou řadu typů IS, jejichž podrobnější třídění a odpovídající pravidla pro jejich návrh a správu zavádí IKČR také.

603x466px

5. Typické kategorie aplikačních komponent, tvořící každý jednotlivý ISVS.

Procesní (byznys) dekompozice ISVS na aplikační vrstvě v kostce:

• Většina agendových ISVS obsahuje aplikační podporu více různých procesních kategorií výkonu VS a využívá k tomu aplikačních funkcí poskytovaných více aplikačními komponentami z více kategorií, viz vysvětlení dále.
• Velmi často (přinejmenším u agend s obsluhou občanů) jsou součástí ISVS funkce ze silně orámovaných kategorií na obr. výše, tj. Front-office, Middle-Office, Back-Office a Spisové služby.
• Mnohé aplikační komponenty ISVS by měly být mezi jednotlivými ISVS (a jejich agendami) v úřadu, korporaci nebo finálně eGovernmentu, sdíleny úměrně tomu, jak lze sjednocovat a sdílet podporované procesy, viz dekompozice agendy. Toto sdílení bude přednostně realizováno u společných obslužných komponent (Front-Office)a společných komponent agendového zázemí (Back-Office).

Dle svého významu pro výkon veřejné služby a ochranu údajů rozlišuje zákon o kybernetické bezpečnosti informační systémy na kritické a významné, přičemž jednotlivé kategorie se musí řídit jednoznačnými pravidly tohoto zákona.

Obdobně zavádí IKČR povinnost klasifikace v ISVS evidovaných údajů (datového kmene a transakčních údajů) a pravidla pro jejich správu a zveřejňování v podobě otevřených dat.

Protože ISVS zpracovávají téměř bezvýjimečně osobní údaje, musejí od 25. 5. 2018 naplňovat kromě požadavků zákona č. 101/2000 Sb., o ochraně osobních údajů, rovněž požadavky, které na ně klade nařízení Evropského parlamentu a Rady č. 2016/679, obecné nařízení o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (zkráceně: Obecné nařízení o ochraně osobních údajů (anglicky General Data Protection Regulation - GDPR). Zejména se jedná o zásady zajištění zabezpečení před možným únikem a zneužitím přítomných osobních údajů, a zásady záměrné a standardní ochrany osobních údajů ve smyslu čl. 25 nařízení GDPR.

ISVS a další IS ve veřejné správě se pro účely IKČR dělí z pohledu sdílených služeb na:

• ISVS poskytující sdílené služby eGovernmentu, viz také níže seznam a popis sdílených prvků eGovernentu, a to zejména

• IS pro sdílené služby při výkonu externích služeb veřejné správy
• IS pro sdílené služby správy zdrojů veřejné správy
• IS pro sdílené služby agend v přenesené působnosti
• IS pro celoplošný agendový portál a další

• ISVS a IS poskytující lokální služby OVS (a převážně čerpájící sdílené služby eGovernmentu), a to zejména

• Agendové IS pro vlastní a samosprávnou působnost
• IS pro lokální agendové a místní portály
• IS pro spisovou službu
• Provozní IS pro správu zdrojů
• a další

Z pohledu zodpovědností správce jsou i celoplošné ISVS pro sdílené služby eGovernmentu součástí lokální architektury konkrétního OVS jejich správce, a musejí být spravovány v jejím kontextu.

Přístup k popisu technologické architektury eGovernmentu

Poskytnutí dostatečného výpočetního výkonu, úložných kapacit, zabezpečení, vývojového prostředí a další služby poskytuje pro fungování IS ve veřejné správě vrstva technologické infrastruktury. Poskytování sdílených služeb výpočetního výkonu a úložných kapacit pro OVS je předmětem projektu eGovernment Cloudu (eGC), realizovaného podle příslušného usnesení vlády ČR, jehož výstupy budou do IKČR průběžně doplňovány.

Přístup k popisu komunikační architektury eGovernmentu

Všechny služby sdílených prvků eGovernmentu a ISVS navzájem musí být poskytovány po bezpečné síťové infrastruktuře (KIVS) a prostřednictvím jednoho centrálního místa přístupu k těmto službám (CMS).

Informační systém VS v kontextu Národní architektury VS

Struktura a funkce ISVS, tj. obsah všech horizontálních i vertikálních domén jeho architektury, musí být vnímána a rozvíjena ve všech souvislostech. Tyto souvislosti jsou dány zejména prostředím, v němž se ISVS nachází a jemuž v důsledku slouží. Tj. zejména prostředí Orgánu veřejné správy, jeho celé korporace a všech vyšších úrovní veřejné správy včetně centrálních sdílených prvků eGovernmentu.

Zjednodušeně lze tyto souvislosti vyjádřit schematicky jako architekturu ISVS v kontextu (jako součást) architektur OVS a architektury eGovernmentu, viz obrázek:

604x248px

6. Architektura ISVS v kontextu architektur úřadu, korporace a eGovernmentu ČR

Záměrně byla pro zjednodušení opominuta například architektura prvků veřejné správy na úrovni EU a architektura prostředí typického (typového) klienta veřejné správy, občana a organizace.

Klíčové tématické okruhy eGovernmentu a jeho IT podpory

 Základní pilíře a budoucí směry rozvoje eGovernentu lze postihnout následujícími klíčovými tématickými okruhy, zahrnutými do architektonické vize eGovernmentu, a odpovídajícími centrálními prvky IT řešení, jejichž prostřednictvím jsou poskytovány sdílené služby eGovernmentu v jednotlivých okruzích témat a jejichž využití v architekturách úřadů je nebo bude na základě obecných nebo speciálních předpisů povinné.

Dostupné, aktuálně budované a v této IKČR plánované sdílené služby eGovernmentu lze tak řadit do následujících kategorií, respektive tematických okruhů:

• Agendová mapa veřejné správy a RPP - poskytující základní popis a metadata pro elektronické úřadování a sdílení údajů
• Úplné elektronické podání (ÚEP) - pro přístup klientů ke službám VS pro životní situace prostřednictvím obslužných kanálů a elektronicky učiněné úkony včetně jejich elektronicky podporovaného vyřizení příslušným OVS
• Kontaktní místa a obslužné kanály pro klienty VS

• Portál občana v PVS a mobilní aplikace jako samoobslužná elektronická Univerzální kontaktní místa.
• CzechPOINT - jako asistované, ale dále již plně elektronické univerzální kontaktní místo VS

• Jednotné identitní prostory (JIP) a systémy elektronické identifikace pro klienty a pro úředníky veřejné správy

• Elektronická identifikace pro klienty-občany ČR (NIA)
• Identifikace, autentizace a autorizace pro úředníky veřejné správy ČR (JIP/KAAS)

• Propojený datový fond (PPDF) - tvořený základními registry, kompozitními službami, službami eGSB a díky nim dostupnými službami jednotlivých datových zdrojů, agendových systémů.
• Veřejný datový fond ČR (VDF) – údaje zveřejňované orgány veřejné správy jako otevřená data a nástroje pro katalogizaci a přístup k otevřeným datům

• Otevřená data
• Veřejné rejstříky

• Elektronická výměna dokumentů (EVD) a elektronické úřadování

• Datové schránky
• Elektronické pečetě a časová razítka
• Spisové služby, spravované jednotlivými OVS, s budoucí možností využití služeb SaaS a PaaS eGCovernment cloudu, pokud tam budou poskytovány

• Sdílené agendové IS (AIS)

• Sdílené agendové IS v přenesené působnosti
  • například pro agendy v přenesené působnosti Živnostenský rejstřík Evidence obyvatel, Evidence řidičů a Registr motorových vozidel, Informační systém technické infrastruktury atd.
• Sdílené agendové IS pro samostatnou působnost územních samospráv
• Sdílené provozní informační systémy, jako například Informační systém státní služby, Integrovaný informační systém státní pokladny nebo NEN pro provozní procesy veřejné správy.
• eSbírka

• Jednotné obslužné kanály a uživatelská rozhraní úředníků

• Portál úředníka - jednotné federativní transakční uživatelské a navigační rozhraní pro úředníky, paralela/protiváha k Portálu občana
• CzechPOINT@Office - jako univerzální rozhraní poskytování služeb mezi úředníky/úřady

• Sdílené platformy a ICT infrastruktura VS ČR

• Národní datová centra - ve státních podnicích SP CSS a NAKIT, v obdobných organizacích dalších ministerstev.
• eGovernment Cloud
• Sdílená síťová a komunikační infrastruktura

Každý z tematických okruhů je níže popsán klíčovými principy, definicemi a následně odpovídajícími sdílenými službami centrálních prvků eGovernmentu.

Agendová mapa výkonu veřejné správy ČR

ke zvážení – spíše jde o celkový Meta-informační systém (Mapu) výkonu VS

Zákon 111/2009 Sb. O základních registrech zavedl jako jeden ze základních registrů Registr práv a povinností. Podle současného zění zákona je RPP zdrojem referenčních údajů o:

• Jednotlivých Orgánech veřejné moci a Soukromoprávních uživatelích údajů s veřejnoprávní působností
• Jednotlivých agendách a OVM v těchto agendách působících v definovaných činnostních rolích
• O právu jednotlivých agend resp. OVM v nich působících využívat údaje ze základních registrů
• O právu jednotlivých agend resp. OVM v nich působících vést údaje o evidovaných subjektech a objektech práva
• O právu jednotlivých agend resp. OVM v nich působících poskytovat jimi vedené údaje jiným agendám
• O právu jednotlivých agend resp. OVM v nich působících čerpat údaje z jiných agend

Pro ISVS podporující jednotlivé agendy tak RPP vytváří základní rámec oprávnění a povinností při sdílení údajů s jinými ISVS prostřednictvím referenčního rozhraní VS – definuje tedy základní pravidla interoperability ISVS v rámci VS ČR.

Z pohledu výkonu VS ČR definuje RPP kromě referenčního výčtu jednotlivých OVM také jejich působnosti v jednotlivých agendách, které definují zákonnou působnost OVM.

Zde ještě podrobněji rozvedeme:

• Věcnou a místní příslušnost
• Přenesená působnost

AIS Působnostní ve skupině systémů RPP, společně s Informačním systémem o ISVS (ISoISVS), Informačním systémem o datových prvcích (ISoDP) a s nově definovanými katalogy životních událostí, rolí subjektů práva, služeb a dalších objektů a katalogy jejich vzájemných vazeb tvoří tzv. Meta-informační systém veřejné správy, tedy systém informací o veřejné správě jako takové.

Úplné elektronické podání (ÚEP)

Tzv. úplné elektronické podání (ÚEP) je možné popsat tak, že klient, fyzická osoba (občan), ale i zástupce právnické osoby, má možnost vyřídit všechnu svou potřebnou agendu životní situace, tj. dosáhnout oprávněných požitků (nároků) nebo splnit povinnosti (závazky) plynoucí mu na základě jeho životní události z jeho změněné situace ve vztahu k veřejné správě, a to prostřednictvím elektronické interakce samoobslužně kdykoli a odkudkoli či asistovaně z kteréhokoli univerzálního kontaktního místa VS, bez nutnosti osobní návštěvy na příslušných úřadech, a následně možnost mít přehled o stavu a vývoji všech svých řešených životních událostí.

Všechny obslužné kanály veřejné správy musí být cílově vzájemně integrovány tak, aby mezi nimi bylo možno libovolně přecházet i v průběhu vyřizování podání a aby všechny informace byly zachovány, přenášely se do nich (mezi nimi).

Elektronické podání klienta vůči veřejné je dle této IKČR považováno za úplné, pokud splňuje všechny v úvodu této IKČR uvedené architektonické principy eGovernmentu, zejména pak:

• Podporuje princip Digital by Default tím, že je navrženo jako vnitřně plně digitální (nikdy se nemusí tisknout nebo osobně řešit), s tím, že ale podporuje asistovanými formami i tzv. elektronicky handicapované.
• Podporuje princip Whole-of -Government tím, že je dostupné rovnocenným způsobem ve všech elektronických kanálech eGovernmentu (samoobslužných i asistovaných), s upřednostněním univerzálních kontaktních míst (CzechPOINT a PO v PVS).
• Podporuje princip Once only tím, že pro předvyplnění formuláře i pro navigaci a volbu služby jsou využity všechny údaje o klientovi, které veřejná správa má a ze zákona je v dané situaci smí použít.
• Podporuje principy Interoperability by Default a Cross-border by default tím, že umožňuje elektronicky obsloužit všechny klienty, rezidenty ČR a EU, pro které je úkon relevantní, a to i vzdáleně ze zahraničí.

Dále ÚEP z hlediska front-office a klientů:

• Má služby agend v rámci ÚEP a jejich IT aplikace navrženy tak, aby služby bylo možno v obslužných kanálech kombinovat pro efektivním řešení životních událostí.
• Využívá jednotný identitní prostor (JIP) klientů a úředníků (JIP/KAAS).
• Umožňuje klientům sledovat průběh vyřizování jejich podání.

Z toho pro byznys, případně následnou aplikační architekturu úřadu plynou následující pravidla a požadavky IKČR:

1. Postupně všechna existující práva a povinnosti ze vztahu k VS budou doprovázena transakční službou (nejenom popisem návodu) v autentizované části portálu veřejné správy (PVS), a to v těch všech případech, kdy elektronická transakční služba bude proveditelná a bude odpovídat oprávněným zájmům klientů a současně i úřadů.

2. Stejnou službu lze získat off-line, pro jednotlivá (elementární, atomická) podání k nároku (právu) nebo závazku (povinnosti), tj. půjde stáhnout předvyplněný formulář na cokoli, off-line vyplnit, zaslat datovou schránkou nebo elektronicky podepsané doručit jakkoli jinak (i mailem, vložením do portálu), případně vložit do elektronické aplikace úřadu.

3. V případě menší četnosti podání stačí jeden z obou kanálů (on-line nebo off-line), musí však umožňovat dobrou (personalizovanou) navigaci ke službě a k jejímu předvyplnění.

4. Stejnou službu lze získat s pomocí služby úředníka na kterémkoli fyzickém kontaktním místě asistovanou formou. Pro typové a jednoduché elementární služby a z nich seskupené konfigurovatelné produkty pro řešení typových životních situací to takto bude možné na Univerzálních asistovaných kontaktních místech, nyní CzechPOINT.

5. Stojíce již mimo front-office eGovernmentu, zůstanou existovat tradiční kanály pro příjem listinných podání osobně, diktátem do protokolu nebo poštou – úřední přepážky a podatelny. Jejich úkolem ale bude obdržené vstupy neprodleně plně digitalizovat (s maximem OCR), aby celé další (následné) zpracování bylo jednotně plně elektronické.

6. Podnikatelé a organizace, mající ze vztahu k VS periodické a velmi informačně objemné povinnosti (jako například KV DPH, hlášení na SSZ a ZP atd.) budou využívat jejich další (a hlavní) kanál obsluhy, tzv. embedded systémy a A2A integrace jejich back-end a provozních systémů s API z AIS.

7. Nedílnou součástí řady podání je splnění finanční povinnosti (poplatku, daně) – IKČR předpokládá využívání elektronických platebních nástrojů, jejich postupnou centralizaci jako sdílené služby a vysokou míru automatizace návazných operací jakoje párování plateb a aktualizace stavu podání.

8. Elektronické samoobslužné služby pro občany (interakce) i pro organizace (integrace) musí být doplněny interaktivním podpůrným a poradenským kanálem (service-desk, call-me-back, apod.), tedy multikanálovým kontaktním centrem, které bude pomocí hlasu, chatu, SMS, mailu apod. pomáhat řešit situace klientů v samoobslužném webovém rozhraní nebo v integračním kanálu.

9. Služby a prostředky eGovernmentu musí být navrhovány a realizovány tak, aby služby zprostředkované třetími stranami (Service Broker) byly rovnocenným obslužným kanálem veřejné správy a součástí eGovernmentu. Za tím účelem bude třeba přinejmenším efektivně pracovat s elektronickými plnými mocemi a poskytovat služby AIS jako tzv. „otevřená API“ tak, aby je ověření partneři mohli zahrnout do svých nadstavbových aplikací.

10. Pro zajištění obsahu a postupu řešení služeb pro životní situace (události), napříč agendami a resorty, rovnocenně ve všech samoobslužných a asistovaných univerzálních klientských centrech, musí existovat, nejlépe na MV nebo samostatně jako úřad, silné, kapacitně, znalostně a finančně dobře vybavené Kompetenční centrum služeb veřejné správy. To jediné dokáže naplnit služby pro ŽS obsahem napříč resorty, protože resorty samy to z legislativních i jiných důvodů udělat nemohou.

11. Pro individuální přizpůsobení (personalizaci) uživatelských rozhraní se budou využívat klientské profily. Cílově bude mít každý klient jenom jeden, celou veřejnou správou a všemi jejími obslužnými kanály sdílený osobní profil. Tento profil bude obsahovat výčet rolí, které již klient vůči veřejné správě hraje (v kterých agendách) a jaké údaje chce používat v jednotlivých rolí, nebo napříč všemi rolemi. Budou to údaje převzaté z propojeného datového fondu (jeho firmy, rodinní příslušníci, majetek apod.) a údaje doplněné klientem (preferovaný mail a telefon, preferovaný bankovní účet, apod.).

Kontaktní místa a obslužné kanály pro klienty VS

IKČR zdůrazňuje a rozvíjí tzv. Univerzální kontaktní místa. Ta představují obslužné kanály, tj. místa a prostředky, kterými klienti veřejné správy mohou realizovat služby veřejné správy, bez ohledu věcnou a místní příslušnost služby a služebního úřadu, a to jak samoobslužné (Portál občana v PVS), tak asistované (CzechPOINT).

Při rostoucí elektronizaci služeb klientům bude nezbytným dalším univerzálním kontaktním místem také multikanálové (hlas, mail, chat, SMS, …) kontaktní centrum / Call-centrum, primárně určené na podporu uživatelů samoobslužných elektronických kanálů.

Portály pro externí klienty veřejné správy

Bude dále rozvedeno. Klíčové části:

• federalizace portálů jednotlivých resortů a území propojených jednou identitou občana,
• sdruženo pod Portálem občana,
• informační část a transakční část PVS,
• informuláře, používající identitu občana.

Asistovaná univerzální kontaktní místa - Czech POINT

Ministerstvo vnitra ČR vybudovalo Czech POINT (zkratka pro Český Podací Ověřovací Informační Národní Terminál) s cílem vytvořit univerzální podatelnu, ověřovací místo a informační centrum, kde by bylo možné na jednom místě získat veškeré údaje, opisy a výpisy, které jsou vedeny v centrálních veřejných evidencích a registrech, jakož i v centrálních neveřejných evidencích a registrech ke své osobě, věcem a právům.

S cílem vytvořit místo, kde je dále možné ověřit dokumenty, listiny, podpisy a také elektronickou podobu dokumentů, učinit podání ke kterémukoli úřadu veřejné správy, a konečně získat informace o průběhu řízení ve všech věcech, které stát k jeho osobě vede.

Aktuálně lze na pracovištích Czech POINT lze získat například výpis z katastru nemovitostí, obchodního rejstříku, rejstříku trestů.

Rozhraní CzechPOINT@home je určeno pro občany, kteří nechtějí pro výpis z rejstříku chodit na kontaktní místo Czech POINT a mají zřízenu vlastní datovou schránku fyzické osoby. Datová schránka žadatele slouží pro odeslání žádosti a pro doručení vystaveného výpisu z rejstříku nebo jiné odpovědi. Žadatel připravuje žádost o výpis či další podání pomocí webových formulářů CzechPOINT@home.

Výpisy z vybraných (zpoplatněných) rejstříků je možné získat prostřednictvím e-shopu Czech POINT.

Elektronické samoobslužné služby CzechPOINT postupně splynou s, respektive budou nahrazeny transakční částí PVS.

Asistovaná kontaktní místa CzechPOINT budou naopak rozvíjena do té míry, že jejich prostřednictvím bude možné učinit zcela stejný rozsah podání a získat stejný rozsah informací jako v samoobslužném kanálu.

Identifikace, autentizace a autorizace účastníků řízení

Zásadním požadavkem bezpečnosti a transparentnosti pro informační systémy veřejné správy je požadavek na jednotnou elektronickou identifikaci interních i externích uživatelů. Pro každou operaci je nutná znalost osoby, která tuto operaci provádí zvláště z hlediska nepopiratelné zodpovědnosti osoby.

Externí uživatelé (klienti) informačních systémů veřejné správy musí být jednoznačně identifikováni zvláště z důvodů ochrany osobních údajů a dále z procesního hlediska, jak předpokládá správní řád (jednoznačné prokázání totožnosti účastníků řízení).

Pro interní uživatele, pracující v informačním systému veřejné správy je nutnou podmínkou jednoznačná a nepopiratelná identifikace uživatele tak, aby bylo možné jednoznačně vyhodnotit oprávnění této osoby v rámci přístupu k údajům a službám informačních systémů a současně zpětně vyhodnotit činnost těchto osob dle záznamů v auditních systémech (logy).

Úloha správy přístupů se pro každý informační systém veřejné správy skládá z následujících kroků:

• Identifikace – jednoznačné a nepopiratelné určení fyzické osoby, která přistupuje k informačnímu systému veřejné správy
• Autentizace – prokázání, že přistupující osoba je tou osobou, za kterou se vydává. Autentizace probíhá předložením autentizačních prostředků (například uživatelské jméno a heslo, autentizační certifikát), které osobě přidělil správce informačního systému
• Autorizace – na základě údajů o identifikované a autentizované osobě a dalších údajů o této osobě (například zařazení na pracovní pozici) zařazení osoby do odpovídající role a z toho vyplývající vyhodnocení oprávnění na úkony a data v rámci informačního systému.

IKČR v této oblasti vyžaduje naplnění následujících principů pro všechny informační systémy veřejné správy:

1. Prostředky pro identifikaci a autentizaci jsou vždy vydány bezpečnou a jednoznačnou cestou identifikované osobě. O tomto vydání prostředků existuje trvalý záznam spolu s údaji, jak byla ověřena identita osoby

2. Osoba, jíž byly prostředky vydány, nedílně zodpovídá za ochranu těchto prostředků před odcizením a zneužitím

3. Osoba, jíž byly prostředky vydány, nese nedílnou zodpovědnost za všechny úkony, které byly v informačním systému provedeny při použití těchto prostředků

4. Správce prostředků pro identifikaci a autentizaci musí zajistit celý životní cyklus prostředků (vydání, obnova, odvolání, ztráta) tak, aby po celou dobu uchovávání logů o transakcích v rámci informačních systémů, kde mohou být prostředky použity, bylo možné jednoznačně prokázat platnost prostředku v daném okamžiku a identitu osoby, jíž byl prostředek vydán

5. Správce informačního systému zodpovídá za nastavení oprávnění v informačním systému na základě rolí nikoli na základě identifikace a autentizace

6. Věcný správce agend, které jsou vykonávány v rámci informačního systému, zodpovídá za obsazení osob do rolí (technicky vykonává technický správce informačního systému, vždy však na základě podkladů o věcných správců). Tuto svoji zodpovědnost může delegovat v rámci organizační struktury na více zodpovědných osob.

7. Neexistuje technický účet, který by nebyl vydán jednoznačně identifikované osobě. Tato osoba následně zodpovídá za všechny činnosti, které byly provedeny s použitím tohoto technického účtu.

8. Neexistuje anonymní účet, který by mohl získat oprávnění pro přístup k osobním údajům osob.

Řešení pro identifikaci, autentizaci a autorizaci může být provedeno buď lokálně v rámci informačního systému, nebo globálně v rámci celé veřejné správy.

Základními pilíři eGovernmentu jsou dvě skupiny klíčových sdílených služeb, vytvářející jednotný identitní prostor klientů veřejné správy a jednotný identitní prostor úředníků veřejné správy.

Jednotná elektronická identifikace klientů VS (NIA)

Pro jednoznačnou identifikaci, autentizaci a autorizaci klientů veřejné správy byl vytvořen technický a právní rámec, který umožňuje všem správcům informačních systémů veřejné správy tuto činnost vykonávat v souladu s IKČR a výše uvedenými požadavky bez nutnosti vytváření nákladných řešení a zvyšování administrativní zátěže.

Zákon č. 250/2017 Sb., o elektronické identifikaci, zavádí v §2 povinnost provádět prokázání totožnosti s využitím elektronické identifikace pouze prostřednictvím kvalifikovaného systému elektronické identifikace. Tento paragraf nabývá účinnosti 1. července 2020. Po tomto datu nebude možné pokračovat v praxi vydávání přístupových údajů klientů veřejné správy mimo systémy kvalifikovaného systému elektronické identifikace, pokud jiný zákon tuto cestu neumožnuje.

Podporu celého procesu elektronické identifikace prostřednictvím kvalifikovaného systému elektronické identifikace je vytvořena platforma Národní identitní autority, která vykonává činnosti Národního bodu dle § 20 a následujících a národního uzlu eIDAS pro spolupráci s oznámenými systémy elektronické identifikace dle nařízení Evropské parlamentu a Rady (EU) č. 910/2014 ze dne 23. července 2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu a o zrušení směrnice 1999/93/ES.

Národní identitní autorita vytváří federativní systém, který se skládá z následujících komponent:

• Národní bod jako centrální bod federativního systému, který zajišťuje komunikaci a registraci účastníků federace. Tato komponenta zajišťuje současně vždy jednoznačné ztotožnění osoby, která prokazuje svoji totožnost předložením autentizačních prostředků
• Kvalifikovaný správce, který vydává jednoznačně identifikovaným fyzickým osobám prostředky pro vzdálenou autentizaci (prokázání totožnosti) a provádí veškeré činnosti spojené se správou těchto prostředků a prokazováním totožnosti fyzické osoby
• Základní registry, které poskytují jednoznačnou identifikaci osoby a zajištění vazeb této osoby vůči referenčním údajům o osobě
• Národní uzel eIDAS, který zajišťuje přijímání vzdáleného prokázání totožnosti z ohlášených systémů dle nařízení eIDAS a předávání vzdálené identifikace a autentizace z České republiky ostatním státům EU

Kvalifikovaný poskytovatel elektronických služeb bude nadále zodpovědný za řízení oprávnění (autorizaci) fyzické osoby, která prokázala takto svoji totožnost. Nadále tedy musí provádět správu oprávnění na základě údajů o osobě, které získá z propojeného datového fondu veřejné správy a vlastních údajů vedených v agendě.

Jednotný identitní prostor úředníků, autentizační informační systém (JIP/KAAS)

Jednotní identitní prostor (JIP) informačních systémů veřejné správy a Katalog autentizačních a autorizačních služeb (KAAS) je autentizační informační systém podle § 56a zákona o základních registrech a jeho správcem je Ministerstvo vnitra. Na základě znění zákona zavedení jakékoli osoby do tohoto autentizačního informačního systému vyžaduje její jednoznačné ztotožnění oproti základnímu registru obyvatel. Ministerstvo dále spravuje prostředky pro autentizaci, které vydává.

IKČR předpokládá co nejširší používání autentizačního informačního systému JIP/KAAS pro splnění zásadních podmínek pro identifikaci a autentizaci interních uživatelů informačních systémů veřejné správy. Pro ty informační systémy, kde interní uživatelé informačního systému jsou zaváděni úřady, které nejsou správci tohoto informačního systému, je použití autentizačního informačního systému JIP/KAAS povinností.

Datové fondy a druhy údajů při výkonu veřejné správy

Propojený datový fond a jeho služby

IK ČR zavádí do architektury VS ČR pojem propojeného datového fondu (PPDF). Propojený datový fond je tvořen datovými fondy (zejména datovými kmeny a transakčními daty) jednotlivých ISVS, propojených referenčním rozhraním VS s datovými fondy jiných ISVS pomocí odkazů (referenčních vazeb) na referenční údaje o subjektech práva (fyzických osobách, právnických osobách a OVM) a referenční údaje o objektech práva - územních prvcích, vedených v základních registrech. Pro referenční vazby údajů o fyzických osobách se využívá Agendový identifikátor Fyzické osoby ( AIFO), pro referenční vazby právnických osob Identifikační číslo osoby (IČO), pro referenční vazby územních prvků jejich příslušné identifikátory přidělené RUIAN.

Referenční rozhraní VS, pomocí něhož je PPDF zpřístupněn, je tvořeno Informačním systémem základních registrů a sběrnicí eGovernmentu, která je součástí CMS (eGSB).

Cílem rozvoje PPDF je publikovat jeho prostřednictvím nejen referenční údaje ze ZR a autoritativní (ze zákona vedené a spravované) údaje editorů ZR, ale také autoritativní údaje dalších agendových centralizovaně vedených ISVS.

Základními službami PPDF pro ISVS - čtenáře a uživatele údajů v PPDF jsou a budou:

• Ztotožnění (přidělení identifikátoru) subjektu resp. objektu práva v ISVS vedeném
• Výdej propojených údajů o subjektu/objektu práva v rozsahu oprávnění vedených v RPP pro příslušnou agendu podporovanou ISVS
• Notifikace o změnách referenčních a autoritativních údajů pro údaje v ISVS vedené
• Podpora reklamace chybných údajů
• Podpora pseudonymizace údajů o subjektech práva

Pro OVM a subjekty údajů to budou služby:

• Podpora vytváření výstupů z ISVS pro subjekty údajů
• Podpora vytváření autorizovaných výpisů z ISVS
• Podpora reklamace chybných údajů

PPDF je základním předpokladem pro naplnění principu Only Once a eliminace místní příslušnosti.

PPDF se skládá z následujících prvků eGovernmentu:

1. Základní registry (dále také ZR), publikované službami ISZR

Základní registry tvoří Základní registr obyvatel (též ROB), Základní registr osob (též ROS), Základní registr územní identifikace a nemovitostí (též RUIAN), Základní registr práv a povinností (též RPP), registr ORG a informační systém základních registrů (též ISZR).

2. Údaje editorů ZR publikované kompozitními službami ISZR

Kompozitními službami se rozumí služby ISZR, které poskytují údaje vedené v editorských systémech ZR s vazbou na referenční údaje vedené v ZR

3. Autoritativní zdroje publikované na eGSB

ISVS vedoucí evidence údajů ze zákona (autoritativní zdroj) publikují údaje pro potřeby jiných OVS nebo pro klienty VS prostřednictvím CMS – eGSB.

4. Národní sady prostorových dat (NaSaPo)

Geoinfostrategie vymezila nové uspořádaní prostorových dat s horizontem 2020, včetně nastavení vztahu Národní sady prostorových obkektů NaSaPO ke RUIAN.

ISZR a eGSB tvoří referenční rozhraní ve smyslu zákona o ISVS.

Autoritativní údaje veřejné správy

Jedním z principů, které chceme ve veřejné správě naplnit a pro které je projekt Základní registry 2.0 zcela klíčový, je princip tzv. “autoritativních údajů” ve veřejné správě.

Cílem je, aby klienti veřejné správy nebyli nuceni dokládat skutečnosti, o kterých veřejná správa již ví, či které vznikly dokonce na základě rozhodnutí veřejné správy. Většina skutečností potřebných pro rozhodování veřejné správy je již někde evidována, a to formou údajů v informačních systémech veřejné správy. Tyto údaje mají svůj původ a v řadě případů je již nastavena i zodpovědnost za jejich správu v příslušném AISu (příkladem je oprávnění k řízení motorového vozidla, průkaz osoby se zdravotním postižením, status důchodce, potvrzení o bezdlužnosti apod.). Dále existují skutečnosti, které sice jsou na základě rozhodování veřejné správy, nicméně nejsou dosud vedeny v AIS jako údaje (příkladem je potvrzení o studiu, dohoda o chráněné dílně apod.). Zmapováním údajů v jednotlivých agendách, které probíhá nyní v rámci nových povinností ohlašovatelů vůči RPP je postupně zjištěna základní mapa údajů evidovaných, vyžadovaných a poskytovaných v rámci jednotlivých agend a to, kde a jakým způsobem jsou evidovány a v jakém AIS. Tím, jak již bylo popsáno výše, vznikne základní datová mapa veřejné správy, a je tedy možné ji zanalyzovat a identifikovat ty údaje a skutečnosti, které jsou používány ve více agendách.

Na referenčních údajích vedených v základních registrech (a na údajích vedených o fyzických osobách v systémech typu Evidence obyvatel) jsme si ověřili funkčnost principu, kdy tyto údaje a jejich změny klient nemusí dokládat, ale celá veřejná správa si tyto údaje získává prostřednictvím ISZR a na základě nich pak rozhoduje. Princip autoritativních údajů je pouze rozšířením tohoto funkčního celku i o další údaje.

V souvislosti s autoritativními údaji jsou obecně platné následující aspekty:

• Autoritativním údajem bude jen údaj vedený v AIS a vytvářený rozhodováním v rámci určité agendy veřejné správy.
• Autoritativním údajem bude údaj nebo soubor údajů, který dokládá nějakou skutečnost, jež je důležitou rozhodnou skutečností při rozhodování veřejné správy v rámci agendy či agend.
• U autoritativního údaje bude vždy jasné, jak vznikl, kdo je zodpovědný za jeho zápis, změny a správu, v jakém AIS je veden a jakým způsobem může být změněn či zrušen.
• Poskytovatelem autoritativního údaje bude vždy správce AIS, v němž je autoritativní údaje veden a evidován, a to vždy na základě zákonného zmocnění.
• Autoritativní údaj bude vždy vázán na subjekt práva, či objekt práva.
• Poskytování a využívání autoritativních údajů bude vždy logováno, podobně jako je tomu u údajů ze základních registrů.
• Technické řešení poskytování a využívání autoritativních údajů OVM bude realizováno prostřednictvím eGON service busu, a to vždy mezi jednotlivými AIS.
• Bude umožněno subjektu údajů si pořídit výpis autoritativního údaje jako výpis z informačního systému veřejné správy.

Protože cílem je efektivní a zároveň účelné propojování údajů především za účelem omezování nutnosti klienta dokládat skutečnosti, bude autoritativní údaj moci být orgánem veřejné moci získáván:

1. na základě souhlasu subjektu údajů (jménem subjektu údajů), nebo
2. na základě zákonného zmocnění (z moci úřední)

Na autoritativní údaje se budou vztahovat podobné principy jako na referenční údaje v ZR, a to zejména:

• Princip důvěryhodnosti: OVM bude takovému údaji důvěřovat, pokud se neprokáže opak;
• princip využívání: OVM bude muset takový údaj využít pro svoje rozhodování a nezatěžovat klienta jeho doložením;
• princip reklamace: OVM, pokud zjistí nesoulad s autoritativním údajem, vznese jeho reklamaci a editor ji vyřídí;
• princip zpochybnění: autoritativní údaj, u nějž vznikne pochybnost, či který bude reklamován, bude vyznačen jako zpochybněný;
• princip notifikace a aktualizace: OVM budou získávat autoritativní údaje i s možností registrace notifikací o změnách, čímž se okamžitě dozví o změně údaje, a to zcela automaticky;
• princip zmocnění: subjekt údajů bude moci určit, které třeba i komerční subjekty mimo veřejnou správu budou získávat automaticky informace o změnách těchto údajů.

Pro vybudování a využívání autoritativních údajů je tedy nezbytné dobudovat potřebnou technickou infrastrukturu a nastavit principy a zajistit jejich dodržování, především pak vybudovat nástroje, s jejichž pomocí budou moci být informační systémy propojovány a autoritativní údaje využívány. K tomu je nezbytné realizovat projekt Základní registry 2.0, neboť dobudováním potřebných nástrojů a úpravou stávajících klíčových informačních systémů a jejich služeb bude moci být koncept autoritativních údajů realizován.

Pro rozběhnutí principu autoritativních údajů bude pochopitelně nutno také nastavit legislativní a technický rámec, to bude řešeno až v okamžiku, kdy budeme mít k dispozici potřebné nástroje. Oblast autoritativních údajů jako základní princip se ale již nyní přidává do Národní informační koncepce ČR, počítá s nimi koncept Digitálně přívětivé legislativy apod. Autoritativní údaje dále umožní naplňovat i cíle a zásady již v existujících strategií (kupříkladu “Strategie rozvoje ICT služeb ve veřejné správě”).

Autoritativní údaje se budou mezi jednotlivými informačními systémy předávat referenčním rozhraním. V naprosté většině to bude prostřednictvím EGON service busu, ale ne vždy, pokud již funguje a je využívána jiná cesta, která splní veškeré požadavky.

Obecné příklady

Autoritativní údaje budou vždy údaje vedené v informačním systému veřejné správy. Bude se jednat o údaje, které jsou v ISVS k dispozici a které je ISVS schopen publikovat (především prostřednictvím eGSB, ale nikoliv výhradně) a které jsou vázány na subjekt (tedy osobu) nebo na objekt (předmět evidence).

Příkladem podání autoritativního údaje jsou:

1. Oprávněný subjekt se dotazuje na řidiče

   1. Dotaz na subjekt v ROB - provazba přes AIFO tazatele

   2. Dotaz na autoritativní údaje o subjektu jako řidiči přes eGSB do systémů MD

   3. MD vrátí přes eGSB

2. Oprávněný subjekt se dotazuje na vlastníka a provozovatele vozidla

   4. Subjekt zná identifikátor objektu (SPZ vozidla)

   5. Dotaz přes eGSB na vozidlo podle SPZ a jeho atributy

   6. MD vrátí údaje o vozidle a

      1. údaje o vlastníkovi provázané přes AIFO

      2. údaje o provozovateli provazbou přes AIFO

3. Oprávněný subjekt se dotazuje na vozidla, která vlastní či provozuje subjekt

   7. Má ztotožněný subjekt přes AIFO (ROB) nebo IČ (ROS)

   8. Dotazuje se na vozidla vlastněná či provozovaná subjektem přes eGSB do systémů MD

   9. MD vrátí přes eGSB seznam vozidel s jejich identifikátory (SPZ) a jejich atributy

4. Oprávněný subjekt se dotazuje na to, zda je osoba v evidenci Úřadu práce

   10. Má osobu ztotožněnou v ROB přes AIFO

   11. Dotazuje se přes eGSB do systému JISPSV na MPSV

   12. MPSV/ÚPČR vrací údaje provazbou přes AIFO, nebo

   13. MPSV/ÚPČR vrací přes eGSB informaci, že osoba není v evidenci ÚP

5. Dotaz na děti subjektu

   14. Má ztotožněného rodiče v ROB přes AIFO

   15. Dotazuje se přes eGSB na děti rodiče

   16. MV/ISEO vrací přes eGSB AIFO dětí a případně údaje dětí (nemám vyjasněno)

6. Poskytování údajů pro výběr pokut Celní správou

   17. Subjekt má připravené údaje o udělené pokutě, včetně subjektu pokuty a jeho AIFO či IČ

   18. Oprávněný subjekt předá přes eGSB ticket k výběru uložené pokuty, včetně údajů o subjektu a číslo jednací rozhodnutí

   19. Celní správa si ticket převezme, zaeviduje do svého ISVS a koná

   20. Celní správa přes eGSB vrátí oprávněnému subjektu údaje o výběru pokuty s vazbou v původním ticketu

Potřebné rámcové kroky

Princip autoritativních údajů bude projednáván s orgány veřejné moci na různých úrovních, již dnes je ale jasné, že obecný rámcový další postup by měl být:

1. Zakotvit princip autoritativních údajů jako princip eGovernmentu (bude zakotveno v NIK)
2. Zanalyzovat údaje evidované v agendách podle ohlášení v RPP
3. Zanalyzovat potřeby vycházející ze seznamů rozhodných skutečností úřadů
4. Vydefinovat první skupiny adeptů na autoritativní údaje
5. Připravit obecný legislativní rámec pro využívání autoritativních údajů ve VS (pracuje se na principech legislativy)
6. Projednat a schválit legislativní rámec na obecné úrovni, nebo ověřit legislativou v určitých agendách
7. Dobudovat technickou infrastrukturu pro výměnu autoritativních údajů a jejich správu (projekt ZR2)
8. Vyzkoušet si AU na prvních druzích údajů
9. Postupně roztáhnout na další agendy

Veřejný datový fond

Veřejným datovým fondem (dále jen VDF) se rozumí celek datového fondu ČR, obsahující údaje zveřejňované orgány veřejné správy jako veřejné rejstříky a údaje zveřejňované jako otevřená data s podporou centrálního nástroje, kterým je Národní katalog otevřených dat (NKOD).

Veřejné rejstříky (VDF-VR)

Veřejnými rejstříky právnických a fyzických osob podle zákona č. 304/2013 Sb., Zákon o veřejných rejstřících právnických a fyzických osob (dále jen „veřejný rejstřík“), se rozumí:

• spolkový rejstřík,
• nadační rejstřík,
• rejstřík ústavů,
• rejstřík společenství vlastníků jednotek,
• obchodní rejstřík a
• rejstřík obecně prospěšných společností.

Do veřejného rejstříku se zapisují zákonem stanovené údaje o právnických a fyzických osobách (dále jen „zapsaná osoba“). Veřejný rejstřík je informačním systémem veřejné správy. Veřejný rejstřík je veden v elektronické podobě. Veřejný rejstřík vede soud (dále jen „rejstříkový soud“).

Ministerstvo financí uveřejňuje způsobem umožňujícím dálkový přístup informace o osobách zapsaných v České republice a údaje o tom, ve kterém veřejném rejstříku jsou tyto osoby zapsány. Ministerstvo financí umožňuje získat o údajích vedených ve veřejných rejstřících elektronický opis.

Údaje z Obchodního rejstříku společně s údaji z Registru živnostenského podnikání (RŽP) a Registru ekonomických subjektů (RES), Registru plátců spotřební daně (SD) a dalších zdrojů publikuje Ministerstvo financí prostřednictvím Administrativního registru ekonomických subjektů (ARES). ARES je IS, který zpřístupňuje veřejné údaje o ekonomických subjektech z informačních systémů (zdrojů) veřejné správy. Obsahuje údaje ze základních (majoritních) zdrojů, které jsou formou odkazů doplněny údaji z dalších zdrojů. Při zpracování se používají též kontrolní zdroje.

Veřejné rejstříky a vzdálený přístup k jejich údajům prostřednictvím ARES předcházely Základním registrům a musí být s nimi sladěny a integrálně nově zařazeny do celkové koncepce eGovernmentu. Koncepce rozvoje veřejných rejstříků a jejich IS musí tedy naplňovat přinejmenším následující požadavky:

1. Všechny rejstříky musí obsahovat ztotožněné údaje FO a PO, pokud je bylo proti čemu ztotožnit (u rezidentů).
2. Všechny rejstříky vedle toho, že jsou publikovány na internetu, musí být dostupné jako otevřená data. A to přímo, nebo prostřednictvím OD k ARES.
3. Všechny rejstříky musí být pro potřeby agend OVS dostupné přes eGSB, a to buď sdruženě, prostřednictvím ARES, nebo přímo, pokud jejich veřejné údaje nejsou v ARES zahrnuty.
4. ARES, jako klíčový veřejný rejstřík s velkým hospodářským dopadem, musí být být průběžně rozvíjen a inovován tak, aby odpovídal aktuálním potřebám občanské i podnikové veřejnosti ČR.

Otevřená data (VDF-OD)

Otevřenými daty se v rámci veřejného datového fondu se rozumí celek obsahující údaje zveřejňované orgány veřejné správy jako otevřená data a Národní katalog otevřených dat (NKOD).

NKOD je nástroj, ve kterém jednotlivé orgány veřejné správy katalogizují jimi zveřejňovaná otevřená data a jiné orgány veřejné správy a veřejnost v něm otevřená data vyhledávají a získávají k nim přístup.

Existence NKOD a povinnost jednotlivých orgánů veřejné správy v něm katalogizovat svá otevřená data je dána zákonem č. 106/1999 Sb., o svobodném přístupu k informacím, který zavádí definici otevřených dat, NKOD a zmocňuje vládu vydat nařízení o seznamech, evidencích či registrech, jejichž veřejný obsah je povinně zveřejňován jako otevřená data, § 5 odst. 7 tohoto zákona pak zmocňuje orgány veřejné správy zveřejňovat i další informace jako otevřená data.

Nařízení vlády č. 425/2016 Sb. o seznamu informací zveřejňovaných jako otevřená data stanovuje, jaké informace mají být zveřejňovány orgány veřejné správy jako otevřená data povinně.

Pro naplnění závazků, které vyplývají ze strategických dokumentů, bude zveřejňování otevřených dat povinné pro všechny správce ISVS. Pro zamezení vytváření duplicitních informací ve veřejné správě, které mohou být zveřejňovány, bude zavedena povinnost orgánů veřejné správy je sdílet jako otevřená data.

Průběžná změna legislativního prostředí musí vést k postupnému rozšiřování povinností orgánů veřejné správy zveřejňovat informace reprezentované jako údaje evidované v ISVS, jejichž zveřejnění je možné, nebo jejich anonymizovanou podobu, souhrn či statistiku jako otevřená data s cílem dosáhnout plošné povinnosti. Je nutné výslovně zanést možnost zveřejňovat informace jako otevřená data do zvláštních předpisů upravujících zveřejňování údajů, v jejichž případě se postup podle zákona o svobodném přístupu k informacím nepoužije, např. do zákona o právu na informace o životním prostředí.

Je též nutné legislativně ukotvit povinnost orgánů veřejné správy využívat při výkonu svých agend otevřená data poskytovaná jinými orgány veřejné správy. To se týká především číselníků, kdy jsou stejné číselníky vytvářeny různými orgány veřejné správy.

Veřejný datový fond v současnosti tvoří otevřená data několika orgánů veřejné správy a NKOD. Různá kvalita otevřených dat komplikuje jejich opakovatelnou použitelnost. Je též téměř nemožné sdílet veřejné údaje mezi orgány veřejné správy jako otevřená data, neboť neexistují žádné garance dostupnosti. Pro zlepšení současného stavu se VDF stane virtuálním distribuovaným datovým prostorem, ve kterém orgány veřejné správy sdílí s veřejností i mezi sebou navzájem veřejné údaje evidované v jimi spravovaných ISVS v podobě kvalitních otevřených dat. VDF-OD bude mít následující součásti:

• Sdílený veřejný datový fond (SVDF) – bude podmnožinou otevřených dat, která je určena nejenom veřejnosti, ale slouží i ke sdílení veřejných údajů mezi orgány veřejné správy. Pro otevřená data v SVDF musí být zajištěna a garantována jejich dostupnost pro orgány veřejné správy, které je pro výkon svých agend využívají.
• Národní katalog otevřených dat (NKOD) – bude zvýšena jeho uživatelská přívětivost i na bázi sémantického slovníku pojmů. Bude podporovat standard DCAT-AP.
• Nástroj pro správu sémantického slovníku pojmů (NSSSP) – umožní správu sémantického slovníku pojmů všemi orgány veřejné správy a popisovat jejich otevřená data za účelem sémantické harmonizace otevřených dat.
• Katalog uživatelů otevřených dat (KUOD) – bude evidovat, jaké orgány veřejné správy využívají jaká otevřená data v SVDF.
• Portál otevřených dat (POD) – bude jednotný přístupový bod do VDF veřejně přístupný na adrese https://data.gov.cz.
• 5* (pětihvězdičkový) veřejný datový fond (5VDF) – bude podmnožinou otevřených dat, které jsou zveřejněny jako propojená otevřená data. Jeho součástí bude index datových entit, který pro každou datovou entitu reprezentovanou v 5VDF poskytuje základní údaje z 5VDF a odkazy na různé její reprezentace v otevřených datech jednotlivých orgánů veřejné správy v 5VDF.

Budou zajištěny kapacity pro vytvoření nových komponent VDF-OD. Softwarové nástroje pro realizaci VDF budou vytvořeny jako open-source s maximálním využitím existujících open-source komponent.

SVDF bude naplňován postupně. Nejprve zde budou zveřejněny kompletní údaje evidované v základních registrech ROS, RÚIAN a RPP, statistiky vytvořené z údajů evidovaných v základním registru ROB a veškeré sdílené číselníky spravované orgány veřejné správy. Postupně pak budou v SVDF zveřejňovány i další sdílené veřejné údaje dle připravovaných projektů tvorby či zhodnocování jednotlivých ISVS tak, aby bylo dosaženo cílového stavu zveřejnění všech sdílených veřejných údajů v SVDF. V 5VDF budou zveřejněny údaje ze základních registrů a vybrané číselníky vybraných orgánů veřejné moci, které jsou potřebné pro propojování dat. V případě rozšiřování základních registrů budou též i v nich vedené údaje zveřejněny jako otevřená data ve SVDF a jako propojená otevřená data v 5VDF.

Bude vytvořeno HW a SW prostředí pro provoz komponent VDF-OD. Pro potřeby orgánů veřejné správy, které budou zveřejňovat otevřená data v SVDF bude vybudováno sdílené úložiště SVDF, které umožní zajistit a garantovat dostupnost pro ostatní orgány veřejné správy.

HW a SW prostředí pro VDF-OD bude zajištěno v NDC nebo eGovernment Cloudu. HW a SW prostředí sdíleného úložiště SVDF bude zajištěno v NDC nebo eGovernment Cloudu. Správcem vytvořených prostředí bude Ministerstvo vnitra.

Zpracování, výměna a odborná správa elektronických dokumentů VS ČR

Zásady elektronického úřadování - definice.

Bude doplněno.

Následují sdíelné služby pro elektronické dokumenty a elektronické úřadování:

Datové schránky a elektronické úkony

Propojená správa dokumentů VS ČR

doplnit odstavce o změnách DS – co to je, pro koho to je, legislativní opora – bude doplněno.

Napojení na Identitu

Interoperabilita Datových schránek nebude řešena do schválení ETSI standardů elektronického doporučeného doručování.

Elektronické pečetě a časová razítka

Bude doplněno

Sdílená elektronická spisová služba pro malé OVS

Bude doplněno

Sdílené agendové informační systémy (AIS)

Centrální IS pro agendy v přenesené působnosti

Sdílené agendové informační systémy pro agendy v přenesené působnosti, jako jsou např. Živnostenský rejstřík, Evidence obyvatel, Evidence řidičů a Registr motorových vozidel, budou rozšířeny tak, že pokud je někdo ohlašovatelem agendy s výkonem v přenesené působnosti, musí zajistit i centrální agendový informační systém (jeho Middle-Office a agendový portál) s možností integrace na lokální systémy úřadů v území.

Naproti tomu musí obce disponovat pouze odpovídajícím „zařizovacím standardem“ pro připojení na takové systémy a úřadování v nich.

Sdílené IS pro samosprávné agendy

IKČR navrhuje, aby OVS, které musí vybudovat podporovat IT podporu pro samosprávné agendy a mají pro to k dispozici potřebné zázemí (infrastrukturu, kapacity, znalosti), typicky ORP (zejména statutární města a bývalá okresní města) nebo kraje, poskytly tuto podporu v multitenantním režimu malým obcím (1. a 2. typu) ve svém správním území. A to za podmínek daných změnami legislativy, ke kterým bude muset pro plnou realizaci tohoto konceptu dojít.

Stejná forma sdílení je možná mezi těmito úrovněmi samosprávy i v případě spisové služby a provozních systémů, pokud malé obce nevyužijí možnosti sdílení centrálních služeb, budou-li k dispozici.

Cloud

Sdílený informační systém pro spisovou službu

Případně, pokud nebude uveden u elektronického úřadování.

Sdílené provozní informační systémy

Obecně chceme říci, že takové systémy budou přibývat tak, jak bude stát směřovat politicky a legislativně k centrům sdílených služeb pro oblast provozních procesů.

Centrální personální IS

• Informační systém státní služby ISoSS. Bude doplněno.

Centrální finanční plánovací a rozpočetnické IS (ERP)

Integrovaný informační systém Státní pokladny je účinný, transparentní, efektivní a centralizovaný nástroj pro řízení veřejných financí, centralizaci účetních informací státu, konsolidaci vybraných ekonomických ukazatelů za veřejnou správu a komplexní přesné a včasné výkaznictví za celý veřejný sektor v souladu s mezinárodními standardy.

Implementovaný informační systém integruje základní funkční bloky Státní pokladny zaměřené na řízení specifických procesů řízení a kontroly veřejných financí, kterými jsou:

• Rozpočtový informační systém (RISPR a RISRE)
• Centrální účetní systém (CSÚIS)
• Řízení státního dluhu (ŘSD)
• Platební styk (PS)
• Prezentační vrstva - Monitor Státní pokladny (Státní monitor, Krajský monitor a Obecní monitor)

Státní pokladna má před sebou několik možných směrů rozvoje, například integraci na nákupní řešení nebo controlling (nákladové, manažerské účetnictví) veřejné správy.

Monitor Státní pokladny je specializovaný informační portál Ministerstva financí, který umožňuje veřejnosti volný přístup k rozpočtovým a účetním informacím ze všech úrovní státní správy a samosprávy. Prezentované informace pocházejí ze systému Státní pokladny a Centrálního systému účetních informací státu a jsou čtvrtletně aktualizovány. Monitor zahrnuje grafickou webovou část, analytickou část a strojově čitelná zdrojová data.

Centrální registr administrativních budov (CRAB) má vyřešit dosavadní absenci aktuálního celostátního přehledu o administrativních objektech v majetku státu, o jejich obsazenosti a dislokaci státních zaměstnanců. Registr na základě získaných informací umožní maximální využití státních objektů. Ve své činnosti se opírá o Usnesení vlády České republiky ze dne 20. prosince 2012 č. 954 o Centrálním registru administrativních budov.

Informační systém CEDR jako celek je nástrojem zejména pro poskytování, evidenci a kontrolu dotací a pro výkon řady s tím souvisejících agend. Systém se skládá z řady vzájemně provázaných subsystémů, které jsou provozovány na MF- GFŘ, resortech, agenturách a územních orgánech finanční správy.

V informačním systému CEDR jsou shromažďovány údaje o všech dotacích a návratných finančních výpomocích ze státního rozpočtu, státních fondů, státních finančních aktiv a Národního fondu a jejich příjemcích na základě Usnesení vlády č. 584/1997Sb. (subsystém CEDRIII).

• CEDR - resorty: Údaje jsou do IS CEDR zaznamenávány buď pomocí subsystému CEDR - resorty, který mohou využívat všichni poskytovatelé dotací, nebo prostřednictvím jiných informačních systémů, ve kterých jsou všechny požadované údaje také shromažďovány (např. EDS/SMVS, MSC2007). Předávání údajů do IS CEDR ukládá zákon č. 218/2000 Sb., o rozpočtových pravidlech, §75. Lhůty pro předávání dat a povinné položky stanoví vyhláška č. 296/2005 Sb., o centrální evidenci dotací.
• CEDR II - Kontrolní útvary FÚ - Všechny údaje, shromážděné v IS CEDR III, jsou předávány do subsystému CEDR II, který využívají kontrolní útvary finančních úřadů. CEDR II proto obsahuje i moduly pro podporu evidence kontrol a vymáhání nedoplatků nebo částek, které mají být vráceny v případě zjištění porušení rozpočtové kázně. Informace o výsledcích provedených kontrol jsou na vyžádání zpřístupněny příslušným poskytovatelům dotací.
• CEDR III - Veřejnost: Veřejné údaje z databáze CEDR jsou zpřístupněny prostřednictvím subsystému CEDR – web na Internetu MF, který umožňuje i tvorby sestav a výběrů.

ISPROFIN-EDS/SMVS - Informační Systém PROgramového FINancování (ISPROFIN) je manažerský systém pro řízení a kontrolu čerpání položek státního rozpočtu. Dělí se na:

• EDS - Evidenční Dotační Systém eviduje a řídí poskytování návratných finančních výpomocí a dotací ze státního rozpočtu na pořízení nebo technické zhodnocení dlouhodobého hmotného a nehmotného majetku
• SMVS - Správa Majetku ve Vlastnictví Státu řídí poskytování prostředků ze státního rozpočtu na pořízení nebo technické zhodnocení hmotného a nehmotného dlouhodobého majetku státu.

Monit2014+ - Informační systém Monit2014+ je určen k procesnímu i datovému zabezpečení kompletního řízení a administrativních procesů nad projekty dotačních programů ze strukturálních fondů EU v České republice v programovém období 2014 - 2020.

Funkcionalita systému Monit2014+ pokrývá veškeré základní procesy životního cyklu dotačních programů i v rámci nich realizovaných konkrétních projektů.

Monit2014+ je napojen řadou rozhraní na desítky informačních systémů státní správy České republiky i Evropské unie podílejících se na implementaci dotačních programů EU.

Centrální systém práva - eSbírka/eLegislativa

Systém eSbírka se bude dělit na dvě části – na portál, kde se budou vyhlašovat závazná elektronická znění právních aktů vyhlašovaných ve Sbírce zákonů a mezinárodních smluv, včetně právně závazných úplných znění, a na databázi informací o právních aktech. Ta bude sloužit k pružné práci s aktuálními či minulými úplnými zněními právních předpisů, bude též obsahovat dokumenty související s právními předpisy, jako například výkladová stanoviska jednotlivých úřadů, umožní i vyhlašování závazné listinné podoby právního předpisu v textově zcela identické podobě elektronické. Vedle závazné podoby bude právní předpis v elektronické podobě zpřístupněn i v dalších formátech umožňujících následné využití dat v komerčních i neziskových projektech. Systém bude propojen se systémy Evropské unie EUR-Lex a N-Lex.

Systém eLegislativa představuje moderní nástroje pro tvorbu a projednání právních předpisů. Přináší významné změny do legislativní práce, zejména přípravu změn právních předpisů zápisem změn přímo do jejich úplného znění. Novely právních předpisů budou nově doprovázet jejich právně závazná úplná znění, což usnadní orientaci v častých změnách právního řádu. Zavedení eLegislativy přinese vyšší přehlednost tvorby, zejména projednání právního předpisu, a zároveň snížení počtu chyb v legislativním procesu a celkové zvýšení kvality a transparentnosti legislativního procesu.

Nová technická i legislativní podoba tvorby a publikace práva umožní, aby novely právního předpisu nově doprovázela jejich právně závazná znění, obsahující aktuální znění předpisu ve znění přijatých změn. To usnadní orientaci v častých změnách právního řádu.

Vyplývat z toho bude povinnost připojit se k tomuto systému a současně zákaz nakupovat komerční databáze právních předpisů (výklady jsou dovoleny).

Centrální systém nákupu a veřejných zakázek

Národní elektronický nástroj (NEN), jako klíčový prvek soustavy Národní infrastruktury pro elektronické zadávání veřejných zakázek (NIPEZ), je komplexní elektronický nástroj pro administraci a zadávání veřejných zakázek a koncesí pro všechny kategorie veřejných zakázek a všechny kategorie zadavatelů, vč. sektorových. NEN podporuje všechny rozsahy elektronizace od evidence zadávacích řízení po plně elektronické postupy.

NEN umožní provázání (elektronickou procesní integraci) na interní systémy zadavatelů i dodavatelů či systémy eGovernmentu v ČR. Plně podpoří plánovací aktivity, neboť často bude využíván pro veřejné zakázky realizované v rámci dlouhodobých investičních projektů.

Pro operace relevantní pro Státní rozpočet musí být NEN integrován jak na lokální rozpočetnictví úřadů, tak zejména na RIS-PR a RIS-RE z IISSP.

Uživatelské rozhraní NEN musí být zařazeno do centrálního Portálu úředníka (PÚ), dostupného pro ty OVS, pro něž by bylo nehospodárné budovat svůj lokání PÚ. Dále musí být uzpůsobeno tak, aby jej ostatní OVS jako jednu z mnoha centrálních služeb mohly řady zařadit do svých lokálních Portálů úředníka (Intranet).

Uživatelé NEN se k němu musí přihlašovat pomocí JIP. To znamená klienti VS (dodavatelé) pomocí NIA a úředníci pomocí JIP/KAAS.

Jednotné obslužné kanály a uživatelská rozhraní úředníků

Ve shodě s cílem a s principy poskytnout úředníkům efektivní navigační a uživatelské prostředí pro elektronické úřadování, pro elektronickou správu zdrojů úřadu a pro zaměstnaneckou samoobsluhu je potřeba výrazně posílit a rozvinou, případně nahradit dosavadní možnosti sdílených služeb Portál úředníka a CzechPOINT@Office.

Portál úředníka

Aktuálně plní tuto roli pouze portál IS o Státní službě (ISoSS), který má dvě části - veřejnou a část pro služební úřady, s přístupem přes JIP/KAAS.

Veřejná část poskytuje 3 funkce:

• Přihlašování na úřednickou zkoušku
• Evidence obsazovaných služebních míst
• Evidence provedených úřednických zkoušek

Portál ISoSS v sekci pro služební úřady umožňuje:

• Vkládání návrhů na systemizaci pracovních míst (a dále také Vlastní kontrola návrhů, Úprava návrhů, Odesílání návrhů do schvalovacího procesu, Možnost vkládání odůvodnění k návrhu, Prohlížení postupu schvalovacího procesu návrhu)

Pro každého úřadníka bude v jeho „kmenovém“ úřadě poskytnuto jednotné univerzální vnitřní navigační prostředí a webové uživatelské pracovní prostředí.

Portál úředníka (PÚ) bude federativní (federalizovaný) obráceným způsobem než PVS. Tj. budou existovat jednotlivé centrální portálové služby (HR, vzdělávání, NEN, IISSP, …), které budou připojovány do lokálního transakčního PÚ, do něhož by se měl postupně transformovat každý tzv. Intranet úřadu.

Vedlo toho se jeden z centrálních portálů VS, IKČR navrhuje, aby to byl personální portál ISoSS, rozšíří tak, aby pro úřední osoby a zaměstnance úřadů, pro něž je nehospodárné spravovat svůj vlastní PÚ, poskytl službu zprostředkování všech centrálních interních portálů na jednom místě.

Všechny funkce portálu úředníka, přesahující hranice „domovského“ OVS budou dostupné výhradně s využitím JIP/KAAS. Proto musí být i lokální IS dostupné se stejnou identitou nebo musí mít úřad pro Portál úředníka a do něj zařazené IS vybudovaný lokální Single-Sign-On řešení, integrované s JIP/KAAS.

CzechPOINT@Office

Jde o neveřejné pracoviště úřadu, kde úředník samostatně čerpá informace, ověřuje a předkládá podání v rámci k eGovernmentu. Je určeno pro úředníky orgánů veřejné moci, kteří ze zákona přistupují k rejstříkům nebo provádějí autorizovanou konverzi dokumentů z moci úřední. (Např. místo toho, aby občan nebo podnikatel dokládal Výpis z rejstříku trestů, úředník si pořídí nutný doklad pomocí Czech POINT@Office).

Jedná se o pracoviště na libovolném úřadě, s technickým vybavením stejným jako v případě veřejnosti přístupných pracovišť Czech POINT, tzn. standardní počítač s přístupem na internet, webový, formulářový a dokumentový prohlížeč, účet pro používání Czech POINT@Office (přístup pomocí dvojice certifikátů pro autentizaci a podpis žádostí).

Systém Czech POINT poskytuje rozhraní CzechPOINT@office, které je určeno pro orgány veřejné moci. Pomocí formulářů, dostupných v rozhraní CzechPOINT@office, mohou úředníci využívat pro výkon své působnosti. Jedná se zejména o:

• výpis a opis z Rejstříku trestů
• výpisy ze základních registrů
• autorizovanou konverzi z moci úřední
• agendy matrik
• agendy ohlašoven
• agendy soudů

Do oblasti nástrojů pro úředníky patří také podpora provádění autorizované konverze z moci úřední. K dispozici jsou dvě rozhraní systému CzechPOINT pro tuto úlohu:

• KzMU API 1
• KzMU API 2

CzechPOINT@Office bude postupně konvergovat k Portálu úředníka, splyne s ním nebo bude nahrazen a společně vytvoří jedno efektivní interní obslužné rozhraní.

Sdílené platformy a ICT infrastruktura VS ČR

Národní datová centra

Cílově jsou i NDC nadále nedílnou součástí IKČR, budou se rozvíjet vedle eGC a často dokonce ve stejných prostorách a se stejnými kvalitativními parametry, například bezpečnosti. Jejich role je pro řadu centrálních systémů eGovernmentu nezastupitelná.

Lze předpokládat, že bude společně s požadavky na parametry eGC definován povinný minimální standard pro NDC a že ještě několik resortních DC bude „povýšeno“ na NDC. Současně lze předpokládat, že části některých NSC se zapojí jako významné součásti státní části eGC a budou své služby nabízet vedle přímé dodávky „kmenovým klientům“ - organizacím svého zřizovatele, také volně, komukoli za podmínek eGovernment Cloudu.

Strategický rámec Národního cloud computingu – eGovernment cloud ČR

Cílem vybudování sdílených služeb eGovernment cloudu ČR (dále jen eGC) je významné zvýšení efektivity, flexibility a bezpečnosti a zároveň významné snížení pořizovacích a provozních nákladů provozu ISVS využitím sdílených cloudových služeb. eGC bude provozován jak státními, tak i komerčními provozovateli na základě společných standardů a pravidel.

Informační koncepce ČR zohledňuje základní cíle a koncepty eGC, stanovené usnesením Vlády ČR ve Strategickém rámci Národního cloud computingu (UV1499/16) a rozpracovávané v rámci projektu Příprava vybudování eGovernment cloudu, jehož výstupy dále upřesňovat standardy eGC a pravidla jeho provozu i využívání.

eGovernment cloud nabídne standardizované sdílené služby na úrovních IaaS (výpočetní výkon, datová úložiště, umístění v DC), PaaS (operační systémy, databáze, vývojová prostředí), SaaS (aplikační vrstva) a BPaaS (IT procesy, včetně jejich využití jako podpory k on-premise řešením). Z pohledu čtyřvrstvého modelu jsou služby IaaS a PaaS službami vrstvy IT technologické architektury, služby SaaS jsou službami vrstvy aplikační architektury a služby BPaaS službami vrstvy byznys - výkonu veřejné správy, její IT části.

Služby eGC budou definovány a popsány v centrálně řízeném Katalogu služeb eGC. Provozovatelé služeb eGC musí splňovat centrálně stanovované bezpečnostní a provozní podmínky. Splnění podmínek bude ověřováno atestačními středisky.

eGC bude poskytován jak formou centrálně řízeného nákupu služeb komerčních provozovatelů (tzv. komerční část eGC) pro ISVS s nižšími nároky na bezpečnost, tak i formou služeb provozovaných pod kontrolou státu (tzv. státní část eGC) pro služby s nejvyššími nároky na bezpečnost.

Aktuálně probíhající Projekt vybudování eGC analyzuje legislativní podmínky a připravuje definici právního rámce a nákupních procesů komerční i státní části eGC v souladu s platnou legislativou.

Služby eGC budou poskytovány ve čtyřech úrovních bezpečnosti, přičemž úrovně 1-3 budou poskytovány v komerční části eGC a úroveň 4 ve státní části. V rámci vybudování eGC vzniká i metodika hodnocení bezpečnostních dopadů ISVS pro určení příslušné úrovně bezpečnosti eGC.

Pro posouzení ekonomické výhodnosti služeb eGC vzniká metodika hodnocení celkových nákladů (TCO) porovnávající provoz on-premise proti využití služeb eGC.

V první fázi budování eGC bude využívání služeb eGC dobrovolné a zároveň proběhne sběr celkových kapacitních a finančních podkladů pro cílový rozsah eGC. V druhé fázi, po ukončení přípravy a schválení souvisejících legislativních změn, budou pro OSS uplatněny principy „cloud-first“ (povinné umístění ISVS do eGC, pokud dosavadní provoz nesplňuje požadavky bezpečnosti a spolehlivosti nebo když využití eGC je ekonomicky výhodnější než dosavadní provoz, nebo „cloud-only“ (pro systémy s nejvyššími nároky na bezpečnost).

Služby sdílených platforem a infrastruktury

Bude doplněno.

Komunikační infrastruktura

Zákon 365/2000 sb. v aktuálním znění zavedl povinnost publikovat služby ISVS jednotlivým uživatelům prostřednictvím Centálního místa služeb (CMS). V kombinaci s komunikační infrastrukturou veřejné správy zavádí CMS/KIVS pro jednotlivá OVS bezpečnou, od internetu oddělenou komunikační infrastrukturu, poskytující pro jednotlivá OVS:

• Bezpečný a spolehlivý přístup k aplikačním službám jednotlivých ISVS
• Bezpečnou a spolehlivou publikaci aplikačních služeb jednotlivých ISVS všem OVS působícím v daných agendách
• Bezpečný přístup do Internetu
• Bezpečný přístup k poštovním službám v internetu

Cílem je:

• publikovat bezpečným způsobem přes CMS/KIVS všechny aplikační služby centralizovaných ISVS se současným zajištěním bezpečného přístupu jednotlivých OVS k těmto službám při výkonu jejich působnosti.
• Umožnit bezpečný přístup k aplikačním službám ISVS určeným pro koncové klienty VS ze sítě internet
• Zabezpečit bezpečné síťové prostředí pro zajištění interoperability v rámci EU

Centrální místo služeb (CMS)

CMS je systém, jehož primárním účelem je zprostředkovávat řízené a evidované propojení informačních systémů subjektů státní správy ke službám (aplikacím), které poskytují informační systémy jiných subjektů státní správy.

CMS jako součást „referenčního rozhraní„ je podrobně definováno zákonem č. 365/2000.

Službou se v tomto kontextu myslí služba nějakého informačního systému státní správy-ISVS (aplikace), který je připojen k CMS skrze KIVS, jedna aplikace službu poskytuje a jiné ji používají (konzumují).

Řešení CMS je z důvodu zajištění vysoké dostupnosti redundantní na úrovni lokalit a uzlů (dva plně vybavené uzly CMS ve dvou různých lokalitách, každý uzel z redundantních komponent, redundantní konektivita uzlů CMS).

Důsledná implementace zásad/principů/architektury CMS pro propojení informačních systémů subjektů státní správy současně účinně eliminuje negativní dopady aktuálních hrozeb a problémů veřejného internetu (výpadky DNS, latence, DoS, …) na funkčnost ISVS.

Komunikační infrastruktura veřejné správy (KIVS)

Bude doplněno co to je, pro koho to je a jaká je leg. opora

Krajské konektory - ne (jenom) hvězda, ale sněhová vločka. , základní axiom je připojit krajskou síť jednou linkou na CMS.

Lze předpokládat změny, i legislativní, ve vztahu ke krajským sítím, vyplývající z architektonického požadavku, aby se všechny kraje a jejich koncové body připojovaly k centrálním sdíleným službám eGovernmentu bezpečnými síťovými prostředky (KIVS a CMS), nikoli veřejným internetem.

Pravidla pro sdílené služby na dalších úrovních veřejné správy

Sdílené služby resortních ministerstev

Kromě konceptu veřejnoprávních korporací jako takových, uplatňujícího se u samospráv, viz níže, je vhodné při sestavování informační koncepce, budování a realizaci architektury a budování služeb veřejné správy, uvažovat v pojetí celého resortu. Ministerstvo si dle zákona zpracovává informační koncepci samo pro sebe, a to i přes to, že poskytuje některé služby svým podřízeným a řízeným organizacím. Nemusí se přitom jednat o přímé služby ICT, ale ve všech případech je ministerstvo třeba gestorem za legislativu, ohlašovatelem agendy a jemu podřízené organizace pak mají legislativu naplňovat a agendy vykonávat, a to s využitím příslušných informačních systémů. Ministerstvo tak sdílí s úřadem roli věcného správce ISVS. I tam, kde jsou OSS samy správci vlastních informačních systémů, je pak vhodné uvažovat společně na celoresortní úrovni, neboť funkcionality a vazby ISVS jsou do značné míry určovány právě legislativou a definicí agend a jejich podrobností v RPP.

Stále platí, že jednotlivé orgány veřejné moci jsou do jisté míry samostatnými, nicméně jsou v řadě věcí závislé právě na svém ministerstvu. To je také často správcem příslušné rozpočtové kapitoly, a tedy i zajištuje financování rozvoje ICT, pochopitelně v souladu s eGovernmentem a informačními koncepcemi.

Z těchto důvodů je vhodné stanovit základní principy na úrovni celého resortu a učinit podřízené organizace odpovědné za jejich dodržování. Jedná se o principy stanovené v informační koncepci, v architektuře, i při rozvoji jednotlivých ISVS. Zákon o informačních systémech veřejné správy přitom umožňuje zpracovat informační koncepce jednotlivých orgánů veřejné moci tak, že bude zpracována resortní část IK společná pro všechny resortní organizace a u jednotlivých organizací se pak doplní jen nutná specifika, tím bude dosaženo jak povinnosti mít u každé organizace informační koncepci, tak i souladu na úrovni resortu. Lze to zajistit i tak, že resort vydá informační koncepci pro podřízené organizace, vždy ale musí být jasné, že podřízené organizace toto akceptují a je možno resortní IK považovat i za jejich informační koncepci.

Při uvažování na celoresortní úrovni není nutno zůstat jen u formálních koncepcí, je nanejvýš vhodné takový postup zvolit u přípravy legislativy, přípravy výkonu agendy veřejné správy, metodikách výkonu agendy a příslušných rozhodování, kontrole výkonu veřejné správy apod.

Ministerstvo jako takové by pak pro svoje organizace mělo plnit roli také metodického řízení, včetně společných postupů. Takovým případem jsou třeba výkon spisové služby, ekonomika, personální oblast apod. Zde je vhodné využít principu, kdy ministerstvo stanoví pravidla a metodiky a jednotlivé organizace s tím tedy nemají tolik metodické a organizační práce. Lze samozřejmě využít nejen lidský potenciál úředníků a pracovníků ministerstva, ale také možné technické prostředky. Opět může jako příklad sloužit zavedení celoresortního řešení ESSL, kdy se pořídí jednotná aplikační platforma ESSL, ta se pak provozuje v samostatných instancích pro jednotlivé organizace. Dalším takovým příkladem je celoresortní řešení pro ekonomický systém, webové portály, služby IDM, intranetové aplikace apod.

Sdílené služby územních samospráv

Specifická role samosprávy, kdy každý samosprávný celek je autonomní v oblasti samosprávných činností má rozhodující vliv na jakékoliv sdílení v IT. Rozmanitost velikosti municipalit (od krajů po nejmenší obce) má vliv na velikost jejich útvarů, které se zabývají ICT. Nejmenší municipality, které disponují ICT útvary, jsou obce s rozšířenou působností (ORP). Ve správním obvodě ORP je počet subjektů, kterým jsou poskytovány sdílené služby nebo data dostatečně velký, aby sdílení bylo efektivní, a současně počet umožňuje efektivní řízení. Existence útvaru ICT je rozhodující pro poskytování jakéhokoliv sdílení (služby, data). V současné době již řada ORP ve svém správním obvodě tyto služby poskytuje (Kladno, Vyškov).

Vláda v informační koncepci doporučuje municipalitám pro určitou dílčí sadu sdílených služeb použít jako základní prvek správní obvody ORP a vychází z následujících předpokladů:

• ORP jsou nejmenšími subjekty, které zpracovávají architektonický plán.

• Správní obvod ORP je jednoznačně dán a všechny subjekty, kterých se bude sdílení ve správním obvodě týkat, jsou známy.

• Poskytování služeb a dat je určeno standardy (spisové služby).

• Tento model již v řadě ORP funguje.

  Pro jiné sdílené služby (například dlouhodobé ukládání dokumentů v elektronických digitálních spisovnách) doporučuje IKČR využít sdílená centra krajů, neboť:

• Mají vybudovanou infrastrukturu

• Disponují IT kapacitami a kompetencemi

• …

Pro další sdílené služby, například pro aplikační služby ekonomických systémů nebo spisových služeb, doporučuje IKČR využít SaaS služby eGovernment Cloudu, protože:

• Procesy a o IT potřeby v těchto oblastech fungování samospráv jsou vysoce standardizované a opakovatelné, proto jsou velmi vhodné pro řešení v cloudu

• Tyto funkce a jejich podpora zůstávají v plné zodpovědnosti obcí, a proto tyto potřebují multitenantní řešení

  Úkolem NAP je pro jednotlivé potřeby formulovat nejužitečnější úrovně sdílení na jednotlivých těchto vrstvách hierarchie veřejné správy.

Sdílené aplikační služby kraje

Doporučujeme, aby kraje pro obce zřídily a poskytovaly služby například informačního systému spisové služby, respektive navazující digitální spisovny pro digitální i listinné dokumenty

Krajské sítě

Publikace služeb krajských center do krajské sítě a dále přes krajský konektor do CMS.

Sdílené aplikační, technologické a síťové služby ORP

IKČR navrhuje, aby malé obce, typicky všechny obce prvního a druhého typu, provozující méně než 10 přístupových zařízení, byly zproštěny povinnosti zajišťovat informatizaci svých služeb veřejné správy a svůj podíl na eGovenrmentu vlastními silami.

Namísto nich by dávalo smysl, aby tak činily, a to i za podmínek úhrady oprávněných nákladů, obce s rozšířenou působností, nejlépe obce v místech bývalých okresních úřadů nebo kraje. Tuto změněnou povinnost bude nutné dohodnout se zástupci území a samozřejmě jí podpořit legislativní úpravou.

Pravidla tvorby a údržby vlastní čtyřvrstvé architektury jednotlivých úřadů

V této kapitole IK ČR předepisuje pravidla pro návrh a výstavbu vlastních, lokálních architektur úřadů, a to primárně po architektonických vrstvách.

Současně v úvodu v návaznosti na výše uvedené architektonické principy eGovernmentu a principy rozvoje informatiky jsou uvedeny vybrané klíčové architektonické požadavky, které musí být uplatněny při návrhu koncepcí dlouhodobého rozvoje ISVS úřadů.

Architektonické požadavky

Architektonické požadavky navazují na tzv. konkrétní dopady architektonických principů a rozpracovávající je do konkrétních zadání, která musí být prokazatelně uplatněna při návrzích architektury úřadů v IK OVS a návrzích architektur řešení pro jednotlivé ISVS.

Architektonické požadavky budou průběžně zveřejňovány Ministerstvem vnitra v rámci jeho koordinační role (PV pro Architekturu RVIS, diskuse, spolupráce, zveřejnění).

Pravidla byznys architektury výkonu veřejných služeb úřadu

Z hlediska řízení informatizace představuje byznys architektura zadání pro efektivní IT podporu výkonu veřejné správy. Proto je aktuální model cílového stavu byznys architektury úřadu povinným předpokladem a nedílnou součástí informační koncepce každého úřadu, orgánu veřejné správy.

Rozdělení procesů a funkcí veřejné správy

Pro rozhodování o variantách architektury řešení IT podpory byznys potřeb výkonu veřejné správy úřadu je nutné všechny tyto byznys potřeby VS vyhodnocovat a třídit z několika úhlů pohledu.

Vedoucí informatiky úřadu a techničtí správci ISVS jsou povinni ve spolupráci s jejich věcnými správci vytvořit a udržovat aktuální model procesní, respektive funkční dekompozice úřadu a její diagram, tzv. Mapu byznys portfolia/architektury úřadu.

Tento model musí z podstaty komplexního řízení informatizace úřadu obsahovat identifikované všechny činnosti (schopnosti, procesy, funkce nebo služby, dále zastoupeny pouze pojmem funkce), které organizace vykonává, ať již jsou aktuálně manuální nebo elektronizované. Jako součást prostředků dlouhodobého řízení rozvoje IS úřadu musí být u všech těchto funkcí úřadu vyhodnoceno, do jaké míry uspokojivě a efektivně jsou podpořeny informačními technologiemi a do jaké míry tak má být cílově učiněno v časovém horizontu informační koncepce úřadu (5 let). Tato část Informační koncepce OVS pak musí obsahovat a zohledňovat zejména:

• rozhodnutí o konsolidaci IT podpory byznys funkcí úřadu
• rozhodnutí o možnostech sdílené IT podpory byznys funkcí úřadu
• optimalizaci funkcí úřadu s podporou ICT - doplnění a rozvoj nedostatečné ICT podpory funkcí úřadu

Přitom je nutné pohlížet na identifikované funkce úřadu a rozhodovat o nich přinejmenším z následujících čtyřech hledisek:

1. hledisko míry podpory externích služeb pro klienty veřejné správy

2. hledisko míry (a potenciálu) podobnosti, jednotnosti a centralizace procesů

3. hledisko míry (a potenciálu) vymístění funkcí a využití sdílených služeb na místo individuálních funkcí

4. hledisko výkonu funkcí úřadu vlastním nebo cizím jménem a na vlastní nebo cizí účet

Ad a) Hledisko klasifikace dle podpory služeb pro klienty. Pro usnadnění modelování byznys vrstvy architektury úřadu vydává a aktualizuje OHA MV akcelerátor, zvaný Referenční model byznys architektury úřadu. Ten dělí funkce úřadu do vrstev podle jejich „vzdálenosti“ od poskytování služeb pro externí klienty takto:

440x237px

8. Základní dělení funkcí, procesů a služeb úřadu

• Hlavní procesy, funkce úřadu - úřad vykonává v interakci s externím klientem nebo pro výkon služby veřejné správy externímu klientovi
• Podpůrné procesy, funkce úřadu - úřad vykonává jako předpoklad, přímou podporu nebo návaznost na individuální poskytování služeb externím klientům
• Funkce a procesy správy zdrojů - úřad vykonává pro zajištění všech ostatních předpokladů a zdrojů dle své role a pozice ve veřejné správě, bez přímé souvislosti s podporou služeb svým individuálním externím klientům.
• Řídící a rozvojové funkce - vykonává úřad, aby byl schopen plánovat, realizovat, monitorovat a vyhodnocovat kvalitu a výkonnost svých funkcí a jejich další rozvoj.
• Provozní funkce - vykonává úřad pro základní zajištění své udržitelné existence (provozu), bez ohledu na to, jaké jsou jeho hlavní, podpůrné a zdrojové funkce.

Referenční model byznys architektury úřadu dále dělí hlavní funkce pro výkon služeb zejména externím klientům (občané a zástupci organizací), ale i interním klientům (úřady a úředníci) na:

• Obslužné funkce - představující interakci s klienty ve všech a v kterémkoli obslužném a komunikačním kanálu, angl. Front-Office (dále také FO), cílově co nejvíce společně a jednotně, napříč agendami.
• Odborné funkce - představující specializaci na výkon a rozhodování v agendě či provozní funkci, angl. Middle-Office (dále také MO). Dále mohou být děleny na:

• Generické odborné funkce veřejné správy (vidimace, konverze apod.)
• Agendově specifické funkce veřejné správy

• Funkce společného zázemí agend - představující funkce vykonávané typicky (ale ne výhradně) mimo interakci s klientem, z angl. Back-Office (dále také BO), společně a jednotně pro více (až pro všechny) agend úřadu.
• Funkce správy spisů a případů - sloužící ke správě dokumentů a informací propojujících jednotlivé fáze (a funkční oblasti) vyřizování případů (řízení) klientů, interních i externích.
• Funkce integrace a spolupráce mezi úřady při výkonu služeb klientům.

604x385px

9. Další dělení (klasifikace) funkcí, procesů a služeb hlavní oblasti v kontextu ostatních funkčních oblastí.

Ad b) Hledisko jednotnosti a centralizace.

Takto identifikované a klasifikované funkce úřadu je nutné posuzovat podle míry jejich jednotnosti v organizaci (úřadu, korporaci - resortu nebo samosprávné jednotce, eGovernmentu) a potenciálu pro jejich sjednocení a případnou centralizaci - z vlastního rozhodnutí v úřadu nebo samosprávné jednotce, či ze zákona v rámci celé veřejné správy.

Ad c) Hledisko vymístění (outsourcingu) a využití sdílených služeb.

Identifikované funkce v modelu byznys architektury úřadu je nutné posuzovat z hlediska dostupnosti již sdílených byznys služeb nebo potenciálu na vymístění (outsourcing) k poskytovateli takové sdílené služby - uvnitř úřadu nebo samosprávné jednotky z vlastního rozhodnutí, jinde ze zákona.

Přitom rozlišujeme následující možnosti (úrovně) sdílení na:

595x66px

• Celostátně (celoplošně) sdílené služby. Ty se na této i na všech další úrovních dělí ještě na:

• služby externí na podporu klientů veřejné správy (a případně OVM) - služby hlavních a podpůrných procesy
• služby interní na podporu úřadů a úředníků - služby zdrojových, řídících a provozních procesů

• Sdílené služby veřejnoprávních korporací (správců rozpočtových kapitol, krajských a místních (ORP) územních korporací)
• Sdílené služby uvnitř úřadu - typicky služby pro obslužné funkce (FO), pro funkce zázemí agend (BO) a pro funkce správy spisů a případů
• Individuální (dílčí, specifické, nesdílené) funkce - typicky odborné agendové funkce (MO)

Ad d) Hledisko výkonu funkcí vlastním jménem a na vlastní účet.

Jako protipól funkcí předaných k vykonání jinému úřadu, organizaci, vyskytují se v orgánech veřejné správy funkce vykonávaném pro někoho jiného, tj. cizím jménem, na cizí účet, případně obojí. U všech identifikovaných funkcí úřadu je nutné - vždy posuzovat i tento aspekt, tj. u činností (procesů, funkcí, služeb) čím jménem a na čí účet jsou vykonávány.

Podle všech výše uvedených úhlů pohledu se liší potřeby funkcí úřadu na jejich aplikační podporu, proto je nutno mezi nimi rozlišovat a následně podle tohoto navrhovat řešení této aplikační podpory a volit způsob její realizace. Je důležité tyto vlastnosti funkcí úřadu znát a rozvoj aplikací úřadu podle nich prokazatelně řídit.

Detailní referenční modely byznys architektury, rozpracovávající zde uvedená pravidla, včetně jejich grafického vyjádření tj. Map, stanovuje a publikuje OHA MV, ve spolupráci s OeG a organizacemi zastupujícími jednotlivé úrovně státní správy a samosprávy.

Ohlášení agend úřadu v RPP

Zákon 111/2009 Sb. o základních registrech zavedl jednoznačnou hierarchii agend a agendových informačních systémů spolu s vyznačením jak údajů, které jsou v rámci agendy vedeny, tak údajů, které je agenda oprávněna při své činnosti využívat ze základních registrů a dalších agend. V rámci tohoto textu jsou uvedeny důsledky plynoucí pro návrh architektury informačních systémů na všech vrstvách modelu.

Agendu definuje ústřední správní úřad zodpovědný za výkon agendy v právní terminologii. Při popisu údajů se tedy nevyužívá technologická terminologie, ale terminologie uvedená v příslušném právním předpise.

Úřad působící v agendě již nemůže ovlivnit ohlášení agendy, může případně požadovat na ústředním správním úřadě, který agendu ohlásil, její úpravu.

Logika ohlášení agend stanovuje, jaké údaje jsou v agendě vedeny o jednotlivých subjektech/objektech práva tak jak jsou definovány v legislativním textu. V rámci přijaté notace je kód agendy označován velkým písmenem A následovaným přiděleným číslem agendy. Jednotlivé subjekty/objekty, o kterých jsou v agendě vedeny údaje (kontexty) jsou dále postupně číslovány. Následuje číslo údaje v rámci kontextu.

Tedy například

• Agenda A998 Agenda o podmínkách provozu vozidel na pozemních komunikacích
• má uveden jako první kontext 998-1 Silniční vozidlo
• který má jako první údaj 998-1-1 Údaje o vlastníkovi a provozovateli, není-li totožný s vlastníkem

Smyslem této registrace není detailní datový rozpad na položky ve smyslu informatickém, ale stanovení údaje, na který může být vztaženo oprávnění k využívání. Je tedy zřejmé, že údaj 998-1-1 se následně rozpadá na informatické položky (viz zákon č. 56/2001 Sb., o podmínkách provozu vozidel na pozemních komunikacích,§ 4 odst. 2) písmeno a).

Každá informatická položka tedy musí být uvedena jako další vrstva v notaci

998-1-1-1 Jméno vlastníka silničního vozidla.

Smyslem této notace, oznámení agend v Registru práv a povinností a následné technologické specifikace je jednoznačné oddělení právních a informačních zodpovědností. Při návrhu publikace prostřednictvím Propojeného datového fondu (eGSB) tedy správce agendy definuje právní rozdělení kontextů a údajů a správce příslušného agendového informačního systému následné informační rozdělení těchto údajů. Toto rozdělení pak jednoznačně definuje položku v předávané datové větě v rámci propojeného datového fondu a řízení oprávnění přístupu k této položce.

Správce Agendového informačního systému tedy musí spolupracovat se správcem agendy na ohlášení agendy tak, aby bylo možné provést jednoznačnou dekompozici údaje v kontextu na jedno informační položky. Definice těchto informačních položek je následovně součástí definice datového rozhraní.

Zvolený princip zamezuje záměnám údajů podle jejich názvů (jméno vlastníka vozidla je určitě něco jiného než jméno vlastníka nemovitosti, ačkoli se obě položky jmenují jméno) a je nutné při návrhu všech datových rozhraní používat výše uvedenou číselnou hierarchickou notaci.

Správce agendy při ohlášení také určuje, jaké údaje ze základních registrů či jiných agend má oprávnění při své činnosti využívat a správce agendového informačního systému pak při návrhu datového rozhraní čerpá z definice datových položek jednotlivých ISVS, které údaje/data publikují do propojeného datového fondu veřejné správy (definice WSDL na eGSB).

Pokud je agenda vykonávána prostřednictvím více Agendových informačních systémů, pak správce agendy musí určit toho správce agendového informačního systému, který bude závazně určovat rozpad údaje na datové položky, a ostatní správci agendových informačních systémů musí tento rozpad respektovat.

Rozdělení obslužných a komunikačních kanálů veřejné správy

Obslužné a komunikační kanály úřadu veřejné správy vůči jeho externím klientům je pro účely jejich efektivního řízení a jejich IT podpory možné dělit z několika úhlů pohledu, a to podle:

• Sdílení a subjektivity provozovatele obslužného kanálu na vlastní, centrální, v přenesené působnosti, u poskytovatelů služeb a další
• Podle míry zapojení klienta na samoobslužné nebo asistované (osobní, vně listinné či hlasové, ale vnitřně plně elektronické)
• Podle vazby na místo a agendu na univerzální - bez místní a věcné příslušnosti, územní - s místní, ale bez věcné příslušnosti a agendové - s věcnou příslušností (jedné nebo více agend téhož ústředního správního úřadu), ale bez místní příslušnosti.
• Podle komunikačního média a prostředku podání/doručení na osobní - diktát do protokolu na přepážce, listinné - poštou, kurýrem nebo na podatelně a na elektronické - Datovou schránkou, elektronicky podepsaným dokumentem do elektronické podatelny nebo do specifické aplikace úřadu (dle zvláštních zákonů).

600x65px

Cílem je, co nejvíce potřeb klientů obsloužit v prvním stupni obsluhy, v univerzálních kontaktních místech (UKM) - klientských centrech, jako je samoobslužný Portál klienta (občana, podnikatele, zástupce organizace a cizince) v PVS a asistovaný CzechPOINT. Přitom pro nezbytné individuální služby budou nadále k dispozici specializovaná kontaktní místa úřadů.

Zásadou je, že v kterémkoli UKM nalezne klient informace o všech svých kontaktech a řízeních s veřejnou správou.

V případě asistovaných kontaktních míst (univerzálních i v OVS) však zprostředkuje informace o všech informacích ze vztahu klienta a veřejné správy úředník, výhradně na základě explicitního zmocnění klientem. To je jediný případ, kdy smí úředník najednou vidět více než jednu agendu současně, přitom ale smí vidět pouze stavové informace z notifikací, tj. zda by měl klient agendě věnovat pozornost pro nějaké právo nebo povinnost. Na základě takového přehledu může dát klient pokyn, aby pro něj vyřízení jednotlivých agend po jedné úředník zprostředkoval.

Všechny úkony v obslužných kanálech musí být adekvátně zaznamenány ve spisové službě úřadu.

Úřad veřejné správy je povinen v legislativě (může-li ji ovlivnit), v procesech úřadu a v jejich aplikační podpoře (v rozsahu dle platné legislativy) zajistit plnou rovnoprávnost všech obslužných kanálů a umožnit klientovi volbu mezi kanály.

Preference kanálu, efektivnějšího z pohledu úřadu, tedy typicky elektronického samoobslužného kanálu, je možná pouze zvýšením jeho atraktivity pro klienta, nikoli regulatorním opatřením (nařízením, sankcí).

Pro informatickou podporu v úřadu dále vyplývá, že na konci horizontu pravidel této IKČR, aktuálně v roce 2022, platí pro všechny agendy úřadu, že:

• Všechna řešení (zákonná i informatická) musí být navržena tak, aby vnitřně byla plně elektronická a vně podporovala všechny obslužné kanály (konverze dokumentů).
• Všechny kontaktní kanály, včetně specializovaných, budou podporovat navigaci ke službě (vyhledání služby) podle životních situací, vyplývajících z životních událostí klientů.

Budou navrženy takové úpravy právního prostředí a IT řešení, aby v dlouhodobém horizontu podporovaly rovnost a provázanost obslužných kanálů (Multichannel) - tj. řízení je možné v kterémkoli kanálu začít, v jiném sledovat jeho průběh a v jiném řízení dokončit.

Portály občana a úředníka

Portál je mimo jiné i technickým nástrojem pro on-line transakční služby klientům veřejné správy, pro informování o výkonu veřejné správy a pro interaktivní komunikaci ze strany klienta. Proto mají být součástí portálu také popsané životní situace (pokud možno interaktivní na základě parametrů), ale i elektronické formuláře pro podání a pro úkony učiněné klientem vůči orgánu veřejné moci, a to se schopností předvyplnění a dotažení dokládaných údajů.

Portály tedy nemohou být samostatné a nepropojené aplikace, ale naopak musí se jednat o prostředek, který je integrován s informačními systémy v úřadu. Především s elektronickou spisovou službou, s agendovými informačními systémy, ale třeba i s ekonomickými systémy tam, kde se jejich prostřednictvím shromažďují údaje o výplatách či o poplatcích podle jednotlivých klientů. Portál má sloužit klientovi k získání informací, jako prostředek pro publikování otevřených dat, statistik a veřejných výstupů, pro elektronická podání a komunikaci klienta s úřadem apod. Nově musí portál sloužit i držitelům zaručené elektronické identifikace jako prostředek pro získání jejich údajů, pro různé notifikace, ale třeba i pro interaktivní podání žádostí, či podání žádostí o výpisy apod.

Oba typy samoobslužných kanálů přístupu k externím a interním službám veřejné správy mají mnoho společného, ale v něčem se liší. Oba typy portálů mají uživateli zpřístupnit postupně všechny jemu nabízené elektronické služby a oba tak učiní hierarchickým, federalizovaným způsobem.

V případě Portálu občana v PVS stojí občan jako samoobslužný uživatel „vně“ veřejné správy a portál mu poskytuje jedno univerzální vstupní místo dovnitř. Z toho důvodu jsou všechny věcné (agendové) a do budoucna i místní portály se svými službami federalizovány „pod“ tímto ústředním portálem.

V případě portálů samospráv se předpokládají dva trendy: a) jednak budou lokální portály samospráv obsahovat obrácený směr navigace do Portálu občana, kde bude moci klient vyřídit vše ostatní ze státní správy, co případně nenašel v místním portálu a b) lokální portály budou moci být v dlouhodobé perspektivě nahrazovány místně přizpůsobenými službami centrálního Portálu občana v PVS.

Naproti tomu v případě Portálu úředníka stojí úředník hluboko „uvnitř“ veřejné správy, nachází se ve svém úřadu, kde je ve státní službě nebo zaměstnán, a proto jako Portál úředníka primárně užívá Portál (Intranet) úřadu, resortu, kraje, obce. Tento lokální portál úředníka je pak federalizován s centrálním Portálem úředníka, který postupně agreguje (poskytuje) všechny celostátní elektronické služby pro úředníka. Úředník se tak prostřednictvím svého portálu dívá „ven“ ze svého oddělení, na všechny elektronické služby úřadu, resortu či korporace a celého eGovernmentu.

Všechny sdílené portálové komponenty, které mají být užívány v lokálních portálech úředníka, musí být technicky i licenčně vyřešeny tak, aby se v těchto portálech daly využívat bez omezení a bez další finančních nároků.

Služby pro životní situace - úplné elektronické podání (ÚEP)

Zejména byznys a aplikační architektura úřadu musí být v nových a významně měněných agendách a řešeních jejich IT podpory upravena tak, aby podporovala tzv. úplné elektronické podání (ÚEP), viz definice a požadavky v kapitole 2.4.2

Vliv byznys architektury úřadu na možnosti řešení její IT podpory

Z charakteru činností úřadu, viz dekompozice výše, vyplývá, jaké jsou možnosti pro sdílení a dosažení efektivní aplikační podpory těchto činností.

Tam, kde úřad ze zákona zůstává zodpovědný za určitou činnost (agendu, podpůrnou funkci) nemůže využít sdílených řešení a ani na úrovni centrálních prvků eGovernmentu nebudou taková sdílená řešení připravována, dokud se zákonné podmínky pro tuto oblast nezmění.

Příkladem je ERP (rozpočetnictví) nebo spisová služba. Zde jak procesy, tak jejich aplikační podporu musí mít každý úřad vlastní, zůstává věcným správcem těchto řešení. Pokud je tedy úřad věcným správcem nějakého řešení, zachovává si za něj zodpovědnost a pravomoc o něm okamžitě rozhodovat - musí to být řešení v pravomoci tohoto úřadu.

V takovém případě, pro taková řešení jako je ERP nebo eSSL může OVS využít sdílené služby pouze na IT technologické a platformové úrovni, SW řešení mu musí poskytnuto maximálně tzv. multitenantní formou (více samostatných nájemníků) na společné technické infrastruktuře.

Pravidla aplikační architektury IS VS úřadu

Z hlediska řízení informatizace představuje aplikační architektura těžiště řízení efektivní IT podpory výkonu veřejné správy. Rozvoj všech informačních systémů úřadu se děje prostřednictvím rozvoje jeho komponent a v kontextu všech ostatních aplikačních komponent úřadu a aplikačních služeb eGovernmentu. Proto je aktuální model cílového stavu aplikační architektury úřadu základem informační koncepce každého úřadu, orgánu veřejné správy.

Informační systémy veřejné správy slouží pro podporu výkonu agendy či agend veřejné správy. Musí tedy sloužit pro úředníka jako prostředek, který ho provádí jeho úřední činností a který mu pomáhá při jeho úřední práci, shromažďuje a doplňuje potřebné údaje, hlídá naplnění určitých povinností a nabízí řešení, ale třeba by měl být schopen i připravit návrh rozhodnutí v dané věci. Úředník by v ISVS měl dostat komplexní nástroj, který za něj vyřeší veškerou či alespoň značnou část administrativy a úředník tak bude mít čas na práci s klientem a na skutečné správní rozhodování tam, kde je takového rozhodování třeba.

Principy klasifikace aplikací dle referenčního modelu

Informační systémy veřejné správy (ISVS), tak jak je definují jejich agendové nebo jiné zákony, se tedy obvykle skládají z jedné nebo více aplikačních komponent. Aplikační komponenty ISVS a ostatních informačních systémů úřadu, lze pro účely jejich správy dělit například podle míry sdílení aplikačních služeb a podle klientů těchto služeb, nebo podle vztahu IS k řetězci obsluhy klientů veřejné správy.

Vedoucí informatiky úřadu a techničtí správci ISVS jsou povinni ve spolupráci s jejich věcnými správci vytvořit a udržovat aktuální model dekompozice aplikačních komponent a aplikačních funkcí úřadu a její diagram, tzv. Mapu aplikačního portfolia/architektury úřadu.

Podporu pro rozhodování při řízení životního cyklu aplikačních komponent informačních systémů VS a současně vyjádření nejlepší praxe jejich inventarizace a třídění poskytuje tzv. Referenční model aplikační architektury, který základem aplikační mapy úřadu.

487x213px

10. Rozdělení aplikačních komponent úřadu do vrstev

Dělení vychází z účelu aplikačních komponent shora počínaje úlohou uživatelského rozhraní a navigace až po platformy, zcela nezávislé na druzích uživatelů a poskytovaných služeb úřadu. V aplikační mapě se toto dělení uplatní jako vrstvy vertikální dimenze, viz obrázek 10.

604x245px

11. Rozdělení transakčních a informačních (analytických) komponent

Dále dělení aplikací vychází z byznys logiky podporovaných funkcí, kde na jedné straně jsou funkce (služby) pro vnější klienty, partnery a veřejnost, na druhé straně jsou funkce detailně podporující jednotlivé klíčové zdroje úřadu (znalosti, zaměstnance, majetek a zásoby (a jejich dodavatele), případně svěřené registry), viz obrázek 11.

Rozsah a obsah aplikací pro obslužné, odborné a funkce zázemí agend se liší podle segmentů veřejné správy. Odlišnosti ostatních kategorií jsou minimální, převažují obdobné a jednotné aplikační funkce.

Povinností ředitele informatiky úřadu (technického správce) je zohlednit vzájemnou podobnost aplikací podle jejich kategorie při rozhodování o konsolidaci aplikací nebo o návrhu aplikační podpory v kategoriích, kde je tato nedostatečná nebo chybí.

Referenční model aplikační architektury s plným detailem třídění a s odlišným obsahem klíčových transakčních komponent pro jednotlivé odlišující se segmenty veřejné správy (např. zdravotnictví, pojistné agendy, dotační agendy, správa síťové infrastruktury apod.) stanovuje a publikuje OHA MV.

Pokud zákon pro nějakou agendu definuje i způsob IT podpory evidence údajů, a zmocňuje tak k implementaci ISVS, není tím stanoveno, že by tento systém nemohl některé své komponenty využívat společně s ostatními agendami (a agendovými systémy) téhož úřadu.

Na druhou stranu dosud není možné, nestanovuje-li to explicitně zákon, sdílet v ISVS aplikační komponenty vlastněné jiným úřadem (ani příslušnou korporací, tj. rezortem, krajem nebo ORP).

Z toho vyplývá aktuálně proveditelný požadavek optimalizace procesů a aplikačního portfolia úřadu tak, že pro průřezové procesy agend (podobné, příbuzné či jednotné byznys funkce a procesy) využije jednotných nebo dokonce centrálních sdílených komponent aplikačního portfolia úřadu (např. pro obsluhu klientů na přepážkách, portálovou samoobsluhu, řízení kontrol na místě, příjem a párování plateb apod., transkripce jmen osob ze zemí používajících jiné písmo, než latinka).

Pokud se takto sdílí v úřadu několik komponent napříč agendami, používají tyto pro externí označování klienta nikoli AIFO, ale nejlépe nějaké společné klientské číslo občana v rámci systému úřadu. AIFO bude využíváno pouze při externí výměně údajů o klientovi v agendě prostřednictvím Back-End integrace přes ISZR a eGSB.

Pravidla pro uživatelská rozhraní a přístup k informačním systémům

Uživatelská rozhraní ISVS i provozních systémů musí být především ergonomicky optimální pro nejlepší podporu odpovídajících uživatelských rolí a jejich výkonu externích i interních funkcí veřejné správy.

• Úřad musí mít všechny svoje formuláře primárně v autentizované zóně portálu a umožnit předvyplnění údajů z PPDF s využitím zaručené identity klienta
• Agendové a místní portály se budou rozšiřovat z informačních na transakční (ÚEP)
• Transakční obsah portálu (formuláře) musí být integrován (federalizován) s PVS - Portál občana (cílově s předáním identity)
• Identifikace uživatelů v portálu musí využívat národní identifikační schéma (NIA)

V případě uživatelských rolí zaměřených na jedinou agendu nebo malou část provozních funkcí, tj. roli pracující výhradně v určitém „informačním silu“, je upřednostněna efektivita práce před univerzalitou a skladebností uživatelského rozhraní.

IS poskytující služby uživatelům, kteří mají více rolí, často je střídají nebo potřebují informační podporu napříč „informačními sily“, musí vedle toho disponovat i odděleným (de-coupled, sligtly coupled), servisně orientovaným uživatelským rozhraním. Z toho současně plyne, že všechny odpovídající aplikační komponenty musí být alespoň „service enabled“, tzn., musí své funkce pro taková UI poskytovat v podobě orchestrovatelných webových služeb.

Kromě výjimečně zdůvodnitelných případů, například modelovacích nebo GIS nástrojů, nebo při nedostupnosti dostatečně propustného internetového připojení, nesmí být žádná byznys logika obsažena v uživatelském rozhraní, nýbrž musí být z aplikačních serverů dostupná jednotně pro všechny použité typy UI (lokální klient, webový klient, mobilní klient). Důvodem je usnadnění jednotné údržby byznys logiky při neustálých změnách (parametrizaci) funkcí IS.

IKČR předpokládá postupné sjednocování (unifikace) vzhledu a chování portálových aplikací ústředních správních úřadů pro dosažení jednotného uživatelského zážitku klienta. To platí zejména poté, co budou elementární služby úřadů dostupné „proklikem“ z portálu občana.

U místních portálů obcí IKČR naopak předpokládá i nadále lokální specifický „look & feel“, který podporuje sounáležitost občana s obcí, jako klíčovou podporovanou hodnotu, vedle ergonomie a efektivity obsluhy, která tím nesmí být dotčena.

Cílově IKČR předpokládá, že obce budou moci na místo budování lokálních portálů využívat SaaS služeb Portálu občana v PVS, a to v prvním kroku pro svěřené služby státní správy v přenesené působnosti, později i pro služby samosprávy a hospodářskou činnost obce. Proto tento účel bude v PVS možnost služby graficky lokalizovat, avšak při zachování jednotné navigace a nástrojů obsluhy.

Pravidla pro obslužné agendové aplikace (FO)

Cílově musí být obslužné aplikační funkce jednotné a centralizované v úřadu, resortu (nebo korporaci) a státu tak, aby klientům veřejné správy umožňovaly dobrý „zážitek“ a efektivní obsluhu, a to úměrně výše uvedenému členění obslužných kanálů veřejné správy a požadavků na jejich podporu.

To znamená, že aplikace obslužných kanálů stejného typu, například externí portál, musí být hierarchicky federativně integrované nebo zcela centrální. Aplikace různého typu, například uživatelské rozhraní pro fyzickou přepážku a pro portál musí být vzájemně integrovány tak, že užívají společnou aplikační logiku komunikace s klienty, která není vestavěna ani do portálu, ani do přepážkového SW, ale právě do společného aplikačního SW obslužných kanálů, také označovaného CRM, což ve veřejné správě znamená Citizen Relationship Management.

CRM společně s komunikačními technologiemi (web, mail, telefon, chat, SMS, DS, a další) zajistí jednotnou vícekanálovou obsluhu (multichannel, omnichannel).

Podstatnou část agendové byznys logiky přebírají obslužné kanály z agendově specifických (Middle-Office) systémů a ze systémů agendového zázemí (Back-Office).

Pravidla pro odborné (specifické) agendové aplikace (MO)

Ve všech případech, kdy má být veřejná služba v agendě zajišťována v přenesené působnosti nebo ve vlastní působnosti plošně v pobočkové síti (FŘ, OSSZ, Okresní soudy) je povinností ústředního správního úřadu ohlašujícího tuto agendu vystupovat jako věcný správce jejího ISVS a zajistit pro takovou agendu centrální agendový informační systém, pokrývající odborné agendové funkce (MO), případně funkce agendového zázemí (BO).

Tento systém musí být dostupný prostřednictvím síťové infrastruktury státu ve všech obslužných místech veřejné správy, agendových i univerzálních. Musí být uzpůsoben k integraci na lokální i na celostátní aplikační komponenty pro obsluhu klientů (FO), pro lokální společné funkce zázemí agend (platby, vedení spisu apod.) (BO), zejména pak musí být integrovatelný na lokální spisovou službu, lokální saldokontní účetnictví klientů a lokální EkIS úřadu.

Uživatelské rozhraní těchto centrálních AIS musí být zařaditelné a volatelné z jednotné transakční navigace v centrálním portálu úředníků (intranetu veřejné správy) i (dočasně) v lokálním intranetu úřadu.

Pro aplikační architekturu úřadu potom platí, že úřad musí buď:

a) využívat tuto centrálně sdílenou aplikační komponentu, tj. poskytnout uživatelům úřadu uživatelský přístup k této komponentě prostřednictvím JIP/KAAS a integrovat tuto komponentu na Back-Office s ostatními nezbytně místními komponentami úřadu, jako je spisová služba úřadu nebo systém řízení obsluhy klientů.

b) využívat vlastní agendový systém úřadu pro tuto agendu, integrovaný na centrální sdílenou komponentu, sloužící jako její „tlustý klient“, avšak s plnou odpovědností úřadu za jeho legislativní aktualizaci.

Pro obě varianty platí závazně jak pro věcného správce centrálního systému, tak pro lokální úřad s tím, že jak jejich interní zaměstnanec, tak externí klient nesmějí v rámci poskytnutí jedné služby této agendy v žádném případě zadávat žádné údaje dvakrát.

Výše uvedená centrální odborná agendová aplikace musí být správcem (ohlašovatelem agendy) poskytnuta včetně samoobslužného zákaznického portálu občana/podnikatele, zajišťujícího splnění principu Once Only. Současně tato centrální aplikace publikuje v agendě evidované autoritativní údaje do PPDF a publikuje veřejné údaje agendy do VDF jako otevřená data.

Pravidla pro aplikace agendového zázemí (BO)

Pokud úřad je činný ve více agendách, které všechny vedou na obdobné funkce zázemí agend (BO), například vedení spisu, příjem poplatku, výplata dávky, apod., bude pro tyto funkce užívat sdílené řešení (spisovou službu, saldokontní účetnictví, …) a měl by postupně sjednotit legislativu a procesy v těchto oblastech funkcí.

Klíčovou komponentou této oblasti z pohledu klientů i úřadu je komponenta pro vedení kmene klientů a jejich pohledávkových/závazkových účtů (saldokonto). Tyto komponenty by měly být v každém úřadu centrální a jednotné, napříč agendami.

Sdílená řešení pro agendové zázemí mohou být sdílena nejen pouze v úřadu, cílově ale také v resortu/korporaci nebo celostátně, jakmile to bude legislativně a technicky možné a dostupné.

Systém elektronické spisové služby je z hlediska procesů úřadu natolik zásadní a natolik specifický, že ač je dle definice nástrojem agendového zázemí (BO), byla pro tyto systémy a pravidla pro ně vytvořena zvláštní kategorie, viz dále.

Pravidla pro aplikace spisové služby a správy případů

Každý úřad by měl pro evidenci všech úředních dokumentů zavést, provozovat a využívat jeden systém elektronické spisové služby, sdílený všemi agendami a útvary úřadu, pokud se z pohledu dobrého hospodáře nevyplatí užívat pro některou agendu samostatnou evidenci dle zák. o archivnictví. V takovém případě musí být obě evidence integrovány tak, aby se uživatelsky daly využívat společně (například v nich vyhledávat, nebo do nich volat služby s dotazem na stav dokumentu).

Pokud úřad pro své agendy vede více dokumentů pro jedno řízení (případ) v tzv. spisu, měl by jako společnou a sdílenou komponentu zvážit právě funkcí správy těchto případů a spisů. Pokud navíc postupně stále více agend je ve svém vyřizování elektronizováno a automatizováno jako tzv. elektronické Workflow, měl by úřad disponovat jedinou sdílenou komponentou pro řízení tohoto workflow nad případy (a dokumenty nebo transakcemi) klientů.

Pravidla pro kategorii znalostních systémů

Znalostní systémy v úřadu musí být konsolidovány tak, aby všechny informace a znalosti úřadu, s výjimkou informací o individuálním výkonu moci v agendě a klasifikovaných informací, byly dostupné pro vzdělávání a podporu výkonu služeb pro všechny zaměstnance úřadu, se společným vyhledáváním informací v intranetu úřadu.

Pro informační systémy poskytující informace o platném, historickém i připravovaném právu platí, že v úřadech mohou být provozovány jenom takové systémy a pouze pro takové funkce, které nejsou podporovány centrálním systémem eSbírka/eLegislativa.

Pravidla pro podpůrné IT systémy

Pravidla pro identity management (IDM)

Každý úřad je povinen zvážit ve své architektuře pořízení řešení pro centrální správu identit a oprávnění uživatelů úřadu a její integraci s personálním systémem úřadu na jedné straně a s centrálním jednotným identitním prostorem úředníků VS ČR na druhé straně (aktuálně řešení JIP/KAAS).

• Povinnost napojení autentizace a autorizace klientů na JIP/NIA a úředníků na JIP/KAAS
• Doporučení realizovat centrální správu identit úřadu (IDM), napojenou u úředníků na HR (HCM)

Zde bude doplněno.

Pravidla pro integrační platformy

Častým problémem je, že u správců ISVS jsou tyto informační systémy budované jako autonomní bloky, které nejsou řádně a správně propojeny a integrovány s dalšími informačními systémy a komponentami v úřadu. Je nutno na to myslet již při sestavování prvotní architektury a důsledně zajistit tyto integrace, a to formou otevřených, a především popsaných a nahraditelných rozhraní, nikoliv jako blackboxy na dohodě dodavatelů.

Každý informační systém veřejné správy musí být integrován s:

• Elektronickým systémem spisové služby - pro odbornou správu dokumentů a pro úkony spojené s dokumenty, kdy ESSL je tím nástrojem pro výkon spisové služby a evidenci všech dokumentů
• Provozními systémy typu IDM a monitoringu
• Auditovacími a logovacími systémy - pro zajištění logování nakládání s údaji evidovanými v ISVS včetně ale nikoliv pouze osobních údajů
• Ekonomickým informačním systémem pro zajištění finančních operací a jejich evidence - u systémů pro agendy, kde se buď vyplácí, nebo přijímají finanční prostředky.

Preferovaným způsobem integrace aplikací je využití standardní integrační platformy (též Enterprise Application Integration, dále též jen „EAI“, nebo synonymum Enterprise Service Bus, dále též jen ESB), která nahradí P2P integraci úřadu a poskytuje funkce pro zejména asynchronní integraci (nečekající na potvrzení zápisu do databáze či odpověď), obsloužení front, logování apod.

Každý úřad bude využívat vlastní nebo sdílenou EAI propojenou na centrální eGSB.

Tato pravidla v souladu s NAP předpokládají vícestupňovou hierarchickou strukturu integračních platforem.

Pro zapojení úřadů do sdílení v rámci propojeného datového fondu je vybudována centrální integrační platforma eGSB (eGovernment Service Bus). Na ni se úřady přednostně napojují prostřednictvím korporátních integračních platforem resortů (krajů, ORP) nebo prostřednictvím vlastních EAI, pokud takovou mají.

Korporátní EAI slouží primárně pro potřeby interní integrace v rámci kapitoly nebo veřejné korporace, jako externí integrace pro úřad ministerstva nebo územního celku a jako sdílená služba pro podřízené organizace korporace, pro které není výhodné vybudovat EAI vlastní.

Místní integrační platformy budují ty úřady, pro které je investice do platformy jejich vnitřní i vnější aplikační integrace vzhledem k četnosti a komplexnosti rozhraní nebo vzhledem k objemu přenášených zpráv ekonomicky a provozně výhodná.

Pravidla pro systémy zveřejňující a využívající otevřená data

Jako otevřená data jsou v kompletní podobě zveřejňovány údaje evidované v ISVS, které:

• u nichž je povinnost zveřejnění v této formě výslovně stanovena právním předpisem; nebo
• jde o ISVS, jehož obsah je zcela či zčásti veřejný a zároveň se nejedná o předchozí případ. V tomto případě je nutné provést posouzení, zda zveřejnění údajů v této formě nebude mít za následek nepřiměřený zásah do práva na ochranu osobních údajů, popř. se jím významně nezvýší možnost narušení bezpečnosti ČR.; nebo
• jde o údaje, které by bylo možné poskytnout na základě žádosti podle předpisů upravujících svobodný přístup k informacím (srov. § 5 odst. 7 zákona o svobodném přístupu k informacím) a zároveň se nejedná o předchozí dva případy. . V takovém případě zveřejní údaje ve formě otevřených dat jen v rozsahu, v jakém by bylo možné je poskytnout, pokud by byly předmětem žádosti podle zákonů upravujících svobodný přístup informacím, přičemž je nutné provést též posouzení, zda by zveřejnění v této formě znamenalo možnost narušení bezpečnosti ČR.

Zveřejňovat údaje z ISVS jako otevřená data znamená povinnost poskytovat je všem odborníkům na zpracování dat (programátorům, datovým analytikům a novinářům, vědcům, studentům, apod.) a orgánům veřejné správy v podobě, která aktivně podporuje jejich strojové zpracování a replikaci, a zejména tomuto účelu neklade žádné (technické, právní ani ekonomické) překážky.

V případě, že jsou z ISVS zveřejňovány údaje v podobě otevřených dat, je též naplněn případný legislativní požadavek poskytnutí veřejného dálkového přístupu k těmto údajům.

Sdílení veřejných údajů evidovaných v ISVS mezi orgány veřejné správy musí být zajištěno prostřednictvím otevřených dat ve SVDF. Orgán veřejné správy, jehož evidence údajů v jím spravovaném ISVS je primární evidencí, je musí zveřejňovat jako otevřená data. Orgán veřejné správy, který tyto údaje využívá v jím spravovaném ISVS, je musí získávat jako otevřená data, pokud jsou jako otevřená data zveřejňovány.

Tytéž údaje je možné ve veřejné správě zveřejňovat jako otevřená data pouze jednou. V případě, že údaje vedené v ISVS jsou předávány do jiného ISVS za účelem shromažďování údajů od různých orgánů veřejné správy a následného zveřejnění, nejsou tyto předávané údaje zveřejnovány jako otevřená data z prvního ISVS, ale pouze z druhého ISVS. Zveřejňování zajistí správce druhého ISVS. V případě centrálních aplikačních služeb jsou vedené údaje poskytovány v podobě otevřených dat správcem centrální aplikační služby a samosprávní úřad v takovém případě již své příslušné údaje jako otevřená data nezveřejňuje.

Pravidla pro využití SaaS služeb eGC

SaaS služby eGC mohou být teoreticky využity pro nahrazení kterékoliv služby na aplikační vrstvě architektury úřadu, resp. interní implementace dané služby („funkce“ z pohledu architektonického modelu) může být nahrazena služnou SaaS. Na SaaS služby eGC budou kladeny stejné architektonické požadavky jako ISVS provozované on-premise a bezpečnostní požadavky odpovídající úrovni hodnocení bezpečnostních dopadů daného ISVS.

Praktické využití SaaS služeb eGC je očekáváno zejména a nejdříve v kategoriích podpůrných systémů, spisové služby a agendového zázemí, v případě obcí i v kategorii agendových aplikací pro samosprávnou působnost.

Další oblasti pravidel aplikační architektury …

• Správa zdrojů
• Podpůrné systémy

• správa nemovitostí
• Platforma GIS
• Mobilní platformy
• …

Pravidla pro identifikaci ISVS

Identifikace ISVS a jejich součástí (komponent, funkcí, služeb, rozhraní) by měla být jednotná, její princip by měl být stanoven OHA. Aktuálně taková pravidla nejsou připravena, bude nutné je navrhnout a projednat.

Pravidla datové architektury IS VS

Tato pravidla aktuálně nepředepisují žádné povinně standardizované individuální prvky datové architektury veřejné správy s výjimkou těch, které jsou postupně publikovány jako součást referenčních a autoritativních údajů veřejné správy ČR.

Zásadním požadavkem informační koncepce je adopce (uplatnění) společného přístupu k datové architektuře pro všechny orgány veřejné správy. Správce každého informačního systému musí vědět:

• Jaké údaje (data) se vyskytují v informačních systémech veřejné správy, které jsou využívány pro podporu agendy
• Odkud tato data pochází. Tedy zda jde o údaje vytvářené v rámci činnosti agendy, získané ze základních registrů, autoritativních zdrojů, využívané z jiných agend, z otevřeného datové fondu a podobně
• Komu údaje poskytuje (ať už na základě oprávnění o využívání údajů jiné agendy nebo na žádost)
• Jak zabezpečuje ochranu údajů ať už při přístupu k údajům, tak vedené záznamů (logů) o těchto přístupech a ochrana těchto logů.

Požadavky na změnu přístupu k datové architektuře jsou tedy platné pro všechny ISVS na území státu.

Každý správce ISVS, který obsahuje nějaký datový fond, je povinen zajistit (správce ISVS musí):

1. Referenčnost - ztotožnit všechny subjekty/objekty vedené v základních registrech (fyzické osoby – ROB, právnické osoby – ROS, adresní body a další územní prvky - RUIAN) a začít přijímat notifikace o změnách údajů o těchto subjektech/objektech jak ze základních registrů, tak od dalších autoritativních zdrojů.

2. Jednoznačnost - rozdělit si datový fond na části

   1. Referenční údaje – musí být v souladu se základními registry

   2. Autoritativní údaje – pochází od editorů základních registrů (např. Evidence Obyvatel) nebo jiných agendových informačních systémů (např. registr řidičů) v rámci agendy jsou pouze využívány

   3. Vlastní údaje agendy – údaje vytvářené v rámci agendy (mohou být dále poskytovány jiným agendám jako autoritativní)

3. Bezpečnost a důvěrnost – musí být zajištěna jak z hlediska ochrany osobních údajů, tak i z hlediska zabezpečení proti ztrátě či neoprávněnému pozměnění údajů

Tento způsob řízení datové architektury musí úřad uplatňovat nejenom pro jednotlivé ISVS, ale souhrnně za celý OVS, jeho úřad a korporaci.

Vedoucí informatiky úřadu a techničtí správci ISVS jsou povinni ve spolupráci s jejich věcnými správci vytvořit a udržovat aktuální model základní (konceptuální) dekompozice údajů úřadu a její diagram, tzv. Mapu datové architektury úřadu.

Detailní referenční modely datové architektury, rozpracovávající zde uvedená pravidla, včetně jejich grafického vyjádření tj. Map, stanovuje a publikuje OHA MV, ve spolupráci s OeG a organizacemi zastupujícími jednotlivé úrovně státní správy a samosprávy.

Rozdělení / klasifikace dat ve veřejné správě

IKČR ukládá úřadům udržovat aktuální klasifikace základních informačních (datových) objektů architektury úřadu. Tyto identifikované objekty musí být klasifikovány do následujících kategorií a je nutné s nimi v aplikační architektuře nakládat způsobem, odpovídajícím jejich klasifikaci.

Všechny údaje spravované v IS úřadu, tvoří tzv. datový fond úřadu. Základní existenciální (statické, kartotéční) údaje o subjektech (klientech, dodavatelích, zaměstnancích, apod.) a o objektech veřejné správy (evidovaná vozidla, kulturní památky, hospodářská zvířata, vl. majetek úřadu, apod.) představují tzv. datový kmen úřadu, nebo jeho kmenová data. Naproti tomu údaje o řízeních (operacích, úkonech) se subjekty nebo nad objekty veřejné správy se nazývají transakční data úřadu. Kmenová a transakční data jsou dvě nejdůležitější součásti datového fondu úřadu, další kategorie dat jsou představeny níže.

Zásadním požadavkem informační koncepce z hlediska klasifikace dat ve veřejné správě je zavedení pojmu autoritativní údaj. V současné době je již zaveden zákoně o základních registrech (§ 2) pojem referenční údaj. Autoritativní údaj má obdobnou datovou kvalitu a je nutné zajistit i právní jistotu při jeho využívání. Jde například o údaje týkající se řidičů, vozidel, vzdělání fyzických osob, kvalifikace osob fyzických či právnických k provádění činnosti dle zákona (lékař, vzdělávací instituce, akreditační středisko apod.).

Použitím výše uvedených principů můžeme údaje vedené v datovém fondu informačního systému veřejné správy (agendě), a souhrnně v datovém fondu úřadu, rozdělit z několika hledisek. Prvotním hlediskem je klasifikace datových objektů z hlediska zodpovědnosti za jejich validitu, viz výše bod jednoznačnost.

Dále mohou být jednotlivé datové objekty datového fondu ISVS a úřadu klasifikovány dle jejich typu (z hlediska stability, dynamiky či způsobu zacházení):

• Kmenová data
• Transakční data individuálních řízení v agendách
• Dokumenty
• Analytická (agregovaná, anonymizovaná nebo jinak transformovaná) data
• Signálová data (datový proud v reálném čase)
• Metadata analytických dat, dokumentů a multimediálních objektů
• Provozní a bezpečnostní auditní data (logy)
• Parametrizační, customizační data, řídící číselníky (jazyky, měny, směrovací čísla, typy daní, kategorie sazeb, druhy paliv, kategorie vozidel, NACE, atd.)
• Data programového kódu (zdrojový kód v databázi)

Zásadní klasifikace datových objektů nejen v datovém kmeni, ale i v dalších výše uvedených datových objektech je podle obsažení osobních údajů:

• Obsahující osobní údaje
• Obsahující citlivé osobní údaje
• Neobsahující osobní údaje.

Zásadním nástrojem pro správu datových objektů o subjektech a objektech práva obsažených v datovém kmeni agendy je Registr práv a povinností. Při ohlášení agendy je nutné uvést výčet údajů vedených v agendě dle zákona 111/2009 Sb. o základních registrech §51 odst. 6) písm. h). Tyto podklady slouží pro oznamovatele jiných agendy, kteří dle písmene j) tohoto ustanovení registrují požadavek na využívání těchto údajů.

V rámci RPP jsou udržovány informace o takto poskytovaných a využívaných údajích z legislativního hlediska, tj. tak jak jsou uvedeny v odpovídajícím právním předpisu. Z hlediska technického využití je pak správce ISVS, který údaje poskytuje prostřednictvím eGSB publikovat odpovídající technický předpis jak XML šablonu v rámci WSDL předpisu využívání publikovaných služeb eGSB.

Z technického hlediska je tedy závazný předpis, jakým jsou data publikovány pro využívání na rozhraní Informačního systému základních registrů a eGSB. Tím je sjednoceno referenční rozhraní veřejné správy a zajištěna jednoznačná technologická prezentace právních pojmů z hlediska přenášených údajů.

Současně tato koncepce nepředpokládá možnost výměny údajů mezi informačními systémy veřejné správy mimo referenční rozhraní.

Informační koncepce přepokládá novelizaci vyhlášek o datových prvcích informačních systémů (496/2006 Sb.) a referenčním rozhraní (53/2007 Sb.) tak, aby reflektovaly výše uvedené zásady.

Pravidla pro číselníková data

Každý, kdo poskytuje údaje v propojeném datovém fondu, má povinnost zveřejňovat s tím spojené číselníky v podobě otevřených dat ve SVDF. Jedná se o číselníky, které vytváří v rámci své činnosti, nikoli o číselníky využívané při vedení údajů.

Pokud tedy například v rámci vyplňování údajů je používán Číselník zemí (CZEM), pak tento číselník správce nepublikuje, pouze uvádí, že využívá daný číselník publikovaný Českým statistickým úřadem.

Pro každý číselník tedy musí být být známo:

• Správce číselníku (OVS)
• Místo publikace číselníku a jeho technický formát
• Způsob aktualizace číselníku

Číselníky evidované dle výše uvedených principů jsou závazné při výměně údajů mezi agendami.

Pravidla pro referenční a autoritativní kmenová data

V rámci svého lokálního informačního systému mohou, respektive musí být úřadem pro výkon agendy využívány referenční a autoritativní údaje. Tyto údaje mohou být využívány on-line při jejich potřebě dotazem na referenční rozhraní (ISZR a eGSB), nebo může být v uložena jejich kopie pro sujekty a objekty vedené v rámci agendy.

Autoritativní údaj:

• Vzniká v dané agendě její činností (definováno příslušným zákonem) a správce agendy je zodpovědný za jeho správnost – autoritativní zdroj – současný stav
• Je využíván v jiných agendách – současný stav (agenda má při své činnosti oprávnění využívat údaje jin agendy)
• Jeho použití z autoritativního zdroje zajišťuje, že je konáno „úředně správně“ obdobně jako u referenčního údaje – nutné legislativně doplnit

Povinnosti z hlediska autoritativních údajů – záměr:

• Správce (agendy) registruje u Registru práv a povinností údaj jako autoritativní
• Správce publikuje údaj v rámci vybraného kontextu s vazbou na subjekt/objekt prostřednictvím eGSB
• Správce publikuje změny autoritativního údaje
• Správce přijímá reklamace na stav autoritativního údaje
• Agenda využívající autoritativní údaj registruje tento požadavek v Registru práv a povinností
• Agenda využívá údaj prostřednictvím eGSB
• Pokud agenda ukládá ve svém datovém fondu tento údaj, pak ho udržuje v souladu se skutečností odběrem změn
• Pokud je při činnosti agendy zjištěna pochybnost o správnosti údaje, pak oznámí správci údaje

Z hlediska efektivity výkonu veřejné správy je zásadní, jak efektivně jsou referenční a autoritativní údaje z referenčního rozhraní využívány. Současně je nutné architektonicky zabezpečit, aby výkon veřejné správy byl maximálně odolný vůči výpadkům centrálních komponent.

a) Pokud nejsou tyto údaje ve větším množství v rámci agendy využívány, pak je nejefektivnější a nejbezpečnější jejich využívání na základě on-line dotazů v okamžiku potřeby. V datech agendy pak nejsou údaje trvale uloženy, ale je uložen pouze jejich tvar získaný v okamžiku dotazu a v souvislosti s daným účelem.

b) Pokud jsou tyto údaje využívány agendou ve větším množství, nebo v případě nedostupnosti centrálních systémů hrozí nebezpečí z prodlení, pak je efektivní údržba lokální kopie referenčních a autoritativních údajů o subjektech a objektech agendy pro potřeby jejího výkonu. V tomto případě je nezbytně nutná systematická údržba těchto údajů tak, aby byly v souladu s údaji vedenými v základních registrech a autoritativních zdrojů. Za tímto účelem je nutné využívat procesu notifikace změn a aktualizace údajů o subjektech a objektech, pro které byla tato změna notifikována.

Princip notifikace je zásadně typu pull a bez předávání údajů při notifikaci. Tedy agenda využívající údaje požádá o seznam subjektů či objektů, pro které za uplynulé období (typicky jeden den) došlo ke změně údaje. Daný seznam pak využije k aktivnímu dotazu na zdroj údajů, kde získává údaje dle svých oprávnění. Je tak tedy zajištěno, že během notifikací nemohou být předány údaje, na které agenda nemá oprávnění. Současně při dotazech na fyzickou či právnickou osobu je vytvořen záznam v základních registrech a dotčený subjekt údajů získá informaci o tom, že agenda aktualizovala údaje o něm ve svém datovém kmeni.

V případě, že OVS využívá více než jeden vlastní (lokální) agendový informační systém a využívá referenčních a autoritativních kmenových údajů, musí být implementováno lokální řešení správy kmenových dat, které po iniciálním ztotožnění udržuje přijímáním notifikací z PPDF kmenová data úřadu aktuální a nezatěžuje PPDF (a ISZR s eGSB) průběžnými on-line dotazy. Osobní údaje získané tímto způsobem jsou uloženy mimo jednotlivé informační systémy a jednotlivými systémy jsou využívány pouze v případě potřeby. Tím je zajištěno oddělení a zabezpečení osobních údajů s nezpochybnitelným auditem přístupu k osobním údajům.

Pravidla pro otevřená data

Otevřená data musí především naplnit legislativní požadavky. Navíc musí jejich způsob zveřejnění naplnit následující podmínky, jejichž splnění musí zajistit orgán veřejné správy, který otevřená data zveřejňuje:

• Otevřená data musí být katalogizována v NKOD v podobě jednotlivých datových sad.
• Datová sada musí být tvořena logicky souvisejícími údaji logicky organizovanými do záznamů se stejnou datovou strukturou.
• Z datové sady nesmí být záměrně odstraňovány vybrané údaje nebo celé záznamy, které zveřejněny být mohou.
• Datová sada musí být poskytována v podobě jednoho či více datových souborů ke stažení ze sítě WWW, které nazýváme distribuce datové sady.
  • Distribuce datové sady se smí vzájemně lišit pouze v datovém formátu, nikoliv ve svém obsahu. Každá distribuce musí obsahovat kompletní množinu záznamů tvořících datovou sadu.
  • Alespoň jedna z distribucí musí být poskytována v otevřeném a strojově čitelném formátu ve smyslu definice otevřených dat podle § 3 odst. 11 InfZ a musí být opatřena podmínkami užití, které neomezují žádné (legální) užití jejího obsahu, především nesmí zamezovat ani komerčnímu užití. Zároveň musí být poskytována bez zbytečných překážek. Není možné podmiňovat přístup k distribuci registrací, uzavřením smlouvy, získáním aplikačního klíče, přihlašováním apod. Přístup k distribuci může být subjektu omezen pouze v případě a po dobu, kdy jeho chování při získávání distribuované datové sady vykazuje známky kybernetického útoku.
  • Každá distribuce v otevřeném a strojově čitelném formátu musí být opatřena logickým datovým schématem vyjádřeným ve vhodném a běžně používaném jazyku pro popis datových schémat, pokud takový jazyk pro daný formát existuje. Logické datové schéma popisuje reprezentaci datové struktury záznamů tvořících datovou sadu v příslušném formátu. Distribuce musí být vůči svému logickému datovému schématu validní.
• Datová sada musí být detailně zdokumentována především za účelem maximálního možného zamezení dezinterpretace jejího obsahu. V případě, že z datové sady byly před jejím zveřejněním odstraněny některé údaje nebo celé záznamy z důvodu nemožnosti jejich zveřejnění, musí být tato skutečnost uvedena v dokumentaci a zdůvodněna. V případě, kdy je datová sada anonymizovanou podobou, souhrnem nebo statistikou zdrojových údajů, musí být způsob anonymizace nebo vytvoření souhrnu či statistiky zdokumentován.
• Obsah distribucí datové sady musí být aktualizován dle periodicity, kterou OVM deklarovalo při katalogizaci datové sady v NKOD.
• Jsou povoleny pouze zpětně kompatibilní změny v datové struktuře záznamů tvořících datovou sadu. Změny v datové struktuře musí být implementovány do logických datových schémat distribucí.
• V případě změn, které nejsou zpětně kompatibilní, musí být založena nová datová sada a distribuce původní již nesmí být aktualizována.
• U datových sad, jejichž distribuce již nejsou aktualizované, musí být zajištěna dostupnost jejich distribucí po nejdelší možnou dobu, minimálně však po dobu 3 let.

Datová sada zveřejněná jako otevřená data ve SVDF musí navíc k výše uvedeným podmínkám splňovat následující podmínky, které zajistí použitelnost a důvěru v data ve SVDF:

• Orgán veřejné správy, který datovou sadu zveřejňuje, musí zajistit a garantovat dostupnost všech distribucí datové sady v otevřeném a strojově čitelném formátu pro všechny orgány veřejné správy, které je využívají při výkonu svých agend. To může učinit využitím sdíleného úložiště SVDF.
  • Datová sada je dostupná, pokud je trvale dostupná s maximálně N výpadky během jednoho T1, přičemž 1 výpadek trvá maximálně T2.
• Správce ISVS, ze kterého je datová sada získána, zodpovídá za věcnou správnost obsahu datové sady. To znamená, že zodpovídá za správnost jednotlivých záznamů tvořících datovou sadu a jednotlivých údajů, které ji tvoří.
• Prvky definované logickými datovými schématy distribucí datové sady, jejichž sémantika je významná, musí být propojeny na pojmy sémantického slovníku pojmů za účelem harmonizace sémantiky datových sad.

Podmínky pro SVDF mohou být splněny i otevřenými daty, které nejsou součástí VDF.

Pravidla pro analytická data

Každý úřad, který ze zákona udržuje primární individuální evidenční data o subjektech či objektech práva ve svých agendových systémech, je automaticky povinen pro potřebu řízení agend i pro jinou veřejnou potřebu vytvářet z těchto údajů anonymizované statistické údaje.

Anonymizované statistické údaje jsou tříditelné podle všech parametrů (klíčů), které nejsou údaji specificky chráněnými a nezakládají možnost profilace.

Statistická data mohou být vytvářena s přiměřenou periodou podle povahy evidovaných údajů v primární evidenci (den, týden, měsíc, čtvrtletí, rok). Jako statistická data budou zveřejňována po provedení nezbytných úprav (např. agregace) data, která jinak nemohou být zveřejněna z důvodu ochrany osobních údajů. Statistická data jsou vytvářena tak, aby v nejvyšší možné míře zachovávala informační hodnotu původních dat.

Takto připravované statistické údaje musí být zveřejňovány jako otevřená data a mohou být zveřejňovány na portálu úřadu také jako zrakově čitelné údaje.

Úřady, jejichž specifické agendové zákony nepředpokládají vytváření statistických údajů a jejich využívání k řízení a optimalizaci výkonu agendy a k zveřejnění jako otevřená data, musí usilovat o odpovídající legislativní úpravu.

Statistická data téhož (nebo velmi blízkého obsahu) je možné ve veřejné správě vytvářet pouze jedenkrát, proto je tím pověřen správce agendového informačního systému primární evidence příslušného subjektu nebo objektu práva a příslušného údaje.

Statistické údaje, které mohou orgány nyní ze zákona pověřené sběrem takových statistických údajů získat z jejich primárních evidencí, nesmějí být duplicitně získávány sběrem od subjektů.

Pravidla pro geo-data

Doplníme ve spolupráci s ČÚZK

Další oblasti pravidel datové architektury

Věcně příslušné úřady mohou a budou ve spolupráci s OHA průběžně stanovovat další pravidla pro správu datové architektury a samostatně zveřejňovat v informačních kanálech OHA.

Pravidla technologické architektury IS VS

Klasifikace IT technologické architektury

Klasifikaci prvků IT technologické architektury, tj. výpočetního výkonu, úložného prostoru, koncových zařízení a dalších platformových HW a SW služeb, vydá jako další akcelelrátorů OHA poté, co bude možnost zobecnit a sdílet zkušenost z dostatečného množství individuálních architektur úřadů v této oblasti.

Pravidla návrhu a využití On-Premise architektury

Veškeré IT technologie, s výjimkou koncových vstupně výstupních zařízení interních uživatelů musí být umístěna a provozována v pro tento účel vyhrazených prostorách, dále také zvaných serverovny nebo datová centra, vyhovujících stanoveným standardům.

Standardy pro serverovny a datová centra bude vydávat MV ve spolupráci s bezpečnostními organizacemi veřejné správy a odbornými IT organizacemi.

Podle IKČR je nepřípustný výskyt tzv. šedého IT, tj. aplikací a platformového SW a HW, pořízených, nebo umístěných nebo užívaných v odborných útvarech OVS bez dodržení centrálního dohledu (governance) útvaru IT úřadu.

Pokud je pro některé malé úřady nehospodárné nebo technicky či personálně nemožné dodržet tato pravidla, je jedinou možností svěřit svá IT řešení do péče jiných organizací veřejné správy, u nichž pravidla budou dodržena, a využívat IT podporu svých procesů veřejné správy jako jejich službu.

Pravidla využití PaaS a IaaS služeb eGC

PaaS a IaaS služby eGC mohou být využity pro nahrazení kterékoliv služby na technologické vrstvě architektury úřadu, resp. interní implementace dané služby („funkce“ z pohledu architektonického modelu) může být nahrazena služnou PaaS nebo IaaS. Na PaaS a IaaS služby eGC budou kladeny stejné architektonické požadavky jako na platformy provozované on-premise. Pro služby eGC a on-premise budou stejné i bezpečnostní požadavky odpovídající úrovni hodnocení bezpečnostních dopadů ISVS tyto platformy využívající.

Praktické využití PaaS a IaaS služeb je očekáváno zejména ve formě skupin služeb odpovídajících provozní platformě určitého ISVS nebo provozního informačního systému, případně jeho jasně definované části (např. web front-end), a to buď na úrovni plně spravované technologické platformy včetně správy OS (PaaS), nebo na úrovni virtualizovaných výpočetních a diskových zdrojů (IaaS), jejichž správu bude úřad provádět vlastními silami nebo s využitím služeb třetí strany. Z pohledu eGC je pro dosažení vyšší úrovně efektivity preferováno použití služeb PaaS.

Dalším příkladem využití PaaS služeb je využití plně spravovaných platforem databázových nebo aplikačních serverů včetně zajištění SW licencí.

Pravidla fyzické a komunikační infrastruktury IS VS

Klasifikace fyzické a komunikační infrastruktury

Klasifikaci prvků fyzické (stavební, technologické) a komunikační infrastruktury vydá jako další akcelelrátorů OHA poté, co bude možnost zobecnit a sdílet zkušenost z dostatečného množství individuálních architektur úřadů v této oblasti.

Pravidla využití sdílených prvků infrastruktury

KIVS, CMS, krajské konektory

Jste-li obcí, pak se připojujte se na CMS přes krajský konektor.

Jste-li krajem, poskytněte obcím krajskou síť, protože je to bezpečné, spolehlivé a cenově efektivní.

Využitím služeb eGC zároveň dochází k fyzickému přemístění provozovaných služeb do datových center poskytovatele eGC a je třeba řešit související otázky připojení úřadu k poskytovateli eGC … bude doplněno

• **
• **

Další pravidla a pomůcky tvorby architektury zdola

Referenční architektury úřadů a řešení

Koncepce referenčních modelů architektury úřadů VS

     Jak je již uvedeno výše, bude OHA ve spolupráci a koordinaci s dalšími organizacemi vydávat příklady nejlepší architektonické praxe, klasifikační hierarchie a akcelerátory práce v architektonických angažmá v podobě tzv. referenčních modelů (dále i jenom RM).

Referenční modely představují buď povinnou, nebo fakultativní (podle doprovodné informace u každého z nich) referenci formy, tj. způsobu modelování a interpretace architektur úřadů.

Referenční modely budou vydávány převážně pro architektury celých úřadů nebo jejich podstatných částí, segmentů.

Pro vyšší využitelnost budou vedle generických, celostátně platných RM, vydávány i RM specifické pro určité odvětví (segment) veřejné správy, například zdravotnictví, infrastruktura apod., nebo pro úřady z jednotlivých vrstev hierarche státní správy a samosprávy, se zahrnutím všech typů působnosti na dané úrovni (přímé, přenesené, samosprávné, soukromoprávní).

Lze očekávat vydání referenčních modelů na těchto úrovních:

• Referenční architektury ústředních správních úřadů - kromě ÚSÚ, se tím myslí i ostatní úřady s celostátní působností.
• Referenční architektury územních samospráv

• Zjednodušený příklad architektury kraje a krajské korporace, vytvořený ve spolupráci s Asociací krajů ČR
• Zjednodušený příklad architektury ORP a jeho korporace
• Zjednodušený příklad architektury malé obce - oba vytvořené ve spolupráci se SMO a KISMO

• Referenční architektury dalších typů orgánů veřejné moci - budou-li takové identifikovány.

Architektonické vzory klíčových oblastí úřadu

OHA bude postupně vydávat referenční typové schopnostní enterprise architektury těch oblastí architektury úřadů (zejména procesní a aplikační), které sice zůstávají většinou v lokální zodpovědnosti, ale jejichž logická podoba musí být pro splnění cílů koncepce centrálně předepsána a následně v řešeních dodržena.

IKČR uvažuje zejména o těchto kategoriích referenčních modelů typové procesní a aplikační architektury:

• Multikanálová uživatelská rozhraní
  • pro klienty VS
  • pro zaměstnance VS
• Klíčové části agendových IS
  • Sdílený agendový Front-office (CRM)
  • Specifický agendový Middle-Office (odborné části agendových IS), některé nadresortní (dotace, kontroly, údržba síťové infrastruktury státu, …)
  • Sdílený agendový Back-Office (platební, znalostní a další systémy)
• Správa spisů, dokumentů a jejich toku (workflow)
• Provozní ERP systémy
• Rozšiřující systémy správy zdrojů úřadu
• Identity management
• Integrační platformy
• Správa kmenových dat a číselníků (s vazbou na ZR i bez)
• Business Intelligence (a její využití jak pro manažerské rozhodování, tak pro podporu transakčních agendových i provozních systémů)

Referenční model typové elektronické spisové služby úřadu

Bude doplněno.

Povinné vzory architektur typových řešení

OHA bude postupně vydávat vzorové referenční schopnostní enterprise architektury a architektury řešení těch oblastí architektury úřadů, jejichž podoba musí být pro splnění cílů koncepce centrálně předepsána a následně v řešeních dodržena. Proto se nazývají povinnými architektonickými vzory.

Typicky se bude jednat o oblasti architektury využívající sdílené služby eGovernmentu nebo o další oblasti, v nichž bude pro naplnění zákonných povinností nebo dosažení efektivity žádoucí jednotné, standardizované řešení.

Architektonický vzor typového agendového IS

Základní aplikační architektura ISVS v kontextu eGovernmentu

tady bude dovysvětleno

Detailní architektury specifických rozhraní agendového ISVS

tady bude další schéma a vysvětlení

Architektonické vzory využití sdílených služeb eGovernmentu

OHA bude vydávat také detailní architektonické vzory rozhraní pro využití sdílených služeb eGovernmentu, na úrovni jednotlivých weboch služeb a další prvků řešení a designu těchto rozhraní a způsobu jejich využití v lokálních architekturách úřadů.

IKČR zde ukládá povinnost respektovat v návrzích řešení tyto vzory tak, jak budou OHA publikovány, postupně a samostatně.

Architektonický vzor typové elektronické spisové služby úřadu

Bude doplněno.

Specifická pravidla pro architekturu úřadů

Pravidla pro architekturu dle velikosti a možností úřadů

Pro obce 1. a 2. typu má vize architektury veřejné správy následující podobu:

Architekturu IT úřadu obce 1. a 2. typu (do určité velikosti, viz níže) tvoří pouze koncová zařízení pro uživatele (dále jen zařízení), síťovou infrastrukturu jim jako sdílenou poskytuje kraj, aplikační služby pro státní správu v přenesené působnosti poskytnou ohlašovatelé agend a aplikační služby pro samosprávní působnost poskytne vyšší stupeň územní samosprávy (ORP, kraj) jako sdílenou službu.

Pro oblast samosprávy tak vychází koncepce z následujících principů:

4. Koncepce je závazná pro všechny subjekty samosprávy, které mají více než 10 zařízení.

5. Informační systémy pro činnosti a agendy v přenesené působnosti přebírají v plném rozsahu od centrálních úřadů. Samosprávné činnosti si každý územněsprávní celek zajišťuje sám.

6. Subjekty s méně než 10 zařízeními si pořizují pouze uživatelský HW a SW, tj. tato koncová zařízení, SW produkty pro výkon veřejné správy jim jako službu zajišťují subjekty, v jejichž správním obvodě leží.

Ad1) Územněsprávní celky, kraje, velká města a obce s rozšířenou působností, mají ve svých úřadech specializované útvary IT. Tyto útvary jsou schopné vlastními silami nebo za pomoci externích dodavatelů zajistit veškeré požadavky IKČR a metodicky řídit své zřizované organizace (technické služby, nemocnice, sociální ústavy, velké školy). Subjekty samosprávy, které mají do deseti zařízení, nedisponují žádným specialistou IT a jsou odkázány na pomoc větších subjektů.

Ad2) Státní správa, kterou samosprávní subjekty vykonávají v přenesené působnosti, je zpravidla podporována informačními systémy, které jsou centrální (živnostenský rejstřík, registr vozidel). Pořízení, vývoj a aktualizace těchto informačních systému je plně v gesci příslušného centrálního orgánu, který je za agendu odpovědný dle zákona. Naproti tomu pro každou samosprávnou činnost jsou informační systémy zajišťovány decentralizovaně (výběrem z nabídky IT firem, málokdy vlastním vývojem). Informační koncepce předpokládá, že také tyto informační systémy budou splňovat stanovené standardy a zásady informační koncepce.

Ad3) Velikost samosprávných subjektů je velmi rozdílná. Počínaje kraji, které disponují velkými úřady, přes obce s rozšířenou působností s úřady o desítkách zaměstnanců až po malé obce, kde je maximálně uvolněný starosta a jeden úředník. Stejná situaci je i u zřizovaných organizací (velké dopravní podniky, nemocnice, ústavy sociální péče) U těchto nejmenších obcí a zřizovaných organizací informační koncepce předpokládá, že budou pouze nakupovat hardware a jeho provozní SW s parametry, které požadují používané informační systémy. Informační systémy budou používat sdílené, jako službu. Informační systémy jim budou zajišťovat obce s rozšířenou působností, v jejichž správním obvodě malá obec nebo organizace leží. Obdobně síťovou infrastrukturu pro napojení na centrální prvky eGovernmentu a sdílené služby jim bude zajišťovat ORP nebo kraj, v jejichž správním obvodě malá obec nebo organizace leží.

Pravidla pro architekturu dle pozice úřadu ve struktuře VS ČR a vztahu ke sdíleným službám

Úřady, zodpovědné ze zákona jako věcní správci sdílených prvků služeb eGovernmentu, považují tyto jim svěřené prvky za nedílnou součást architektury svého úřadu. Vedle celkové architektury svých úřadů ještě samostatně modelují modely architektury těchto svěřených sdílených prvků, a to jak na úrovni EA (PSA), tak na úrovni podrobnosti tzv. architektury řešení, viz dále. Tyto úřady pro tyto prvky modelují také tzv. rozšířené modely, tj. modely zahrnující také prvky typové (logické) prvky architektury na straně typových (typických) odběratelů jejich sdílených služeb.

Úřady, užívající služeb sdílených prvků eGovernmentu, nemodelují tyto informační systémy v žádném případě jako aktivní prvky (aplikační a technologické komponenty a rozhraní) - nemají je v rozsahu své zodpověndosti, nýbrž výhradně jako služby (byznys, aplikační nebo technologické a infrastrukturní - podle potřeby vyjádření) a rozhraní vlastních komponent na tyto systémy.

Úřady zodpovědné, viz výše, za implementaci a provoz centrální registrů a AIS pro služby v přenesené působnosti, modelují architekturu svých úřadů přirozeně i včetně těchto systémů. Současně jsou povinny vytvářet a udržovat také tzv. rozšířené modely, tj. modely zahrnující také prvky typové (logické) prvky architektury na straně typových (typických) odběratelů jejich sdílených služeb, ukazující veškerý potřebný kontext (například integraci centrálního AIS na lokální eSSL a EkIS).

Úřady užívající tyto centrální AIS pro služby v přenesené působnosti, nemodelují ve svých architekturách úřadu tyto jako aktivní prvky (nemají je ve své zodpovědnosti), nýbrž jako služby těchto systémů a rozhraní vlastních komponent na tyto systémy.

Architektonické a IT standardy

Standardy návrhu a vývoje elektronických služeb veřejné správy

Standard elektronických služeb veřejné správy definuje kritéria, jejichž naplnění je předpokladem pro tvorbu a provoz kvalitních a úspěšných služeb veřejné správy. Naplnění standardu je vyžadováno od všech transakčních elektronických služeb poskytovaných veřejnou správou pro externí klienty.

Soulad nových a upravovaných služeb se standardem je předmětem posuzování záměrů OHA (§4 odst. 1 písm. e) zák. 365/2000 Sb. a usnesení vlády č. 998 ze dne 2. listopadu 2015).

OHA bude standardy nárvhu a vývoje elektronických služeb VS vydávat průběžně a publikovat je na portálu a v dalších komunikačních kanálech OHA.

Výchozí sada standardů je uvedena v Dodatku G této IKČR.

Technické standardy informačních systémů

V návaznosti na referenční modely, povinné vzory, standardy návrhu služeb a další součásti NAP může MV ČR vydávat a publikovat tzv. IT standardy součástí IT řešení, tj. formátů, jazyků, protokolů, platforem, zabezpečení, atp., v návaznosti na mezinárodní normy a standardy a domáci zkušenosti.

Modely NAP v centrálním úložišti a v OVS

Tady musí být vysvětleny zásady řízení NAP prostřednictvím modelů „shora“ a „zdola“, ukládaných v centrálním sekundárním úložišti a distribuovaných jeho prostřednictví.

Nyní je to kapitolou NAR, ale spíše to patří sem.