Metodický pokyn. k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ B3

Rozměr: px
Začít zobrazení ze stránky:

Download "Metodický pokyn. k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ B3"

Transkript

1 Metodický pokyn k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ B3 Odbor Hlavního architekta egovernmentu MV Praha, září 2018 verze 6.0 Toto dílo podléhá licenci Creative Commons Uveďte původ 4.0 Mezinárodní Licence. 1

2 Obsah Úvodní informace a pokyny... 3 Způsob podání žádosti...3 Proces posuzování projektů je následující....3 Způsob vyplnění Formuláře žádosti Základní podmínky projektu Úvodní informace o žadateli o stanovisko k projektu Shrnutí charakteristik projektu Popis, potřebnost a výstupy projektu Architektonické informace k funkčnímu celku Dodržení architektonických principů NA VS ČR Enterprise architektura projektu a její kontext Strategie a směrování - Motivační architektura Efektivita projektu Výkonnostní architektura Poskytování veřejných služeb - Byznys architektura Architektura informační systémů (aplikací a dat) Technologická architektura vrstva IT technologie (HW a SW) Technologická architektura vrstva komunikační infrastruktury Bezpečnostní architektura Shoda s pravidly, standardizace a dlouhodobá udržitelnost Přehled služeb čtyřvrstvé architektury Kontrola shody architektury řešení projektu se vzory sdílených služeb egovernmentu Plán projektu Další údaje o projektu Připravenost projektu k realizaci Majetkoprávní vztahy projektu (povinné jen pro projekty zakázkového vývoje SW) Ekonomické parametry funkčního celku Hodnota výdajů a ekonomická náročnost projektu Plán údržby, dlouhodobá udržitelnost výstupů projektu Vyjádření k bezpečnostním aspektům Upozornění a doporučení Přílohy

3 Ú V O D N Í I N F O R M A C E A P O K Y N Y Vzor žádosti, který dostáváte do rukou, vznikl na základě úkolu uloženého bodem 4. článku II. usnesení vlády České republiky ze dne 2. listopadu 2015, č. 889, k dalšímu rozvoji informačních a komunikačních technologií služeb veřejné správy, zajistit dodržování Základních zásad postupu při čerpání finančních prostředků na výdaje související s informačními a komunikačními technologiemi s hodnotou více než 6 mil. Kč ročně, jakož i na základě zmocnění obsaženého v 4, odst. 1 písm. e) a odst. 2 písm. b) a g) zákona 365/2000 Sb., o informačních systémech veřejné správy, v platném znění, dle nichž se Ministerstvo vnitra ČR vyjadřuje k návrhům dokumentací programů obsahujících pořízení nebo technické zhodnocení informačních systémů veřejné správy, k investičním záměrům akcí pořízení nebo technického zhodnocení informačních systémů veřejné správy a k projektům informačních systémů veřejné správy určených k výkonu státní správy, vždy pokud jejich předpokládaná hodnota přesahuje částku 6 mil. Kč bez DPH, resp. 30 mil. Kč bez DPH vynaložených za 5 let. Pro usnadnění zpracování žádosti o stanovisko vytvořil OHA dva samostatné dokumenty: a) Formulář žádosti o stanovisko Hlavního architekta egovernmentu, b) Metodický pokyn k vyplnění formuláře žádosti o stanovisko Hlavního architekta egovernmentu (tento dokument). Způsob podání žádosti Žádost podávejte Ministerstvu vnitra ČR, konkrétně odboru Hlavního architekta egovernmentu (dále jen OHA ) do datové schránky ID: 6bnaawp, a to ve formě volného dopisu obsahujícího text žádám o posouzení projektu dle usnesení vlády č. 889 ze dne 2. listopadu 2015 (případně dle zákona 365/2000 Sb., či obojího) na hlavičkovém papíře (v šabloně) organizace žadatele podepsaný osobou oprávněnou k podání žádosti jménem organizace. Přílohou takovéto Žádosti je vyplněný formulář žádosti o stanovisko OHA včetně všech případných příloh tohoto formuláře. Posuzování a finanční limit (6 mil. Kč ročně) se vztahuje na záměr vydat prostředky, bez ohledu na to, kolika projekty či soutěžemi bude realizace záměru provedena. Pokud se jednoho řešení týká více záměrů, je možno žádosti o stanovisko k těmto záměrům spojit do jediné žádosti. Plný formulář žádosti bez zjednodušení slouží pro nákup nových informačních systémů či jejich údržbu/rozvoj, respektive pro vybudování IT podpory nové nebo významně pozměněné agendy, její části nebo veřejné služby úřadu. Formulář žádosti je univerzálně použitelný a robustní tak, aby pokryl celé spektrum možných záměrů, na které se vztahuje schvalovací povinnost. Proces posuzování projektů je následující. Podatelna Ministerstva vnitra žádost zaeviduje a ve spisové službě přidělí OHA. Ten zkontroluje kompletnost žádosti, v případě nedostatků si vyžádá doplnění, a rozhodne o délce lhůty vyřízení: Základní projekty lhůta do 30 kalendářních dnů od zaevidování nebo Složité projekty lhůta do 60 kalendářních dnů od zaevidování. Lhůta na vyřízení začíná běžet převzetím kompletní žádosti. V průběhu posuzování je OHA oprávněn vyžádat doplnění nebo vysvětlení ze strany Žadatele. Po dobu od odeslání žádosti o doplnění až do doručení doplnění, na jehož základě je možné rozhodnout, je běh lhůty pozastaven. Stanovisko, které OHA vydá, zašle původnímu Žadateli zpět prostřednictvím Informačního systému Datových schránek. Pro urychlení procesu vyřízení, poskytuje OHA Žadateli možnost konzultovat projekt ještě před podáním žádosti. Způsob vyplnění Formuláře žádosti. Formulář žádosti obsahuje dva typy položek k vyplnění: tabulku, do které Žadatel požadované informace do příslušných buněk buď vepisuje, nebo je vybírá z předpřipravené nabídky variant (ve formuláři červeně ), prostor pro vložení diagramu, označený <zde vložte diagram (-y)>. 3

4 Formulář B3 slouží pro předání informací o architektuře celého funkčního celku na základě závazku z žádosti či žádostí typu B1. Funkční celek znamená řešení v celé jeho komplexitě, jak je v prostředí organizace/státu nasazeno. Příkladem budiž informační systém, ke kterému je realizován projekt na vytvoření nového modulu systému. Pak je projektem pouze nový modul, ke kterému je vyplněna žádost. Funkčním celkem je ovšem celý informační systém zahrnující všechny jeho moduly a rozhraní. Pro definici funkčního celku není relevantní, kolik je k němu uzavřeno smluv na podporu nebo kolik dodavatelů vytvářelo jeho jednotlivé části. Rozhodující je technologická provázanost (např. SOA) anebo logická souvislost. Příklady funkčních celků je ADIS (daňový systém), IIS ČSSZ (integrovaný informační systém správy soc. zabezpečení), datové centrum (pro případ rozšiřování o nové technologie) apod. Jeden formulář typu B3 může být splněním závazku ze všech předchozích žádostí typu B1. Důvodem je, že záměr dle B1 se může týkat jen jedné části celého funkčního celku. V případě, že některá část Formuláře není pro váš projekt nebo kontext projektu relevantní, uveďte zde: není relevantní, aby bylo zřejmé, že jste položku nevyplnili záměrně. V případě, že architektura projektu, popsaná ve formuláři žádosti, není v souladu s architektonickými principy Národní architektury VS, požadavky na soulad řešení s kontextem architektury úřadu, požadavky na soulad řešení s kontextem architektury egovernmentu, architektonickými vzory řešení sdílených služeb egovernmentu apod., ale přesto existuje objektivní důvod realizovat projekt požadovaným způsobem, uveďte / vyberte z rozbalovacího seznamu v příslušné části formuláře, že žádáte o výjimku, a pro každou takovou výjimku vyplňte žádost o udělení výjimky, uveďte ji do poslední kapitoly s názvem Přílohy a přiložte ji k žádosti o stanovisko. Vzor žádosti o udělení výjimky je ke stažení na webu OHA 1 1 Z Á K L A D N Í P O D M Í N K Y P R O J E K T U 1.1 Úvodní informace o žadateli o stanovisko k projektu Zde uveďte základní identifikační údaje o organizaci, která vystupuje jako žadatel o stanovisko. Na rozdíl od studie proveditelnosti Integrovaného regionálního operačního programu (IROP) je žadatel organizace, která bude vynakládat finanční prostředky na realizaci projektu, nejedná se tedy o toho, kdo zpracovával formulář. V tabulce 1: Úvodní informace o žadateli projektu, vyplňte: Organizace žadatele plný oficiální název organizace, adresu sídla a identifikační číslo (IČ) organizace, která žádost podává. Ředitel pro informatiku nebo Statutární zástupce jméno a příjmení, název zastávané funkce v organizaci žadatele, mailovou adresu a telefonní kontakt osoby, která svým podpisem stvrzuje podání žádosti o stanovisko OHA, a která je k tomu oprávněná podpisovým řádem organizace. Kontaktní osoba projektu jméno a příjmení, název zastávané funkce v organizaci, mailovou adresu a telefonní kontakt osoby, na níž se OHA může obrátit s případnými žádostmi a nejasnosti souvisejícími s žádostí o stanovisko. V případě, že se nejedná o interního zaměstnance organizace, uveďte k funkci rovněž název organizace, jejímž je tato osoba pracovníkem. Architekt projektu jméno a příjmení, název zastávané funkce v organizaci, mailovou adresu a telefonní kontakt osoby, která při přípravě projektu působí v roli architekta. V případě, že se nejedná o interního zaměstnance organizace, uveďte k funkci rovněž název organizace, jejímž je tato osoba pracovníkem. Datum vypracování žádosti datum dokončení posledních úprav / konečné verze, formuláře žádosti o stanovisko. V případě podávání aktualizované žádosti toto pole nezapomeňte změnit. V tabulce 2: Druh žádosti, zvolte položku, která podle skutečnosti vystihuje, dle jakých předpisů je požadováno stanovisko OHA, tj. zda dle usnesení vlády ze dne 2. listopadu 2015, č. 889, nebo zákona 365/2000 Sb

5 1.2 Shrnutí charakteristik projektu V tabulce 3: Shrnutí charakteristik projektu, vyplňte a zvolte skutečnosti odpovídající variantu: Název projektu srozumitelný název projektu, k němuž je podávána žádost o stanovisko. Nepoužívejte zkratky, které nejsou všeobecně známé v prostředí ICT nebo ve veřejné správě. Seznam předchozích žádostí B1 a B2 k funkčních celku: seznam předchozích žádostí, které tato žádost obsahuje. Předpokládaný počet let využívání výstupů projektu (počet let od začátku využívání do konce využívání) hrubý odhad počtu let od zahájení ostrého provozu do předpokládaného vyřazení z provozu. Vyřazením z provozu je myšleno nahrazení jiným projektem nebo ukončení bez náhrady. V případě, že je předpokládáno využívání (provoz) více než 5 let, pak je možné uvést jen Více než 5 Možnost zveřejnění formuláře z nabízených variant vyberte položku, zda a za jakých podmínek je možné formulář zveřejnit, resp. poskytnout podle předpisů upravujících svobodný přístup k informacím. Pokud formulář není možné plně bez úprav zveřejnit, resp. poskytnout, vysvětlete do volného pole důvod a změny, které je potřeba udělat, aby to bylo možné. Určení věcného správce, technického správce a provozovatele Věcný správce Věcný správce (gestor) je organizační útvar/složka, která je věcně odpovědná za výkon předmětné agendy, tj. rozhoduje o obsahu a pravidlech fungování služby. V této roli je zodpovědný za definici procesu, který službu dodává, definici funkcionality podpůrné ICT služby a dat, za shodu funkcionality aplikace s legislativou a za definici objemových a kvalitativních parametrů podpůrné ICT služby (počet uživatelů, doba provozu služby, dostupnost služby, doba odezvy atd.). Věcným správcem služby veřejné správci může být pouze orgán veřejné moci, tj. státní orgány a samosprávné celky). Každá agendová služba má vždy jen jednoho správce. Je jím orgán zodpovědný za službu (agendu). Provozní služba mívá obvykle více správců. Když služba má jednoho správce, jedná se o centralizovaně řízenou službu. Technický správce Technický správce je útvar nebo organizace, která rozhoduje o způsobu (jakým software, jakým hardware, odkud, apod.) a formě (v jakém režimu tj. zda interně, kombinovaně či externě) bude požadovaná služba zajišťována (realizována). Stanovuje podmínky realizace a produkční podmínky (včetně podpůrných ICT služeb) tak, aby služba byla poskytována v souladu s požadavky věcného správce. Technický správce je pro každou veřejnou službu jen jeden. V rámci organizace je určen organizačním řádem nebo vedoucím představitelem organizace, případně ho - na základě obecně platných pravidel, určuje věcný správce. Provozovatel Provozovatel (poskytovatel služby) je útvar nebo organizace, jenž službu provozuje a dodává zákazníkům. Provozovatelů služby může být více (viz např. výdej občanských průkazů, ), mohou být jak interní (autentizovaní uživatelé), tak externí (klienti). Když služba má jednoho provozovatele, jedná se o centralizovaně provozovanou službu. 5-leté TCO (celkové náklady vlastnictví) v Kč bez DPH předběžný, kvalifikovaný odhad výše externích výdajů v českých korunách bez DPH na realizaci projektu a projekce externích výdajů na přesně 5-letý provoz (přepočet kvůli srovnatelnosti projektů s rozdílnou dobou udržitelnosti). Jedná se o součet hodnot uvedených ve sloupci 3 tabulky v kapitole formuláře žádosti. 1.3 Popis, potřebnost a výstupy projektu V tabulce 4: Popis funkčního celku, vyplňte: Popis výchozí situace projektu (tzv. As-Is) popište výchozí stav, ze kterého projekt vychází. Příklad výchozí situace může být zastaralý informační systém, který již v průběhu příštího roku nebude odpovídat legislativě. Projekt bude navázán na určitý projektový okruh v rámci egovernmentu a bude odpovídat přijatým strategiím. Požadavky / kritéria zákazníka jsou určující pro stanovení toho, co je třeba změnit, co lze využít bez e změny a co vybudovat zcela nově. Východiskem proto vždy musí být objektivní analýza současného stavu ne jen technické infrastruktury, ale i organizační, tzn.: procesů, politik, personálního zabezpečení atd. Výstupem této analýzy by vždy měly být: 5

6 popis a architektura současného stavu obsahující uvedení nedostatků identifikovaných s využitím určených kritérií, konečný návrh byznys a technické architektury cílového řešení, návrh systému optimalizace současných a nových HW technologií, Jako součást prokázání optimálnosti zvolené varianty by každý projekt měl obsahovat prokazatelné doložení hospodárnosti, tj. jasně specifikovat, co z existující infrastruktury a organizačních pravidel: lze / bude využito beze změn, bude využitelné za jakých změn a co, nadále využitelné nebude, včetně zdůvodnění proč. návrh nezbytného rozsahu nové provozně-technické a bezpečnostní dokumentace V rámci Veřejné správy součástí popisu současného stavu musí být i: a) popis propojení (agendového) i sdílení (dat a podpůrných aktiv) s dalšími systémy, b) schéma začlenění předmětné služby / systému do Enterprise architektury předkládající organizace / OVM včetně případných vazeb na sdílené služby veřejné správy, c) popis začlenění nové služby / systému, do současného kybernetického prostředí / Enterprise architektury předkládající organizace / OVM. 2 A R C H I T E K T O N I C K É I N F O R M A C E K F U N K Č N Í M U C E L K U V této kapitole jsou uvedeny informace o všem, co ovlivňuje motivaci a obsah předkládaného projektu, zejména pak všechny aspekty struktury a chování části úřadu, zahrnuté do projektu. Dále pak kontext architektury úřadu ve vztahu ke sdíleným službám egovernmentu. Struktura architektonické části dokumentu vychází ze struktury domén obsahu Národní architektury VS ČR. 2.1 Dodržení architektonických principů NA VS ČR Architektonické principy jsou z cílů rozvoje egovernmentu odvozená pravidla, která slouží primárně k tomu, aby byla plně dodržena při návrzích cílové architektury veřejné správy (a jejích informačních systémů), které tak největší měrou naplní reformní cíle strategie veřejné správy. Definovanými architektonickými principy jsou: Název principu Dostupnost Znění principu Služby veřejné správy musí být všem dostupné především v elektronické podobě, v jakémkoliv čase, v jakékoliv lokalitě a musí být poskytovány nediskriminačním a 6

7 Název principu Použitelnost Důvěryhodnost Znění principu bezbariérovým způsobem. Služby veřejné správy musí být navrhovány s ohledem na potřeby klienta tak, aby mohl vždy vyřídit svoji životní situaci v úplnosti elektronickou službou. Elektronické služby veřejné správy musí být koncipovány takovým způsobem, aby klienti měli plnou důvěru k jejich využívání. Transparentnost Pořízení, rozvoj i provoz služeb veřejné správy musí být vždy zajištěn transparentním způsobem. Bezpečnost Spolupráce a sdílení Udržitelnost Technologická neutralita Elektronické služby musí zajistit adekvátní zabezpečení datového obsahu i přístupu k datům a službám samotným. Elektronické služby veřejné správy jsou navrhovány a budovány primárně na principu spolupráce a sdílení informací a zdrojů mezi úřady veřejné správy. Pořízení nových služeb veřejné správy musí být vždy opodstatněné a služby musí být navrhovány jako dlouhodobě využitelné. Služby veřejné správy musí být koncipovány jako technologicky a platformově nezávislé a nesmí být závislé na omezené skupině dodavatelů. 2.2 Enterprise architektura projektu a její kontext Obecně platí, že všechny prvky modelu architektury, zachycené v některém z katalogů, se musí objevit také v odpovídajících grafických diagramech a naopak. Katalogy jsou předpokladem úspěšné tvorby digramů. Diagramy nad rámec katalogů přinášejí informace o vzájemných vazbách mezi objekty uvnitř katalogů i mezi nimi. V tabulce 5: Vyplňte, jakým způsobem předáváte model Enterprise architektury řešení projektu v rámci žádosti o stanovisko. Případně vysvětlete, proč to z Vaší strany není možné Strategie a směrování - Motivační architektura V tabulce 6: Vysvětlete, proč projekt realizujete v této podobě a čeho jím chcete dosáhnout. Pro vysvětlení motivace použijte zejména pojmy z odpovídajícího modelu motivační architektury (motivátory, zainteresované, cíle, principy, podmínky, architektonické požadavky) vysvětlete důvody, které vedly k potřebě realizace projektu a podstatné skutečnosti, které mají vliv na způsob realizace projektu. Popište, pro jakou změnu je projekt navržen, co změnu vyvolalo, kdo stojí o její realizaci a jak se pozná, že měl projekt požadovaný efekt do příslušných oblastí výkonu veřejné správy Efektivita projektu Výkonnostní architektura V tabulce 7: Vysvětlete dopad projektu na hospodárnost, účelnost, účinnost a kvalitu služeb v organizaci, objasněte, s jakými přínosy je projekt spojen, jaké ukazatele efektivity, výkonnosti a kvality jsou pro projekt relevantní, pokud nějaké a jak je možné je měřit. Rozdělení ukazatelů výkonnosti vychází z tzv. Logického modelu řízení výkonnosti a zodpovědnosti, viz následující schéma. Z něj je patrné, že strategické cíle (politiky) je možno naplňovat pouze konkrétními činnostmi (službami veřejné správy), které i díky podpoře ICT řešeními mohou být (měly by být) efektivnější než před projektem. Schéma ukazuje vzájemný vztah ukazatelů efektivity (3E), které jsou detailně vysvětleny pod čarou. 7

8 Dále uveďte vliv projektu na zvyšování úrovně a kvality předmětné služby, tj. hodnoty služby vnímané jejími spotřebiteli, klienty veřejné správy. V tabulce 8: Přehled požadovaných cílových parametrů SLA nových nebo měněných služeb, popište jednotlivé nové nebo měněné služby v rámci projektu a specifikujte jejich SLA neboli požadovanou úroveň služby: Název v rámci projektu nově zřizované nebo měněné služby: žadatelem definovaný název Specifikace SLA parametru služby: popis zda jde o dostupnost, čas potřebný k obnovení, čas potřebný k reakci na incident apod. Sjednaná mezní hodnota SLA parametru: mezní hodnota pro SLA parametr, např. pro dostupnost 99,9% Sjednaná metrika: sjednaný způsob měření a vyhodnocení parametru SLA. Pro každou službu může být definováno více SLA parametrů V tabulce 9: Popis klíčových měřitelných ukazatelů výkonnosti (KPI), popište jednotlivé nové nebo měněné služby v rámci projektu a specifikujte jejich KPI neboli klíčových ukazatelů výkonnosti: Název v rámci projektu nově zřizované nebo měněné služby: žadatelem definovaný název Kolik stojí každá ukončená transakce, kterou poskytujete - popište předpokládané náklady na transakci (celá služba od začátku do konce) v Kč bez DPH. Jaké procento uživatelů je spokojeno s poskytovanou službou: uveďte hodnoty jaké procento uživatelů je s elektronickou službou spokojeno. Jaké procento transakcí je úspěšně dokončeno / kolik procent ze započatých transakcí je dovedeno uživatelem do úspěšného konce. Jaké procento uživatelů si zvolí raději elektronickou formu služby než ne-elektronickou / kolik procent lidí preferuje elektronickou verzi služby oproti její asistované podobě Poskytování veřejných služeb - Byznys architektura Tato část architektury projektu objasňuje, kdo (aktéři), v jaké roli a kudy (komunikační kanály) se zapojuje do činností úřadu, zahrnutých do projektu. Cílem byznys architektury v této žádosti je poznat a pochopit, které funkce úřadu jsou vykonávány jako služba, kým, pro koho a kterým kanálem. V tabulce 10: Katalog organizačních jednotek, aktérů a rolí, vyplňte Aktér (organizace, organizační jednotky / úředníci, klienti veřejné správy) seznam orgánů veřejné moci a případně jejich organizačních útvarů či typových pracovníků a typových klientů veřejné správy (občanů i organizací) - všechny subjekty, jichž se řešení realizované projektem dotýká. Role aktérů při výkonu a příjmu služby seznam rolí, ve kterých vystupují aktéři uvedení v předchozím seznamu. Pro katalog aktérů a katalog rolí uveďte následující údaje: Název objektu název aktéra/role. 8

9 Počet uživatelů IS odhad počtu aktérů/rolí, kteří budou uživateli informačního systému, jenž je předmětem projektu. Pokud předmětem projektu není žádný informační systém, tak sloupec nevyplňujte. Celkový součet přes všechny kategorie je přirozeně větší, než celkový počet uživatelů, protože uživatelé mohou být rozepsáni současně do více kategorií. Jeden uživatel se započte současně do organizace, do role i do typického aktéra. Počty uživatelů celého IS uveďte alespoň jednou, v té kategorii, kde se Vám to podaří nejlépe odhadnout. Vysvětlení významu objektu bližší objasnění aktéra/role, tak aby bylo zcela zřejmé, oč se jedná, není-li dostatečný již sám název. V tabulce 11: Katalog funkcí a procesů veřejné správy a ve veřejné správě, vyplňte Agendové funkce (agendy dle RPP, dále neregistrované, podpůrné a provozní agendy nebo funkční oblasti) seznam funkcí organizace odpovídajících jednak agendám registrovaným nebo neregistrovaným působícím na vnějšek organizace (např. výkon kontrolní činnosti) a dále podpůrným a provozním funkcím působícím dovnitř organizace (např. účetnictví nebo personalistika). Uvádějte jen takové funkce, které jsou předmětem projektu zaváděny, měněny, podporovány či jinak dotčeny. Procesy v agendách nebo funkčních oblastech seznam procesů, které jsou vykonávány za účelem výkonu a naplňování funkcí uvedených v přechozím katalogu. Funkce (činnosti) řazené v procesu nebo samostatně existující na podporu agend / funkčních oblastí nepovinný seznam standardních činností vykonávaných v rámci procesů uvedených v předchozím katalogu nebo i činností, které nejsou řazeny v žádném procesu, ale jsou vykonávány v rámci funkce organizace uvedené v katalogu předcházejícím procesům. Pro katalog funkcí a procesů uveďte následující údaje: Název objektu název nebo označení funkce nebo procesu. Vysvětlení významu objektu bližší objasnění funkce nebo procesu, tak aby bylo zcela zřejmé, co je jeho obsahem a účelem, není-li dostatečný již sám název. V tabulce 12: katalog (interních a externích) služeb veřejné správy, pro jednotlivé služby vyplňte Interní služby veřejné správy seznam interních služeb veřejné správy (poskytované uvnitř veřejné správy jiným veřejným organizacím), které jsou předmětem projektu zaváděny, měněny nebo podporovány. Externí služby veřejné správy seznam externích služeb veřejné správy (poskytované směrem ke klientům veřejné správy, tj. občanům a organizacím), které jsou předmětem projektu zaváděny, měněny nebo podporovány. Pro katalog služeb uveďte následující údaje: Název služby název interní nebo externí služby. Kdo poskytuje službu označení poskytovatele služby (typicky role), tedy toho, kdo službu poskytuje (dodává, nabízí). Kdo je konzumentem služby označení typicky role, která službu využívá a přijímá její hodnotu. Konzumenty mohou být uživatelé z řad veřejné správy (interní i externí) i veřejnost (občané a komerční subjekty). Klíčovým prvkem rozdělení z hlediska poskytovaných funkcionalit je, zda jde o uživatele autentizované, nebo anonymní. Výčet použitých obslužných rozhraní služby seznam rozhraní (komunikačních a obslužných kanálů), přes které je služba poskytována konzumentům. Do pole uveďte výčet všech rozhraní oddělených středníkem nebo čárkou. V tabulce 13: Využití front-office rozhraní předmětem projektu, zvolte z nabízených variant a vyplňte Asistovaná přepážka uveďte, zda bude moci klient veřejné správy vykonat kontakt s úřadem osobně na fyzické přepážce s využitím asistence vyškoleného pracovníka. Webový portál uveďte, zda bude moci klient veřejné správy vykonat kontakt s úřadem prostřednictvím samoobslužného webového portálu. Datová zpráva (ISDS) uveďte, zda bude moci klient veřejné správy vykonat kontakt s úřadem zasláním datové zprávy do datové schránky úřadu. Elektronicky podepsaný dokument do e-podatelny uveďte, zda bude moci klient veřejné správy vykonat kontakt s úřadem zasláním elektronicky podepsaného dokumentu. 9

10 Listinnou cestou do podatelny uveďte, zda bude moci klient veřejné správy vykonat kontakt s úřadem listinným podáním poštou nebo osobně na podatelně úřadu. Pro katalog funkcí a procesů uveďte následující údaje: Využití vyberte skutečnosti odpovídající variantu, tj. zda je rozhraní (obslužný kanál) v projektu zahrnut (Ano) nebo není (Ne) či je pro konkrétní projekt takový kanál zcela Nerelevantní. Popis využití rozhraní v projektu bližší objasnění, tak aby bylo zcela zřejmé, k čemu bude obslužný kanál sloužit a v jakém rozsahu. V tabulce 14: Využití propojeného datového fondu, zvolte z nabízených variant a vyplňte Čtení referenčních údajů FO (ROB) uveďte, zda bude řešení, jež je předmětem projektu, čerpat referenční údaje (číst) z Registru obyvatel. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Zápis nových FO (ROB) uveďte, zda bude řešení, jež je předmětem projektu, zapisovat nové záznamy do Registru obyvatel. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Editace referenčních údajů FO (ROB) uveďte, zda bude řešení, jež je předmětem projektu, editovat referenční nebo jiné údaje v Registru obyvatel. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Čtení referenčních údajů PO (ROS) uveďte, zda bude řešení, jež je předmětem projektu, čerpat referenční údaje (číst) z Registru osob. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Zápis nových organizací (ROS) uveďte, zda bude řešení, jež je předmětem projektu, zapisovat nové záznamy do Registru osob. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Editace referenčních údajů PO (ROS) uveďte, zda bude řešení, jež je předmětem projektu, editovat referenční nebo jiné údaje v Registru osob. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Čtení referenčních údajů míst a adres (RÚIAN) uveďte, zda bude řešení, jež je předmětem projektu, čerpat referenční údaje (číst) z Registru územní identifikace, adres a nemovitostí. Zápis nových územních id. (RÚIAN) uveďte, zda bude řešení, jež je předmětem projektu, zapisovat nové záznamy do Registru územní identifikace, adres a nemovitostí. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Editace referenčních údajů míst a adres (RÚIAN) uveďte, zda bude řešení, jež je předmětem projektu, editovat referenční nebo jiné údaje v Registru územní identifikace, adres a nemovitostí. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Zápis a využití práv a povinností při využívání údajů agend (RPP) uveďte, zda bude řešení, jež je předmětem projektu, využívat nebo zapisovat práva a povinnosti z Registru práv a povinností. Zápis rozhodnutí o změnách údajů agend dle 52 zák. 111/2009 Sb. (RPP) uveďte, zda bude řešení, jež je předmětem projektu, zapisovat rozhodnutí do Registru práv a povinností. Čerpání informací z agend jiných úřadů (Integrační platformy, egsb) uveďte, zda bude řešení, jež je předmětem projektu, využívat (čerpat) nějaká data prostřednictvím služeb egon Service Bus nebo jiných integračních platforem. Uveďte jaká data a od koho budou čerpána. Poskytování informací agendám jiných úřadů (Integrační platformy, egsb) uveďte, zda bude řešení, jež je předmětem projektu, publikovat nějaká data prostřednictvím služeb egon Service Bus nebo jiných integračních platforem. Uveďte jaká data a komu budou poskytována. Pro seznam využití propojeného datového fondu uveďte následující údaje: Použito výběr ze seznamu, zda je pro projekt prvek propojeného datového fondu Nerelevantní nebo zda je jeho použití plánováno (Ano). Jejich nepoužití, i když je relevantní, znamená nutnost požádat o výjimku. Č. žádosti o výjimku v případě, že je ve sloupci Použito zvolena možnost Ne, žádáme výjimku, tak uveďte číslo příslušné žádosti o výjimku, jaké má v poslední kapitole Přílohy. 10

11 Vysvětlení bližší objasnění rozsahu a způsobu využití prvku propojeného datového fondu. Případně, pokud to není zcela jasné, uveďte proč je použití nerelevantní. Zákonné zmocnění k přístupu uveďte právní předpis, který umožňuje v projektu využít prvek propojeného datového fondu, pokud je jeho využití plánováno. V tabulce 15: Využití dalších klíčových prvků egovernmentu v byznys architektuře projektu, zvolte z nabízených variant a vyplňte, informace o cílovém stavu, tj. využívání kterých prvků egovernmentu povinných k využití na byznys vrstvě je nebo není v rámci projektu plánováno. Identifikace, autentizace úředníka využití identity úředníka z JIP/KAAS (jednotný identitní prostor/katalog autentizačních a autorizačních služeb) pro identifikaci uživatelů informačního systému z řad pracovníků veřejné správy. Identifikace, autentizace klienta dodržení zákona č. 250/2017 Sb., o elektronické identifikaci pro identifikaci uživatelů informačního systému z řad veřejnosti. Doručování využití datových schránek pro účely doručování jiným veřejným institucím a soukromoprávním subjektům (organizacím a občanům) a příjem od jiných veřejných institucí. Dodávání využití datových schránek pro účely příjmu nebo odesílání mezi veřejnou institucí a soukromoprávním subjektem (organizace nebo občan), které není činěním úkonu vůči OVM (např. faktury). Provádění úkonů využití datových schránek pro účely příjmu úkonů učiněných soukromoprávním subjektem vůči OVM (např. podání od organizací nebo občanů). Pro seznam klíčových prvků egovernmentu uveďte následující údaje: Použito výběr ze seznamu, zda je pro projekt prvek národního egovernmentu Nerelevantní (pro službu povinnost neplatí nebo už naopak tuto povinnost splňuje, a tedy ji neřeší) nebo zda je jeho použití plánováno (Ano). Jejich nepoužití, v případě, že je pro danou službu relevantní, znamená nutnost požádat o výjimku. Č. žádosti o výjimku v případě, že je ve sloupci Použito zvolena možnost Ne, žádáme výjimku, zde uveďte číslo příslušné žádosti o výjimku, které má v poslední kapitole Přílohy. V tabulce 16: Identifikace, autentizace a autorizace subjektů/uživatelů v jejich rolích, vyplňte vysvětlení, jak budou řešeny: identifikace, autentizace a autorizace uživatelů systému a to jak interních (úředníků), tak i externích klientů (občanů). Postupně popište: Služba využívající identifikaci, autentizaci a autorizaci: Název každé služby, které využívá pro své fungování identifikaci, autentizaci a autorizaci nebo např. jen identifikaci. Vysvětlení způsobů identifikace, autentizace a autorizace: Vysvětlete způsob ověření identity subjektů / uživatelů v jejich rolích pro službu a informační systém. Například využití NIA, interního IDM nástroje, apod. Druh autentizace: Popište konkrétní technický způsob autentizace, např. jméno+heslo; dvoufaktorová autentizace, Token kartička, apod. Dále zde uveďte: Model byznys architektury (výkonu veřejné správy) pohled činnostních funkcí požadavky na diagram jsou popsány v dokument Definice pohledů dle formuláře žádosti o stanovisko typu A, který je ke stažení na webových stránkách odboru Hlavního architekta MV na adrese: Model byznys architektury (výkonu veřejné správy) pohled služeb veřejné správy požadavky na diagram jsou popsány v dokument Definice pohledů dle formuláře žádosti o stanovisko typu A, který je ke stažení na webových stránkách odboru Hlavního architekta MV na adrese: V tabulce 17: Dodržení architektonických principů byznys vrstvy, pro jednotlivé principy, zvolte odpověď, která vyjadřuje, zda projekt je v souladu uvedenými požadavky, nebo ne, a v případech, kdy je požadavek pro projekt relevantní, ale není s ním v souladu a žádáte výjimku, zde uveďte číslo příslušné žádosti o výjimku, které má v poslední kapitole Přílohy. Pro seznam architektonických principů uveďte následující údaje: 11

12 Dodrženo výběr ze seznamu, zda je pro projekt požadavek Nerelevantní nebo zda je jeho naplnění plánováno (Ano). Nenaplnění, i když je relevantní, znamená většinou nutnost požádat o výjimku. Nepovinné jsou požadavky, které jsou ve sloupci Č. výjimky needitovatelné a šedě podbarvené. Č. žádosti o výjimku v případě, že je ve sloupci Dodrženo zvolena možnost Ne, žádáme výjimku, tak uveďte číslo příslušné žádosti o výjimku, jaké má v poslední kapitole Přílohy. Pro nepovinné požadavky (šedě podbarvené) se nevyplňují nikdy. Způsob a míra naplnění vysvětlete jakým způsobem je projektem naplněn požadavek, případně vysvětlete, proč naplněn není nebo je nerelevantní. V tabulce 18: Vysvětlení v kontextu byznys architektury úřadu, tedy, vyplňte, jaké k projektu existují či jeho realizací vzniknou procesní / kompetenční / motivační duplicity a proč, a jaké jsou další souvislosti uveďte všechny duplicity, které se na byznys vrstvě vyskytují, jako je například více úzce specializovaných obslužných kanálů (např. webových portálů). Popište vztahy předmětu projektu ke všem obdobným řešením v úřadu, v resortu a v celém státu. Uveďte do kontextu všechny do projektu zahrnuté funkce (procesy či služby). Vysvětlete, jak případně tato služba souvisí (je sdílena, sdílí / vyměňují si data, ) s ostatními vykonávanými službami pracovišť rozšířeného řetězce. Vysvětlení byznys architektury projektu prostor pro vysvětlení všech dalších potřebných souvislostí a pro projekt důležitých informací, spojený s výše uvedenými architektonickými objekty, anebo je doplňující Architektura informační systémů (aplikací a dat) Vrstva architektury informačních systémů se dělí na dvě dílčí, na aplikační architekturu a datovou architekturu Architektura informační systémů část: Aplikační architektura Tato část architektury projektu objasňuje, které aplikační komponenty budou projektem zavedeny, změněny nebo zrušeny, jaká jsou jejich vzájemná a externí rozhraní a na podporu kterých byznys funkcí slouží. V tabulce 19: Katalog všech aplikačních komponent řešení a klíčových aplikačních funkcí, zvolte odpovídající druh položky a vyplňte Komponenty, funkce a aplikační služby vytvářené nebo významně měněné v rámci záměru (žádosti) seznam aplikačních komponent, jejich funkcí a jimi poskytovaných služeb, jejichž vytvoření, úprava nebo rozšíření je předmětem projektu. Ostatní komponenty, funkce a aplikační služby integrované na výše uvedené nebo jinak podstatné pro žádost seznam aplikačních komponent, jejich funkcí a jimi poskytovaných služeb, které věcně či technicky souvisí s prvky uvedenými v předchozím katalogu prvků, jež jsou předmětem projektu. Pro katalog aplikačních komponent a funkcí uveďte následující údaje: Typ prvku určení, zda je položka katalogu komponenta, funkce nebo služba. Název prvku název nebo označení prvku. Vysvětlení významu aplikačních komponent, funkcí a služeb bližší objasnění obsahu a významu prvku, tak aby bylo zcela zřejmé, k čemu slouží a co zajišťuje, není-li dostatečný již sám název. V tabulce 20: Katalog aplikačních rozhraní, vyplňte Interní rozhraní seznam aplikačních rozhraní řešení mířených na další aplikace uvnitř úřadu, případně resortu, krajské korporace, apod. Externí rozhraní seznam aplikačních rozhraní řešení mířených na aplikace egovernmentu a jiných úřadů, případně jiná rozhraní. Pro katalog aplikačních rozhraní uveďte následující údaje: Název aplikačního rozhraní název nebo označení aplikačního rozhraní. Komponenta A v případě jednostranné komunikace uveďte volající aplikační komponentu, tedy tu, které je příjemcem informací. V případě oboustranné komunikace uveďte primárně interní komponentu. 12

13 Komponenta B v případě jednostranné komunikace uveďte odpovídající aplikační komponentu, tedy tu, které je poskytovatelem informací. V případě oboustranné komunikace uveďte primárně externí komponentu. Vysvětlení významu aplikačních komponent, funkcí a služeb bližší objasnění obsahu a četnosti komunikace vedené přes aplikační rozhraní. Uveďte aplikační rozhraní aplikačních komponent zahrnutých do projektu na ostatní s nimi integrované komponenty (mající na ně rozhraní, interní a externí z pohledu úřadu). V tabulce 21: Katalog aplikacemi podporovaných agend, vyplňte seznam do projektu zahrnutých informačních systémů, které jsou představovány výše uvedenými aplikačními komponentami projektu, a agend, které jsou s jejich pomocí vykonávány. Pro katalog aplikačních komponent a funkcí uveďte následující údaje: Realizovaný systém informační systém vytvářený, upravovaný, rozšiřovaný nebo podporovaný v rámci projektu. Používejte název nebo označení použité již v katalogu aplikačních komponent. Agenda agenda uvedená v katalogu agendových funkcí v kapitole 2.2.3, která je zajišťována či podporována informačním systémem. Modely aplikační architektury pohled struktury aplikací požadavky na diagram jsou popsány v dokument Definice pohledů dle formuláře žádosti o stanovisko typu A, který je ke stažení na webových stránkách odboru Hlavního architekta MV na adrese: Modely aplikační architektury pohled komunikace aplikací požadavky na diagram jsou popsány v dokument Definice pohledů dle formuláře žádosti o stanovisko typu A, který je ke stažení na webových stránkách odboru Hlavního architekta MV na adrese: V tabulce 22: Katalog komunikačních (obslužných) rozhraní, kanálů koncových klientů, zvolte skutečnosti odpovídající z nabízených variant a vyplňte Asistovaná přepážka Přepážka úřadu možnost příjmu podání a poskytování výpisů na vlastní přepážce organizace za asistence k tomu kompetentního pracovníka. CzechPOINT (přepážka) povinné rozhraní pro poskytování výpisů a příjem podání prostřednictvím univerzálního kontaktního místa veřejné správy. Relevantní jen pro takové výpisy a podání, u kterých se předpokládá dostatečná četnost využívání. Call-centrum možnost příjmu podání a poskytování informací a konzultací prostřednictvím telefonního či jiného hlasového rozhraní. Webový portál Aplikace v portálu úřadu s autentizovaným klientem webový portál (lehký klient) pro příjem podání, poskytování výpisů a zobrazování a správu personalizovaných informací (dat a žádostí přihlášeného klienta veřejné správy). Předpokladem je přímé provázání na příslušné agendové informační systémy. CzechPOINT@home povinné rozhraní pro poskytování výpisů a příjem podání prostřednictvím samoobslužného kontaktního místa veřejné správy. Relevantní jen pro takové výpisy a podání, u kterých se předpokládá dostatečná četnost využívání. Tlustý aplikační klient nainstalovaná počítačová aplikace (tlustý klient) pro činění podání, poskytování výpisů a zobrazování a správu personalizovaných informací (dat a žádostí přihlášeného klienta veřejné správy). Mobilní aplikace nainstalovaná aplikace pro mobilní telefony určená pro činění podání, poskytování výpisů a zobrazování a správu personalizovaných informací (dat a žádostí přihlášeného klienta veřejné správy). CzechPOINT@office povinné rozhraní pro poskytování výpisů a příjem podání ve vztahu mezi jednotlivými orgány veřejné moci prostřednictvím rozšířeného back-office úředníka. V případě, že jsou pro tento účel navzájem propojeny veškeré relevantní agendové informační systémy všech dotčených organizací, tak jen toto rozhraní nerelevantní. Datová zpráva (ISDS) 13

14 Formulář v DS povinné rozhraní pro příjem podání ve formě strukturovaného formuláře doručovaného skrze Informační systém datových schránek. Předpokládá se schopnost vytěžení relevantních dat z formuláře do příslušných informačních systémů. Elektronicky podepsaný dokument do e-podatelny s elektronicky podepsaným formulářem rozhraní pro příjem podání ve formě strukturovaného formuláře opatřeného elektronickým podpisem doručovaného do mailové schránky podatelny organizace. Předpokládá se schopnost vytěžení relevantních dat z formuláře do příslušných informačních systémů a ověření podpisu. Webová aplikace pro zaslání elektronicky podepsaného dokumentu do e-podatelny webový portál (lehký klient) pro vyplnění a odeslání elektronického formuláře včetně jeho opatření elektronickým podpisem klienta. Předpokladem je přímé provázání na příslušné agendové informační systémy. Listinnou cestou do podatelny Formulář listinnou poštou strukturovaný formulář pro podání dostupný ke stažení a vytisknutí na webových stránkách úřadu nebo k vyzvednutí na pobočce úřadu, který je určen k vyplnění a zaslání prostřednictvím poštovních služeb. Formulář na listinnou podatelnu (osobně) strukturovaný formulář pro podání dostupný ke stažení a vytisknutí na webových stránkách úřadu nebo k vyzvednutí na pobočce úřadu, který je možné osobně doručit na podatelnu organizace. Jiné s formulářem bez elektronického podpisu rozhraní pro příjem podání ve formě strukturovaného formuláře nebo nestrukturované zprávy doručované do mailové schránky podatelny organizace. Případně poskytování notifikací klientům veřejné správy o vyřízení žádosti či vstupu do některé relevantní životní situace. Aplikace v portálu úřadu s neautentizovaným klientem webový portál (lehký klient) pro činění podání a poskytování výpisů pro anonymní či nepřihlášené klienty. Předpokladem je přímé provázání na příslušné agendové informační systémy. Aplikační rozhraní pro externí systémy aplikační rozhraní pro přímou komunikaci a výměnu dat mezi informačními systémy různých orgánů veřejné správy. Pro katalog komunikačních rozhraní a kanálů uveďte následující údaje: Využití výběr ze seznamu, zda je pro projekt rozhraní/kanál Nerelevantní nebo zda je jeho využití plánováno. Pro povinná rozhraní a kanály, jež jsou pro projekt relevantní, musí být v případě jejich nevyužití zvolena možnost Ne, žádáme výjimku. Č. žádosti o výjimku v případě, že je ve sloupci Dodrženo zvolena možnost Ne, žádáme výjimku, tak uveďte číslo příslušné žádosti o výjimku, jaké má v poslední kapitole Přílohy. Počet uživatelských přístupů ročně odhad předpokládaného počtu klientů obsluhovaných skrze rozhraní/kanál ročně. Zohledněte rovněž předpoklad rostoucího zájmu o elektronické kanály v následujících letech. Popis využití rozhraní v projektu bližší objasnění účelu a způsobu využití rozhraní/kanálu, tak aby bylo na obecné úrovni zřejmé, jaké dokumenty a informace budou skrze rozhraní/kanál vyměňovány a jakým směrem. Případně, pokud to není zcela jasné, uveďte proč je využití nerelevantní. V tabulce 23: Dodržení architektonických principů aplikační vrstvy, zvolte skutečnosti odpovídající z nabízených variant, zda je projekt v souladu uvedenými požadavky jednotlivých principů. Pro seznam architektonických principů uveďte následující údaje: Dodrženo výběr ze seznamu, zda je pro projekt požadavek Nerelevantní nebo zda je jeho naplnění plánováno (Ano). Nenaplnění, i když je relevantní, znamená většinou nutnost požádat o výjimku. Nepovinné jsou požadavky, které jsou ve sloupci Č. výjimky needitovatelné a šedě podbarvené. Č. výjimky v případě, že je ve sloupci Dodrženo zvolena možnost Ne, žádáme výjimku, uveďte zde číslo příslušné žádosti o výjimku, jaké má v poslední kapitole Přílohy. Pro nepovinné požadavky (šedě podbarvené) se nevyplňují nikdy. Způsob a míra naplnění vysvětlete jakým způsobem je projektem naplněn požadavek, případně vysvětlete, proč naplněn není nebo je nerelevantní. 14

15 V tabulce 24: Vysvětlení v kontextu aplikační architektury úřadu, tedy, vyplňte, jaké k projektu existují či vznikají duplicity a proč a jaké jsou další souvislosti. Uveďte všechny duplicity, které se na aplikační vrstvě vyskytují. Například, jak souvisí navrhované komponenty s ostatními obdobnými komponentami úřadu (například zda a proč potřebuje nová agenda samostatnou spisovou službu nebo naopak, jak nová agendová aplikační komponenta využije stávající komponenty spisové služby a platebního nástroje úřadu). Popište vztahy předmětu projektu ke všem obdobným řešením v úřadu, resortu a celém státu. Vysvětlete, jak bude integrována centrální aplikační komponenta s existujícími nebo připravovanými lokálními aplikačními komponentami a funkcemi řešení na pracovištích rozšířeného řetězce dodávky této veřejné služby. Vysvětlení aplikační architektury projektu prostor pro vysvětlení všech dalších potřebných souvislostí a pro projekt důležitých informací, spojený s výše uvedenými architektonickými objekty, anebo je doplňující Architektura informačních systémů část: Datová architektura Tato část architektury projektu objasňuje, které základní objekty a subjekty reálného světa, ve světle jejich zahrnutí do právního prostředí české VS, budou předmětem evidence budovaného či měněného procesu veřejné služby a odpovídajícího informačního systému. V tabulce 25: Katalog základních datových entit projektu, zvolte skutečnosti odpovídající z nabízených variant a vyplňte, které důležité objekty a subjekty reality a práva jsou předmětem evidence navrhovaného informačního systému. Pro katalog datových entit uveďte následující údaje: Objekt reálného světa, který je předmětem evidence nejdůležitější objekty, které budou v řešení evidovány (např. řidiči, žádosti, správní řízení). Vysvětlení objektu bližší objasnění obsahu a předpokládaného počtu evidovaných objektů. Je objekt čerpán nebo poskytován jiným subjektům? vyberte, zda daný objekt čerpáte či poskytujete někomu jinému. V tabulce 26: Využití datového fondu základních registrů a dalších agend, zvolte skutečnosti odpovídající z nabízených variant a vyplňte Základní registry Způsob vedení datového kmene uveďte, jakým způsobem bude veden datový kmen údajů ze Základních registrů. Standardní jsou dva způsoby: 1. Evidence referenčních údajů s notifikací změn ze ZR evidence referenčních údajů ve vlastní databázi za použití notifikace změn ze základních registrů. Výsledkem tedy je, že v agendovém informačním systému jsou uloženy údaje, jako jméno/název, adresa atd. spolu s agendovými údaji a při každé změně referenčních údajů v základních registrech jsou tyto v agendovém systému aktualizovány. 2. Evidence jen identifikátoru (pseudonymu) a při potřebě zobrazení aktuální podoby referenčních údajů ze ZR evidence jen unikátního identifikátoru (AIFO/IČ) v agendovém informačním systému s tím, že při potřebě čtení záznamů souvisejících se subjektem se provede dotaz na aktuální verzi referenčních údajů ze základních registrů, které jsou zobrazeny a následně opět smazány. 3. Nerelevantní vyberte, pokud předmět projektu nepovede datový kmen využívající referenční údaje ze základních registrů. 4. Jiný, popište tuto možnost zvolte v případě, že datový kmen bude vedený jiným než některým výše uvedeným způsobem. Je třeba podrobně popsat zvolený způsob do sloupce Vysvětlení. Evidujeme subjekty práva, které nejsou vedeny v ZR (např. zahraniční) uveďte, zda budou předmětem evidence subjekty práva, které nejsou vedeny v žádném ze základních registrů jako referenční údaje. Evidujeme fyzické osoby, které nejsou vedeny v ROB uveďte, zda budou předmětem evidence fyzické osoby, které nejsou vedeny v Registru obyvatel. Případně upřesněte míru užití Evidence jiných fyzických osob (EJFO) či jiný způsob naložení s těmito subjekty. Využití údajů publikovaných prostřednictvím kompozitních služeb editorů Základních registrů 15

16 Evidence obyvatel (ISEO) uveďte, zda a v jakém rozsahu plánujete využít kompozitní služby Informačního systému Evidence obyvatel. Cizinecký informační systém (CIS) uveďte, zda a v jakém rozsahu plánujete využít kompozitní služby Cizineckého informačního systému. egon Service Bus Čerpání dat přes egsb uveďte, zda bude součástí projektu použití egon Service Bus pro čerpání dat z jiných systémů nebo pro využití jiných služeb egsb. Uveďte jaká data a služby budou skrze egsb využívána. Publikování vlastních dat přes egsb uveďte, zda bude součástí projektu publikace dat prostřednictvím egon Service Bus pro jiné agendové informační systémy a jaká data budou publikována. Pro seznam využití datového fondu uveďte následující údaje: Použito vyberte ze seznamu možností způsob nakládání s datovým kmenem. Č. žádosti o výjimku v případě, že je ve sloupci Použito zvolena možnost Ne, žádáme výjimku, tak uveďte číslo příslušné žádosti o výjimku, jaké má v poslední kapitole Přílohy Vysvětlení bližší objasnění rozsahu a způsobu využití prvku. Případně, pokud to není zcela jasné, uveďte proč je použití nerelevantní. V tabulce 27: Způsob zajištění vedení dat s ohledem na otevřená data veřejné správy, zvolte skutečnosti odpovídající z nabízených variant a vyplňte Zajištění přístupu k datům Budete mít zajištěn přístup k veškerým datům vedeným v databázích dotčených předmětem projektu ve strojově čitelném a otevřeném formátu? - Uveďte Ano pouze v případě, že přístup k datům bude zajištěn prostřednictvím alespoň jedné z následujících možností: - API, které můžete kdykoliv využívat alespoň k tomu, abyste pomocí sady požadavků získali veškeré údaje ze všech databází dotčených předmětem projektu ve strojově čitelném a otevřeném formátu ve smyslu 3 odst. 7 a 8 zákona č. 106/1999 Sb., o svobodném přístupu k informacím. K API musíte mít k dispozici vždy aktuální a kompletní dokumentaci popisující syntaxi a sémantiku jeho datových struktur a syntaxi, sémantiku a způsob přístupu k operacím, které API nabízí. - Export kompletního obsahu databází dotčených předmětem projektu na požádání nebo v pravidelných intervalech ve strojově čitelném a otevřeném formátu ve smyslu 3 odst. 7 a 8 zákona č. 106/1999 Sb., o svobodném přístupu k informacím. Budete mít výše popsaný přístup k datům zajištěn bez dodatečných finančních nákladů? - Uveďte Ano pouze v případě, že přístup k datům popsaný v předchozí otázce budete moci využívat bez dodatečných nákladů. V případě odpovědi Ano nesmí být přístupy k API dodavatelem zpoplatňovány (jednotlivě ani paušálně) a stejně tak nesmí dodavatel žádat úplatu za provádění jednotlivých exportů obsahu databází. Úplatu může dodavatel žádat pouze za vytvoření a zajištění provozu a podpory API či za vytvoření a zajištění provozu a podpory exportního mechanismu. V této úplatě však nesmí být zahrnuty samotné přístupy k API či provádění exportů. Budete moci se zpřístupněnými daty libovolně nakládat? - Uveďte Ano, pokud nejste žádným způsobem, s výjimkou právních předpisů, omezení v nakládání se získanými daty. Jedná se zejména o ujednání ve smluvní dokumentaci omezující nakládání s daty. Publikace výstupů ve formátu otevřených dat Budou data vedená v databázích dotčených předmětem projektu zveřejňována jako otevřená data - Uveďte Ano, pokud budou data (vlastní obsah databáze a/nebo souhrnné statistiky) zveřejňována jako otevřená data dle zákona č. 106/1999 Sb., o svobodném přístupu k informacím a dle pokynů a dobré praxe popsané na portále otevřených dat a budou katalogizována v Národním katalogu otevřených dat. Nerelevantní se použije výhradně tehdy, pokud není předmětem projektu dotčena žádná databáze nebo databáze obsahuje pouze data, která není možné publikovat ani v podobě souhrnných statistik. Jaké datové oblasti plánujete zveřejňovat jako otevřená data a kdy? - Uveďte rámcově oblasti dat, ve kterých předpokládáte publikaci datových sad jako otevřená data. Pro každou 16

Metodický pokyn. k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ B2

Metodický pokyn. k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ B2 Metodický pokyn k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ B2 Odbor Hlavního architekta egovernmentu MV Praha, září 2018 verze 6.0 Toto dílo podléhá

Více

Posuzování projektů odborem Hlavního architekta egovernmentu. Mgr. Tomáš Kroupa Ing. Martin Tajtl

Posuzování projektů odborem Hlavního architekta egovernmentu. Mgr. Tomáš Kroupa Ing. Martin Tajtl Posuzování projektů odborem Hlavního architekta egovernmentu Mgr. Tomáš Kroupa Ing. Martin Tajtl Co posuzuje OHA? 1. ICT projekty spolufinancované z IROP Výzva č. 4 Aktivity vedoucí k úplnému elektronickému

Více

SPECIFICKÁ PRAVIDLA PRO ŽADATELE A PŘÍJEMCE

SPECIFICKÁ PRAVIDLA PRO ŽADATELE A PŘÍJEMCE INTEGROVANÝ REGIONÁLNÍ OPERAČNÍ PROGRAM SPECIFICKÁ PRAVIDLA PRO ŽADATELE A PŘÍJEMCE SPECIFICKÝ CÍL 3.2 PRŮBĚŽNÁ VÝZVA Č. 10 PŘÍLOHA Č. 4 PRAVIDLA PRO VYDÁNÍ STANOVISKA ODBORU HLAVNÍHO ARCHITEKTA EGOVERNMENTU

Více

Výčet strategií a cílů, na jejichž plnění se projektový okruh podílí:

Výčet strategií a cílů, na jejichž plnění se projektový okruh podílí: Karta projektového okruhu Číslo a název projektového okruhu: Garant karty projektového okruhu: Spolupracující subjekty: 3.1 Úplné elektronické podání Ministerstvo vnitra Správa základních registrů, OSS,

Více

SPECIFICKÁ PRAVIDLA PRO ŽADATELE A PŘÍJEMCE

SPECIFICKÁ PRAVIDLA PRO ŽADATELE A PŘÍJEMCE INTEGROVANÝ REGIONÁLNÍ OPERAČNÍ PROGRAM SPECIFICKÁ PRAVIDLA PRO ŽADATELE A PŘÍJEMCE SPECIFICKÝ CÍL 3.2 PRŮBĚŽNÁ VÝZVA Č. 4 PŘÍLOHA Č. 4 PRAVIDLA PRO VYDÁNÍ STANOVISKA ODBORU HLAVNÍHO ARCHITEKTA EGOVERNMENTU

Více

Základní registry, Datové schránky CzechPointy... A jak dál RNDr. Petr Tiller a Ing. Ondřej Felix, CSc., hlavní architekt egovernmentu MV ČR Praha

Základní registry, Datové schránky CzechPointy... A jak dál RNDr. Petr Tiller a Ing. Ondřej Felix, CSc., hlavní architekt egovernmentu MV ČR Praha Základní registry, Datové schránky CzechPointy... A jak dál RNDr. Petr Tiller a Ing. Ondřej Felix, CSc., hlavní architekt egovernmentu MV ČR Praha leden 2013 1 Pro připomenutí Aneb Co jsme si to postavili

Více

Základní registry nové generace MICHAL PEŠEK ŘEDITEL SPRÁVY ZÁKLADNÍCH REGISTRŮ

Základní registry nové generace MICHAL PEŠEK ŘEDITEL SPRÁVY ZÁKLADNÍCH REGISTRŮ Základní registry nové generace MICHAL PEŠEK ŘEDITEL SPRÁVY ZÁKLADNÍCH REGISTRŮ Historické okénko Před vznikem základních registrů: Každá pobočka úřadu si v rámci své agendy vedla svojí evidenci údajů,

Více

Kudy k Národnímu architektonickému plánu

Kudy k Národnímu architektonickému plánu 8.12.2014 Kudy k Národnímu architektonickému plánu (současný stav na základě výstupů projektu, jehož dodavatelem je sdružení E2020) Ondřej Felix, UHA MV Základní informace o projektu cíle, výstupy Část

Více

ISVS a sdílené služby v roce Petr Kuchař, hlavní architekt eg MV Michal Pešek, ředitel SZR

ISVS a sdílené služby v roce Petr Kuchař, hlavní architekt eg MV Michal Pešek, ředitel SZR ISVS a sdílené služby v roce 2017 Petr Kuchař, hlavní architekt eg MV Michal Pešek, ředitel SZR Schvalování projektů OHA UV 889 z 2. 11. 2015 - Strategie rozvoje ICT služeb a Základní zásady při čerpání

Více

Otevřená data veřejné správy z pohledu České republiky

Otevřená data veřejné správy z pohledu České republiky Otevřená data veřejné správy z pohledu České republiky Mgr. Tomáš Kroupa Ministerstvo vnitra - Samostatné oddělení hlavního architekta egovernmentu Agenda Proč to všechno děláme Co máme za sebou Co nás

Více

Metodický pokyn. Odbor Hlavního architekta egovernmentu MV. Praha, říjen 2016 verze 2.0

Metodický pokyn. Odbor Hlavního architekta egovernmentu MV. Praha, říjen 2016 verze 2.0 Metodický pokyn k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému nákupu typizovaných komoditních ICT produktů (HW, SW nebo služeb) typ C Odbor Hlavního architekta egovernmentu

Více

Metodický pokyn. k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ C

Metodický pokyn. k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ C Metodický pokyn k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ C Odbor Hlavního architekta egovernmentu MV Praha, leden 2019 verze 6.0.1 Toto dílo podléhá

Více

Garant karty projektového okruhu:

Garant karty projektového okruhu: Karta projektového okruhu Číslo a název projektového okruhu: Garant karty projektového okruhu: Spolupracující subjekty: 3.5 Elektronizace odvětví: eeducation Ministerstvo školství, mládeže a tělovýchovy

Více

Aneb kde jsme a kam jdeme. odbor Hlavního architekta egovernmentu Ondřej Felix Pavel Hrabě Tomáš Šedivec

Aneb kde jsme a kam jdeme. odbor Hlavního architekta egovernmentu Ondřej Felix Pavel Hrabě Tomáš Šedivec Aneb kde jsme a kam jdeme odbor Hlavního architekta egovernmentu Ondřej Felix Pavel Hrabě Tomáš Šedivec Agenda Představení NAP a architektury obecně Co to je?, pojmy, podrobnost, 4 vrstvá vize Současné

Více

Elektronická identifikace prostřednictvím národního bodu. Petr Kuchař, hlavní architekt eg, MV

Elektronická identifikace prostřednictvím národního bodu. Petr Kuchař, hlavní architekt eg, MV Elektronická identifikace prostřednictvím národního bodu Petr Kuchař, hlavní architekt eg, MV Teoretický úvod Elektronická identifikace, která je tématem mého vstupu, je relativně malá, nicméně životně

Více

Aneb kde jsme a kam jdeme. odbor Hlavního architekta egovernmentu Ondřej Felix Pavel Hrabě Tomáš Šedivec

Aneb kde jsme a kam jdeme. odbor Hlavního architekta egovernmentu Ondřej Felix Pavel Hrabě Tomáš Šedivec Aneb kde jsme a kam jdeme odbor Hlavního architekta egovernmentu Ondřej Felix Pavel Hrabě Tomáš Šedivec Agenda Představení NAP a architektury obecně Co to je?, pojmy, podrobnost, 4 vrstvá vize Současné

Více

Základní změny v architektuře e-governmentu ČR. Ondřej Felix hlavní architekt e-governmentu MV ČR ISSS, duben 2009

Základní změny v architektuře e-governmentu ČR. Ondřej Felix hlavní architekt e-governmentu MV ČR ISSS, duben 2009 Základní změny v architektuře e-governmentu ČR Ondřej Felix hlavní architekt e-governmentu MV ČR ISSS, duben 2009 Současný stav v oblasti dat veřejné správy roztříštěnost, nejednotnost a multiplicity ve

Více

Výzvy pro čerpání prostředků ze strukturálních fondů

Výzvy pro čerpání prostředků ze strukturálních fondů Výzvy pro čerpání prostředků ze strukturálních fondů Ministerstvo vnitra Odbor strukturálních fondů Ing. Radka Soukupová 7.4.2009 Ministerstvo vnitra ČR tzv. zprostředkující subjekt pro Integrovaný operační

Více

Vydávání stanovisek k ICT projektům dle usnesení vlády č. 889 z

Vydávání stanovisek k ICT projektům dle usnesení vlády č. 889 z Vydávání stanovisek k ICT projektům dle usnesení vlády č. 889 z 2.11.2015 zasedání RVIS, 11.12.2015 Petr Kuchař ředitel odboru Odbor hlavního architekta egov MV ČR Obsah prezentace Úvod do problematiky

Více

Centrální místo služeb (CMS) Bezpečná komunikace mezi úřady

Centrální místo služeb (CMS) Bezpečná komunikace mezi úřady Centrální místo služeb (CMS) Bezpečná komunikace mezi úřady Metodická doporučení odboru Hlavního architekta egovernmentu Ministerstva vnitra pro státní správu a samosprávu o přístupu k informačním systémům

Více

Výčet strategií a cílů, na jejichž plnění se projektový okruh podílí: Strategický rámec rozvoje veřejné správy České republiky pro období

Výčet strategií a cílů, na jejichž plnění se projektový okruh podílí: Strategický rámec rozvoje veřejné správy České republiky pro období Karta projektového okruhu Číslo a název projektového okruhu: Garant karty projektového okruhu: Spolupracující subjekty: 6.3 Sdílitelné služby technologické infrastruktury Ministerstvo vnitra, Ministerstvo

Více

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Příloha č. 3 k č.j. MV-159754-3/VZ-2013 Počet listů: 7 TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Nové funkcionality Czech POINT 2012 Popis rozhraní egon Service Bus Centrální Místo Služeb 2.0 (dále jen CMS

Více

TECHNICKÁ SPECIFIKACE PŘEDMĚTU VEŘEJNÉ ZAKÁZKY

TECHNICKÁ SPECIFIKACE PŘEDMĚTU VEŘEJNÉ ZAKÁZKY TECHNICKÁ SPECIFIKACE PŘEDMĚTU VEŘEJNÉ ZAKÁZKY Příloha č. 1 Zajištění funkcionality "Internetové kontaktní místo veřejné správy Czech POINT" 1. Obecná informace Projekt Czech POINT (dále i CzP) v současné

Více

Posuzování státních IT projektů cíle a zkušenosti

Posuzování státních IT projektů cíle a zkušenosti Posuzování státních IT projektů cíle a zkušenosti Ing. Martin Tajtl Ing. Tomáš Šedivec Mgr. Radim Karásek Ministerstvo vnitra ČR odbor Hlavního architekta egovernmentu Co posuzuje OHA? 1. Záměry státní

Více

SPRÁVA ZÁKLADNÍCH REGISTRŮ ČESKÉ REPUBLIKY. Základní registry a eidas

SPRÁVA ZÁKLADNÍCH REGISTRŮ ČESKÉ REPUBLIKY. Základní registry a eidas ČESKÉ REPUBLIKY Základní registry a eidas Praha, 9. 5. 2017 ROB ROS RPP RÚIAN Informační systém základních registrů Služby základních registrů ORG Změny na základě novelizace zákona 111/2009 Skartační

Více

Výčet strategií a cílů, na jejichž plnění se projektový okruh podílí:

Výčet strategií a cílů, na jejichž plnění se projektový okruh podílí: Karta projektového okruhu Číslo a název projektového okruhu: Garant karty projektového okruhu: Spolupracující subjekty: 9. Elektronizace podpůrných procesů Ministerstvo vnitra, Ministerstvo financí Správa

Více

Koncepce rozvoje ICT ve státní a veřejné správě. Koncepce rozvoje ICT ve státní a veřejné správě (materiál pro jednání tripartity)

Koncepce rozvoje ICT ve státní a veřejné správě. Koncepce rozvoje ICT ve státní a veřejné správě (materiál pro jednání tripartity) Koncepce rozvoje ICT ve státní a veřejné správě (materiál pro jednání tripartity) Praha Listopad 2014 OBSAH 2. Rekapitulace stávajícího stavu a jeho nedostatků... 2 3. Cíle v oblasti ICT a navrhovaná opatření

Více

Sdílené služby českého egovernmentu. Ing. Ondřej Felix CSc Hlavní architekt egovernmentu MVČR

Sdílené služby českého egovernmentu. Ing. Ondřej Felix CSc Hlavní architekt egovernmentu MVČR Sdílené služby českého egovernmentu Ing. Ondřej Felix CSc Hlavní architekt egovernmentu MVČR Praha, 25. září 2014 Zákon 365/2000 Sb. Informační systémy veřejné správy Regulace izolovaných informačních

Více

Metodický pokyn. k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ B1

Metodický pokyn. k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ B1 Metodický pokyn k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ B1 Odbor Hlavního architekta egovernmentu MV Praha, září 2018 verze 6.0 Toto dílo podléhá

Více

Základní registry (kde jsme, kam směřujeme a jak to na sebe navazuje) ing. Ondřej Felix CSc. hlavní architekt egovernmentu MV ČR

Základní registry (kde jsme, kam směřujeme a jak to na sebe navazuje) ing. Ondřej Felix CSc. hlavní architekt egovernmentu MV ČR Základní registry (kde jsme, kam směřujeme a jak to na sebe navazuje) ing. Ondřej Felix CSc. hlavní architekt egovernmentu MV ČR Smysl a účel základních registrů Poskytovat bezpečně vybrané právně závazné

Více

Dopady spuštění základních registrů na subjekty územní samosprávy

Dopady spuštění základních registrů na subjekty územní samosprávy Dopady spuštění základních registrů na subjekty územní samosprávy Příloha č. 7 Nezodpovězené dotazy a seznam doporučení Vydavatel: Ministerstvo vnitra ČR, ve spolupráci s kraji Zpracovatel: CORTIS Consulting

Více

Využití sdílených služeb Jednotného identitního prostoru (JIP) a Katalogu autentizačních a autorizačních služeb (KAAS)

Využití sdílených služeb Jednotného identitního prostoru (JIP) a Katalogu autentizačních a autorizačních služeb (KAAS) Využití sdílených služeb Jednotného identitního prostoru (JIP) a Katalogu autentizačních a autorizačních služeb (KAAS) Ing. Aleš Kučera Zástupce správce Centrály Czech POINT Sdílené služby egovernmentu

Více

Informace o aktuálním dění v oblasti otevřených dat v České republice

Informace o aktuálním dění v oblasti otevřených dat v České republice Informace o aktuálním dění v oblasti otevřených dat v České republice Ministerstvo vnitra - odbor Hlavního architekta egovernmentu Rady vlády pro informační společnost (RVIS), 10.6. 2016 Osnova 1. Definice

Více

Kmenové projekty egov a Úplné elektronické podání. Ing. Ondřej Felix CSc Hlavní architekt egovernmentu MV ČR

Kmenové projekty egov a Úplné elektronické podání. Ing. Ondřej Felix CSc Hlavní architekt egovernmentu MV ČR Kmenové projekty egov a Úplné elektronické podání Ing. Ondřej Felix CSc Hlavní architekt egovernmentu MV ČR Agenda Cíle na rok 2020 Co ještě chybí z kmenových projektů egov Propojený datový fond Propojená

Více

Budoucnost ICT Veřejné správy. Petr Kuchař, Hlavní architekt egovernmentu, ředitel OHA MV

Budoucnost ICT Veřejné správy. Petr Kuchař, Hlavní architekt egovernmentu, ředitel OHA MV Budoucnost ICT Veřejné správy Petr Kuchař, Hlavní architekt egovernmentu, ředitel OHA MV Útvar Hlavního architekta MV, role reprezentován odborem HA egovernmentu na MV Koordinační role při zavádění sdílených

Více

Sdílené služby ve veřejné správě ČR. Ondřej Felix Hlavní architekt egovermentučr Petr Tiller

Sdílené služby ve veřejné správě ČR. Ondřej Felix Hlavní architekt egovermentučr Petr Tiller Sdílené služby ve veřejné správě ČR Ondřej Felix Hlavní architekt egovermentučr Petr Tiller Strategie egon 2007-2013 Efektivní veřejná správa a přátelské veřejné služby 2007 Pentagon Strategie rozvoje

Více

Informace o aktuálním dění v oblasti otevřených dat v ČR

Informace o aktuálním dění v oblasti otevřených dat v ČR Informace o aktuálním dění v oblasti otevřených dat v ČR Ministerstvo vnitra - odbor Hlavního architekta egovernmentu Rady vlády pro informační společnost (RVIS), 10.6. 2016 Osnova 1. Definice otevřených

Více

SPRÁVA ZÁKLADNÍCH REGISTRŮ ČESKÉ REPUBLIKY. Základní registry a eidas

SPRÁVA ZÁKLADNÍCH REGISTRŮ ČESKÉ REPUBLIKY. Základní registry a eidas ČESKÉ REPUBLIKY Základní registry a eidas Mikulov, 6. 9. 2016 Základní registry základ propojeného datového fondu Mikulov 4. září 2012 20 000 000 transakcí Celkem připojeno 1 159 AIS 15. Ledna 2013 100

Více

Formulář žádosti. o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ A. Odbor Hlavního architekta egovernmentu MV

Formulář žádosti. o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ A. Odbor Hlavního architekta egovernmentu MV Formulář žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ A Odbor Hlavního architekta egovernmentu MV Praha, říjen 2016 verze 5.0 Obsah 1. Základní podmínky projektu...

Více

Strategický dokument se v současné době tvoří.

Strategický dokument se v současné době tvoří. Karta projektového okruhu Číslo a název projektového okruhu: Garant karty projektového okruhu: Spolupracující subjekty: 3.9 Elektronizace odvětví: ejustice Ministerstvo spravedlnosti Ministerstvo vnitra

Více

Jednotný identitní prostor Provozní dokumentace

Jednotný identitní prostor Provozní dokumentace Jednotný identitní prostor Provozní dokumentace Vytvořeno dne: 21. 2. 2012 Aktualizováno: 23. 5. 2017 Verze: 1.2 2017 MVČR Obsah 1. Úvod... 3 1.1. Účel provozní dokumentace... 3 1.2. Související dokumenty...

Více

Digitální technická mapa ČR

Digitální technická mapa ČR Digitální technická mapa ČR Architektura ISSS 2019 Strategická východiska Informační koncepce České republiky, Koncepce budování egovernmentu v ČR 2018+ https://www.mvcr.cz/soubor/vladni-program-digitalizaceceske-republiky-2018-digitalni-cesko-informacni-koncepcecr.aspx

Více

Otevřená data. Shrnutí. Když stavím nový IS nebo upravuji existující, co musím udělat, abych byl Open Data Ready? Prosinec 2018

Otevřená data. Shrnutí. Když stavím nový IS nebo upravuji existující, co musím udělat, abych byl Open Data Ready? Prosinec 2018 Otevřená data Když stavím nový IS nebo upravuji existující, co musím udělat, abych byl Open Data Ready? Prosinec 2018 Schválil: Ing. Petr Kuchař, ředitel odboru Hlavního architekta egovernmentu, MVČR Shrnutí

Více

Co jsme si to postavili aneb Sdílené služby ve veřejné správě ČR. Ondřej Felix Hlavní architekt egovernmentu ČR

Co jsme si to postavili aneb Sdílené služby ve veřejné správě ČR. Ondřej Felix Hlavní architekt egovernmentu ČR Co jsme si to postavili aneb Sdílené služby ve veřejné správě ČR Ondřej Felix Hlavní architekt egovernmentu ČR Strategie egon 2007 2013 Efektivní veřejná správa a přátelské veřejné služby 2007 Pentagon

Více

Schůzka informatiků MČ HMP. Datové schránky

Schůzka informatiků MČ HMP. Datové schránky Schůzka informatiků MČ HMP Datové schránky 7.5.2009 Aktuality 6.5.2009 Novela zákona o archivnictví a spisové službě Ve středu 6.5.2009 schválila Poslanecká sněmovna Parlamentu ČR novelu zákona č. 300/2008

Více

Sdílené služby egov ČR 2016 a CMS 2.0. Ondřej Felix MV ČR Telč 2016

Sdílené služby egov ČR 2016 a CMS 2.0. Ondřej Felix MV ČR Telč 2016 Sdílené služby egov ČR 2016 a CMS 2.0 Ondřej Felix MV ČR Telč 2016 Proč sdílené služby egov Proč pro efektivní výkon veřejné správy potřebujeme bezpečné, transparentní a logicky centralizované aplikační

Více

AKTIVITY VEDOUCÍ K ÚPLNÉMU ELEKTRONICKÉMU PODÁNÍ. Přehled změn k 22. červenci Položka Popis změny Zdůvodnění změny

AKTIVITY VEDOUCÍ K ÚPLNÉMU ELEKTRONICKÉMU PODÁNÍ. Přehled změn k 22. červenci Položka Popis změny Zdůvodnění změny Ministerstvo pro místní rozvoj České republiky oznamuje změny ve 4. výzvě k předkládání žádostí o podporu z Integrovaného regionálního operačního programu AKTIVITY VEDOUCÍ K ÚPLNÉMU ELEKTRONICKÉMU PODÁNÍ

Více

Vydávání stanovisek k ICT projektům dle usnesení vlády č. 889 z

Vydávání stanovisek k ICT projektům dle usnesení vlády č. 889 z Vydávání stanovisek k ICT projektům dle usnesení vlády č. 889 z 2.11.2015 část 2: Motivace k architektuře úřadů OHA, 24.3.2016 Ing. Pavel Hrabě, PhD. Externí poradce Odbor hlavního architekta egov MV ČR

Více

Zkušenosti s budováním základního registru obyvatel

Zkušenosti s budováním základního registru obyvatel Zkušenosti s budováním základního registru obyvatel Jiří Dohnal, ICZ a.s. ISSS 2012 1 ROB - EDITOŘI Primární: evidence obyvatel (IS EO), cizinecký informační systém (CIS) UFO v rámci CIS? Potřeba pro:

Více

Několik poznámek ke koncepci ICT v hlavním městě Praze

Několik poznámek ke koncepci ICT v hlavním městě Praze Několik poznámek ke koncepci ICT v hlavním městě Praze Ondřej Felix Digitální šampion ČR předseda ICT komise MHMP hlavní architekt ZR člen Rady vlády pro informační společnost 18.12.2014 ICT v Praze v

Více

Využití služeb egovernmentu poskytovateli zdravotních služeb

Využití služeb egovernmentu poskytovateli zdravotních služeb Využití služeb egovernmentu poskytovateli zdravotních služeb Národní identitní prostor ČR, Portál občana, eop, ztotožnění FO Tomáš Šedivec odbor Hlavního architekta egovernmentu Ministerstvo Vnitra ČR

Více

Základní registry veřejné správy. Ing.Ondřej Felix, CSc., hlavní architekt egovernmentu MV ČR

Základní registry veřejné správy. Ing.Ondřej Felix, CSc., hlavní architekt egovernmentu MV ČR Základní registry veřejné správy Ing.Ondřej Felix, CSc., hlavní architekt egovernmentu MV ČR Současný stav v oblasti dat veřejné správy Roztříštěnost, nejednotnost a multiplicity ve vedení klíčových databází

Více

Úplné elektronické podání. Mgr. Bohdan Urban

Úplné elektronické podání. Mgr. Bohdan Urban Úplné elektronické podání Mgr. Bohdan Urban Agenda Cíle na rok 2020 Úplné elektronické podání a navazující procesy Současný stav Jak chápeme úplné elektronické podání Od podání k úplnému elektronickému

Více

Základní registry ČR

Základní registry ČR Základní registry ČR RNDr. Petr Tiller Igos Consulting a.s. Projekt Informační systém základních registrů (registrační číslo: CZ.1.06/1.1.00/03.05891) byl spolufinancován z prostředků Evropské unie, Evropského

Více

Národní architektonický plán a ostatní metody řízení veřejné správy ČR

Národní architektonický plán a ostatní metody řízení veřejné správy ČR Národní architektonický plán a ostatní metody řízení veřejné správy ČR Ing. Pavel Hrabě, Ph.D. externí konzultant a metodik Odbor hlavního architekta egov Ministerstvo vnitra ČR Stručně Motto: Pokud nevíte,

Více

Role MV v oblasti egovernmentu v programovém období 2014-2020

Role MV v oblasti egovernmentu v programovém období 2014-2020 Role MV v oblasti egovernmentu v programovém období 2014-2020 Konference e-government 20:10 Mikulov, 8. 9. 9. 2015 Mgr. Jiří Zmatlík náměstek ministra vnitra pro řízení sekce ekonomiky, strategií a evropských

Více

Cílem je sjednocení různých informačních systémů veřejné správy do jednotného systému ISZR

Cílem je sjednocení různých informačních systémů veřejné správy do jednotného systému ISZR Ing. Karel Hanke Veřejná správa disponuje množstvím různých informačních systémů které nejsou online propojeny Cílem je sjednocení různých informačních systémů veřejné správy do jednotného systému ISZR

Více

egovernment 2009 Ing. Pavel Tykal

egovernment 2009 Ing. Pavel Tykal egovernment 2009 Ing. Pavel Tykal MV ČR Základní strategický rámec Smart Administration i ti V roce 2007 schválena strategie Smart Administration na období 2007-2015 Motto je : efektivní veřejná správa

Více

Aktuální výzvy a novinky v oblasti otevřených dat v České republice

Aktuální výzvy a novinky v oblasti otevřených dat v České republice Aktuální výzvy a novinky v oblasti otevřených dat v České republice Michal Kubáň Národní koordinátor otevřených dat Odbor hlavního architekta egovernmentu (MV ČR) Open Data Expo, 7. 3. 2017 Zakotvení otevřených

Více

Základní registry (ISSS, duben 2012) ing. Ondřej Felix CSc. hlavní architekt egovernmentu MV ČR

Základní registry (ISSS, duben 2012) ing. Ondřej Felix CSc. hlavní architekt egovernmentu MV ČR Základní registry (ISSS, duben 2012) ing. Ondřej Felix CSc. hlavní architekt egovernmentu MV ČR Smysl a účel základních registrů Poskytovat bezpečně vybrané právně závazné referenční údaje o definovaných

Více

Český egovernment 2015+

Český egovernment 2015+ Český egovernment 2015+ Praha, 26.5.2016 JUDr. Jaroslav Strouhal Náměstek ministra vnitra pro řízení sekce IKT Strategie STRATEGIE A IMPLEMENTAČNÍ PLÁN SLUŽEB VS A EGOVERNMENTU Strategický rámec rozvoje

Více

Metodický pokyn k uvedení registru do produkčního provozu

Metodický pokyn k uvedení registru do produkčního provozu Metodický pokyn k uvedení registru do produkčního provozu dokumentace Národního registru hrazených zdravotních služeb (NRHZS) autoři: Černek J., Blaha M. verze: 1.0 datum: 15. 1. 2018 Dokument je vytvořen

Více

Technická dokumentace

Technická dokumentace Příloha č. 1 výzvy k podání nabídky na veřejnou zakázku malého rozsahu s názvem On-line vyjádření k existenci sítí" Technická dokumentace 1/5 Úvod Tento dokument je nedílnou součástí zadávacích podmínek

Více

1. Integrační koncept

1. Integrační koncept Příloha č. 2: Technický popis integrace 1. Integrační koncept Z hlediska koncepčního budování Smart Administration na Magistrátu města Mostu je možno hovořit o potřebě integrace tří úrovní systémové architektury

Více

JAK ČÍST ZÁZNAM O VYUŽÍVÁNÍ ÚDAJŮ V REGISTRU OBYVATEL

JAK ČÍST ZÁZNAM O VYUŽÍVÁNÍ ÚDAJŮ V REGISTRU OBYVATEL JAK ČÍST ZÁZNAM O VYUŽÍVÁNÍ ÚDAJŮ V REGISTRU OBYVATEL Název dokumentu: Jak číst záznam o využívání údajů v registru obyvatel Verze: 1.8 Autor: Správa základních registrů Datum aktualizace: 25. 2. 2014

Více

Outsourcing v podmínkách Statutárního města Ostravy

Outsourcing v podmínkách Statutárního města Ostravy Outsourcing v podmínkách Statutárního města Ostravy Říjen 2009 Ing. Stanislav Richtar Ředitel společnosti 1 OBSAH PREZENTACE 1. Outsourcing - obecně 2. Výchozí stav projektu 3. Model poskytovaných služeb

Více

JAK SE TAM DOSTANEME?

JAK SE TAM DOSTANEME? egovernment na MV Kam putujeme a jak to uděláme? Mgr. Jiří Kárník vedoucí oddělení procesního řízení a standardizace agend veřejné správy Odbor egovernmentu Ministerstvo vnitra ČR Tel.: 974 816 623 e-mail:

Více

Otevřená data ve veřejné správě ČR Tomáš Kroupa, Ministerstvo vnitra - Odbor Hlavního architekta egovernmentu

Otevřená data ve veřejné správě ČR Tomáš Kroupa, Ministerstvo vnitra - Odbor Hlavního architekta egovernmentu Otevřená data ve veřejné správě ČR 13.11.2015 Tomáš Kroupa, Ministerstvo vnitra - Odbor Hlavního architekta egovernmentu Zhodnocení vývoje v oblasti otevřených dat v ČR Rok 2015 je zatím nejvýznačnějším

Více

Czech POINT Quality&Security24 11.března 2008 Kongresové centrum Praha

Czech POINT Quality&Security24 11.března 2008 Kongresové centrum Praha Czech POINT Quality&Security24 11.března 2008 Kongresové centrum Praha Ing. Jan Ladin Pověřen řízením ORP KIVS Odbor rozvoje a provozu Komunikační infrastruktury veřejné správy Ministerstvo vnitra ČR jan.ladin@mvcr.cz

Více

egovernment Online Service Bus

egovernment Online Service Bus egovernment Online Service Bus Metodická doporučení odboru Hlavního architekta egovernmentu Ministerstvo vnitra pro státní správu a samosprávu ohledně egoverment online Service Bus (dále jen egsb). Autor:

Více

TECHNOLOGICKÁ CENTRA A ELEKTRONICKÉ SPISOVÉ SLUŽBY V ÚZEMÍ Verze příručky 1.0

TECHNOLOGICKÁ CENTRA A ELEKTRONICKÉ SPISOVÉ SLUŽBY V ÚZEMÍ Verze příručky 1.0 Příručka pro žadatele a příjemce finanční podpory v rámci Integrovaného operačního programu pro prioritní osu 2, oblast intervence 2.1 Výzva číslo 04 kontinuální TECHNOLOGICKÁ CENTRA A ELEKTRONICKÉ SPISOVÉ

Více

Project:Úplné elektronické podání

Project:Úplné elektronické podání Project:Úplné elektronické podání Den publikace: 23 Lis 2016 Verze 1.0 Atributy modelu: Obsah 0 Celkovy prehled 1 Vyber, identifikace, autentizace 2 Priprava podani 3 Podani, ukon 4 Ulozeni a potvrzeni

Více

Využívání prvků procesního řízení a zavedení standardů pro výkon prioritních agend veřejné správy

Využívání prvků procesního řízení a zavedení standardů pro výkon prioritních agend veřejné správy Využívání prvků procesního řízení a zavedení standardů pro výkon prioritních agend veřejné správy Mgr. Jiří Kárník Koordinátor projektů vedoucí oddělení procesního řízení a standardizace agend veřejné

Více

Strategie, architektury a projekty jako nástroj řízení IT ve veřejné správě

Strategie, architektury a projekty jako nástroj řízení IT ve veřejné správě Strategie, architektury a projekty jako nástroj řízení IT ve veřejné správě Tomáš Hrabík ICZ a.s. Konference Řízení informatiky v soukromém a veřejném sektoru 1 Otázky 1. Je egovernment o elektronizaci

Více

Základy Informační koncepce ČR. Pavel Hrabě a kolektiv OHA Říjen 2017

Základy Informační koncepce ČR. Pavel Hrabě a kolektiv OHA Říjen 2017 Základy Informační koncepce ČR Pavel Hrabě a kolektiv OHA Říjen 2017 Základní myšlenky IK ČR Zavede pojmy Národní architektonický plán (NAP) modely cílového stavu shora a zdola Národní architektonický

Více

ondrej.menousek@mvcr.cz

ondrej.menousek@mvcr.cz Návrh výzkumné potřeby státní správy pro zadání veřejné zakázky A. Předkladatel garant výzkumné potřeby Název organizace Ministerstvo vnitra Adresa Milady Horákové 133/ Kontaktní osoba Ing. Jaroslav Scheuba

Více

Otevřená a propojitelná data ve veřejné správě Národní katalog otevřených dat

Otevřená a propojitelná data ve veřejné správě Národní katalog otevřených dat Otevřená a propojitelná data ve veřejné správě Národní katalog otevřených dat Dušan Chlapek, Fakulta informatiky a statistiky Vysoká škola ekonomická v Praze, Tomáš Kroupa, Ministerstvo vnitra - Odbor

Více

Když se řekne NAP a Informační koncepce ( z pohledu správce ISVS ) Ondřej Felix Říjen 2017

Když se řekne NAP a Informační koncepce ( z pohledu správce ISVS ) Ondřej Felix Říjen 2017 Když se řekne NAP a Informační koncepce ( z pohledu správce ISVS ) Ondřej Felix Říjen 2017 Trocha základů Čl. 2 Ústavy (1) Lid je zdrojem veškeré státní moci; vykonává ji prostřednictvím orgánů moci zákonodárné,

Více

Příloha č. 3 zadávací dokumentace

Příloha č. 3 zadávací dokumentace Příloha č. 3 zadávací dokumentace 1. Stávající stav 1.1. Východiska pro systém základních registrů Současný systém veřejné správy vychází a bude i nadále založen na principech hierarchického modelu v podobě,

Více

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Č.j.: 3/12/51924/Moos PŘÍKAZ REKTORA č. 1/2012 Pravidla pro kompetence a odpovědnosti při správě informačního systému ČVUT Pravidla pro kompetence a odpovědnosti při

Více

Otevřená data ve veřejné správě 8.9.2015, Mikulov. Tomáš Kroupa, Ministerstvo vnitra - Odbor hlavního architekta egovernmentu

Otevřená data ve veřejné správě 8.9.2015, Mikulov. Tomáš Kroupa, Ministerstvo vnitra - Odbor hlavního architekta egovernmentu Otevřená data ve veřejné správě 8.9.2015, Mikulov Tomáš Kroupa, Ministerstvo vnitra - Odbor hlavního architekta egovernmentu Zhodnocení vývoje v oblasti otevřených dat v ČR Rok 2015 je zatím nejvýznačnějším

Více

GIS Libereckého kraje

GIS Libereckého kraje Funkční rámec Zpracoval: Odbor informatiky květen 2004 Obsah 1. ÚVOD...3 1.1. Vztah GIS a IS... 3 2. ANALÝZA SOUČASNÉHO STAVU...3 2.1. Technické zázemí... 3 2.2. Personální zázemí... 3 2.3. Datová základna...

Více

Výzva k podání nabídek na veřejnou zakázku malého rozsahu na dodávky

Výzva k podání nabídek na veřejnou zakázku malého rozsahu na dodávky Město Šumperk Městský úřad Šumperk nám. Míru 1, 787 01 Šumperk Naše čj.: MUSP 125946/2017 Naše sp. zn.: 125945/2017 TAJ/PAKO *MUSPX01TUVGN * Výzva k podání nabídek na veřejnou zakázku malého rozsahu na

Více

Digitální mapa veřejné správy v kontextu nové politiky státu v oblasti prostorových dat

Digitální mapa veřejné správy v kontextu nové politiky státu v oblasti prostorových dat Digitální mapa veřejné správy v kontextu nové politiky státu v oblasti prostorových dat Jednání Grémia pro regulační reformu a efektivní veřejnou správu 9. prosince 2009 Obsah - Z čeho vycházíme - Význam

Více

PŘÍNOSY A DOPADY ZAHÁJENÍ PROVOZU ROS

PŘÍNOSY A DOPADY ZAHÁJENÍ PROVOZU ROS PŘÍNOSY A DOPADY ZAHÁJENÍ PROVOZU ROS Konference ISSS Hradec Králové 2012 Ing. Stanislav Palas, Český statistický úřad stanislav.palas@ 1/X OBSAH PREZENTACE Přínosy ROS Dopady ROS Na OVM Na podnikatelskou

Více

Komenského náměstí 440/2, 767 01 Kroměříž Příspěvková organizace. reditel@zskomenskeho.cz

Komenského náměstí 440/2, 767 01 Kroměříž Příspěvková organizace. reditel@zskomenskeho.cz Základní škola, Kroměříž, Komenského náměstí 440, příspěvková organizace se sídlem Komenského náměstí 440/2, 767 01 Kroměříž jako zadavatel vyhlašuje v souladu s Příručkou pro příjemce Operačního programu

Více

Co děláme pro lepší egovernment

Co děláme pro lepší egovernment Co děláme pro lepší egovernment Legislativa bez ní to nepůjde Klíčové kroky v legislativním prostoru: - Novela zákona o základních registrech - Zákon o službách vytvářejících důvěru pro elektronické transakce

Více

SPECIFICKÁ PRAVIDLA PRO ŽADATELE A PŘÍJEMCE

SPECIFICKÁ PRAVIDLA PRO ŽADATELE A PŘÍJEMCE INTEGROVANÝ REGIONÁLNÍ OPERAČNÍ PROGRAM SPECIFICKÁ PRAVIDLA PRO ŽADATELE A PŘÍJEMCE SPECIFICKÝ CÍL 3.2 PRŮBĚŽNÁ VÝZVA Č. 4 PŘÍLOHA Č. 2 OSNOVA STUDIE PROVEDITELNOSTI PLATNOST OD 17. 9. 2015 Strana 1 z

Více

AISC. kladní registr obyvatel. Jiří Valter ICZ a. s. www.i.cz 1

AISC. kladní registr obyvatel. Jiří Valter ICZ a. s. www.i.cz 1 AISC agendový informační systém pro základnz kladní registr obyvatel Jiří Valter ICZ a. s. 1 Východiska Zákon o základních registrech (111/2009 Sb.) definuje, že editorem referenčních údajů je Policie

Více

Postup při zápisu údajů do AIS EO soudy prvního stupně

Postup při zápisu údajů do AIS EO soudy prvního stupně Postup při zápisu údajů do AIS EO soudy prvního stupně Zápis zákazu pobytu prostřednictvím formulářů CzechPOINT verze 1.00 Zpracoval: odbor správních činností 1 Zápis údajů do agendového informačního systému

Více

1.4 Pro bezproblémové používaní systému JOSEPHINE je nutné používat internetový prohlížeč Microsoft Internet Explorer verze 11.0 a vyšší.

1.4 Pro bezproblémové používaní systému JOSEPHINE je nutné používat internetový prohlížeč Microsoft Internet Explorer verze 11.0 a vyšší. Příloha č. 1 zadávací dokumentace Požadavky na elektronickou komunikaci 1. Komunikace mezi zadavatelem a účastníky 1.1 Podávání předběžné nabídky, nabídky, podávání žádosti o vysvětlení zadávací dokumentace,

Více

Michal Kolařík 18.1.2012. ISZR - Brána k základním registrům

Michal Kolařík 18.1.2012. ISZR - Brána k základním registrům Michal Kolařík 18.1.2012 ISZR - Brána k základním registrům Informační systém základních registrů Informační systém základních registrů Registrační číslo: CZ.1.06/1.1.00/03.05891 Projekt Informační systém

Více

Specifické informační a komunikační systémy a infrastruktura II.

Specifické informační a komunikační systémy a infrastruktura II. Ministerstvo pro místní rozvoj České republiky oznamuje změny ve 28. výzvě k předkládání žádostí o podporu z Integrovaného regionálního operačního programu Specifické informační a komunikační systémy a

Více

Přístup k řízení GIS jako součásti Enterprise Architecture

Přístup k řízení GIS jako součásti Enterprise Architecture Přístup k řízení GIS jako součásti Enterprise Architecture Tomáš Hrabík, ICZ a. s. Konference Internet ve státní správě a samosprávě 5.4.2016 ALDIS, Hradec Králové Motivace Stupňující se požadavky na standardizaci

Více

OSTRÝ PROVOZ ZÁKLADNÍCH REGISTRŮ ZÁKON A KOMERČNÍ SFÉRA

OSTRÝ PROVOZ ZÁKLADNÍCH REGISTRŮ ZÁKON A KOMERČNÍ SFÉRA OSTRÝ PROVOZ ZÁKLADNÍCH REGISTRŮ ZÁKON A KOMERČNÍ SFÉRA SMART WORLD 2012 Mikulov 4.10. 2012. Ing. Michal PEŠEK Správa základních registrů 1. července jsme startovali registry a bagry.. Česká dálnice egov

Více

2. Základní škola Holešov, Smetanovy sady 625, příspěvková organizace

2. Základní škola Holešov, Smetanovy sady 625, příspěvková organizace 2. Základní škola Holešov, Smetanovy sady 625, příspěvková organizace se sídlem Smetanovy sady 625, 769 01 Holešov jako zadavatel vyhlašuje v souladu s Příručkou pro příjemce Operačního programu Vzdělávání

Více

Stav řešení Enterprise Architektury na Moravskoslezském kraji

Stav řešení Enterprise Architektury na Moravskoslezském kraji Stav řešení Enterprise Architektury na Moravskoslezském kraji Zpracoval(a): Ing. Tomáš Vašica Datum: 23. 9. 2015 Obsah prezentace 1. Představení projektového záměru 2. Co očekává Moravskoslezský kraj od

Více