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

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 B2"

Transkript

1 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á 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 Právní klasifikace předmětu projektu Architektonické informace o projektu 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) Finanční připravenost projektu Metodická připravenost projektu Ekonomické parametry projektu Hodnota výdajů a ekonomická náročnost projektu Analýza rizik 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 Tento zkrácený vzor žádosti byl připraven pro použití v případech záměru realizace dílčí změny řešení, v souladu se závazkem z dříve schváleného formuláře žádosti typu B1, pokud má změna dopad do architektury řešení a jeho shody s architekturou egovernmentu nebo jde o úpravu řešení, která má dopad do jeho architektury nebo jehož pracnost přesáhne 100 člověkodní (v souhrnu interních a externích) či výdaj přesáhne 1 mil. Kč. 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. 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ě. Hlavní předmět projektu - předmětem by vždy mělo být vytvoření (zprovoznění) zcela nové, nebo zvýšení kvality / změna parametrů (hospodárnost, bezpečnost, rychlost odezvy, apod.) již 1 4

5 existující ICT služby. Předmět realizovaný či změněný projektem stručně rozepište tak, aby cílové parametry výstupů projektu byly v souladu s příčinami uvedenými v tabulce 4 v částech Popis projektu (tzv. To-Be) a Důvod. Aby byla zajištěna objektivní vyhodnotitelnost výstupů projektu, měl by každý projekt obsahovat: konkrétní specifikace jednotlivých výstupů (efektů) optimálně ve formě kritérií shodně využitelných pro vyhodnocení možných alternativ řešení i dosažení požadovaných parametrů cílového stavu, způsob objektivního měření splnění požadovaných výstupů. Již ze specifikace cíle/ů projektu musí být jasné, co bude na konci projektu (tj. při akceptaci), vyhodnocováno, tj. např. zvýšení hospodárnosti provozu, bezpečnost, atp. Technologie i organizační opatření vždy byly, jsou a zůstanou jen nástrojem pro dosažení tohoto cíle, tzn. jejich pořízení samo o sobě, by jako cíl být deklarováno nemělo. Specifikovat jako určující indikátory počty nově pořízeného majetku lze pouze u projektů, jejichž cílem je pouhé prodloužení životního cyklu služby, tzn. v případě prosté obnovy komponent infrastruktury. Termín plánovaného zahájení realizace projektu (zahájení výstavby, je-li součástí) předpokládané datum zahájení realizačních prací na projektu. Jedná se o zahájení vývojářských, implementačních nebo obdobných prací předcházejících ostrému provozu. Neuvádějte datum výběrového řízení, ale až datum podpisu či začátku účinnosti smlouvy. Pokud projekt nezahrnuje realizační fázi, ale jedná se např. o využívání aplikačního nástroje jako služby, pak tento údaj nevyplňujte. Termín plánovaného dokončení realizace projektu (uvedení do ostrého provozu) předpokládané datum dokončení realizačních prací na projektu včetně testování. Jedná se o datum předání posledních výstupů projektu do ostrého nebo pilotního provozu. Termín plánovaného zahájení provozu (spuštění ostrého provozu) předpokládané datum zahájení ostrého provozu výstupů projektu. Jedná se o datum předání prvních výstupů projektu do ostrého nebo pilotního provozu. Termín plánovaného ukončení provozu (konec smluvního vztahu s dodavatelem) předpokládané datum ukončení smluvního vztahu na provoz výstupů projektu. Jedná se o datum, ke kterému bude projekt ukončen, bude uzavřena navazující smlouva na provoz výstupů projektu. 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é. Shrnutí shody se základními principy a standardy českého egovernmentu Žádáte výjimku (y)? uveďte odpověď Ano nebo Ne, zda je v žádosti vědomě plánován rozpor s principy či standardy českého egovernmentu, přičemž ke každému rozporu je jako příloha žádosti podán vyplněný formulář Žádost o výjimku. Počet žádostí o výjimku v přílohách uveďte počet žádostí o výjimku, které jsou přílohou žádosti. Komentář k výjimkám v případě že je žádáno o výjimku, tak stručně popište, výjimky, o něž je žádáno (např. nevyužití JIP/KAAS nebo nezpřístupnění služby skrze CzechPOINT). 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 5

6 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. Realizační (implementační) výdaje v rámci projektu v Kč bez DPH předběžný, kvalifikovaný odhad výše hodnoty projektu v českých korunách bez DPH. Jedná se o součet všech externích výdajů - plánovaných smluv, objednávek, implementačních prací, nákupu HW, SW apod., kterými bude projekt realizován. Jedná se o součet sloupce 1 tabulky v kapitole formuláře žádosti. Provozní výdaje plánované v rámci projektu v Kč bez DPH předběžný, kvalifikovaný odhad výše externě vynakládaných nákladů na produkční provoz a provozní podporu výstupů projektu (kromě např. nákladů na energie, nájem, pozáruční aktualizace SW dle legislativy a povinného testování i např.: externí administrace, tzn. součet všech plánovaných úprav, dodělávek, rozvoje, údržby, apod., které plánujete vynaložit v rámci plánované doby životnosti/udržitelnosti výstupů projektu) v českých korunách bez DPH. Jedná se o součet sloupce 2tabulky v kapitole formuláře žádosti. 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 projektu, vyplňte a označ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: 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, 6

7 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. Popis projektu (tzv. To-Be) podrobnější popis v čem projekt spočívá, tj. popis změn, ke kterým v průběhu projektu dojde (ne pouze technických, ale i organizačních, např.: změny procesů, personálních kapacit, pravidel, ), jaký má projekt rozsah (jakých organizací/útvarů a jakých ICT služeb se dotkne, jak velké geografické území obsáhne, kolika uživatelů a jakých propojených dalších systémů se dotkne,.) a návaznosti a jak bude vypadat cílový stav (klíčové výkonové, kvalitativní a bezpečnostní SLA hlavních služeb), po jeho realizaci. V případě, že projekt bude řešit pouze některé z identifikovaných nedostatků, je třeba uvést i vymezení, které nedostatky projekt řešit nebude a zdůvodnění tohoto rozhodnutí. Důvod změny v uvedeném výčtu důvodů vyberte ty, které Vás vedou ke změně současného stavu: Legislativní důvody: Nový právní předpis, který vyžaduje změnu řešení Konec licencí: U produktu skončily licence k užívání a je potřeba je nahradit novými nebo změnit celý systém. Modernizace, optimalizace řešení (výsledky business analýz): Na základě výstupů z analýz procesů vznikl požadavek na optimalizaci, které má pomoci nový/modernizovaný IS. Lepší nabídka trhu: Existuje nové řešení na trhu, které je objektivně lepší, efektivnější či hospodárnější. Změna není vynucena legislativou ani jiným právním důvodem, jen se jedná o řešení, které nabídne lepší výkon než současný. Požadavky zaměstnanců, uživatelů: Současné řešení neodpovídá požadavkům zaměstnanců a uživatelů. Je málo intuitivní a efektivita práce s ním je malá. Konec podpory od dodavatele: Dodavatel přestává podporovat současného řešení. Může se jednat o konec samotného dodavatele nebo jen změnu jeho business plánu. Konec podpory produktu: Současnému produktu končí podpora od všech známých dodavatelů. Jiné důvody, které Vás ke změně vedou - např.: sdílení/výměna dat (integrace) s jiným systémem/službou, blížící se konec životního cyklu, rostoucí poruchovost, výkon nedostačující očekávané potřebě, odolnost neodpovídající vývoji kybernetických hrozeb, potřeba rozšíření dostupnosti služby pro další uživatele atd. vysvětlete v tabulce 8 formuláře žádosti. Za dostatečné odůvodnění naléhavosti projektu nelze považovat pouze označení např. důvodu: Legislativní důvody. Každé zdůvodnění musí vždy vycházet z reálné analýzy současného stavu ICT aktiv instituce (jak primárních, tak i podpůrných, tj. ne pouze infrastruktury, ale i souvisejících organizačních pravidel, personálního zabezpečení atd.) ve vztahu k měnícím se povinnostem a potřebám. Např. projekty z oblasti bezpečnosti vždy musí vycházet ze zjištění bezpečnostního auditu či penetračních testů. Odůvodněnost potřebnosti projektu je třeba hodnotit nejen sumárně za celý projekt, ale i z pohledu jednotlivých, do projektu zahrnutých fází / aktivit / opatření. Z příčiny obvykle plynou i hlavní cíle. Musí proto vždy být obsahově konzistentní s předmětem projektu uvedeným v tabulce 3. Přehled případných alternativ řešení rozdílných od Popis projektu (tzv. To-Be) - Klíčovým předpokladem úspěšného projektu (hned po kvalitním zadání), je zjištění všech aktuálně reálných alternativ řešení = aby hodnocení opravdu obsáhlo všechny alternativy. a) přehled posuzovaných alternativ (kombinací různých organizačních a technických opatření, různých provozních režimů atd.) dosažení splnění požadovaných parametrů - protože maximální efekt lze dosáhnout jen vhodnou kombinací organizačních a technických opatření, b) charakteristiku a zhodnocení zvažovaných alternativ, Zvolenou alternativu je vymezit jednoznačně, nikoliv vždy nutně detailně. V tabulce 5: Přehled výstupů projektu, vyplňte a zvolte skutečnosti odpovídající variantu: Přehled výstupů projektu položkový seznam všeho, co bude projektem realizováno. Příkladem obvyklých výstupů jsou: 7

8 a) nová nebo změněné parametry existující služby (např. napojení služby na JIP/KAAS pro jednoznačnější identifikaci), b) nově pořízený majetek (např.: nově vybudovaná datová síť, zakoupené licence např. na vlastní informační systém, přístupové licence k serverům pro uživatele koncových stanic, atd.), c) nové závazky (např. smlouvy o podpoře, ale i přístupové licence k SaaS/PaaS/atd.), d) zásadní změny konfigurace (např. upravená rozhraní napojených systémů). Jednotlivé výstupy charakterizujte v následující struktuře: Označení výstupu jedinečné označení výstupu názvem nebo číslem. Množství a jednotka množství a jednotky množství (nejčastěji ks / kusy) výstupu, tedy kolik jednotek dané položky je výstupem (např. počet rozhraní informačních systémů nebo počet nakoupených serverů) Celková cena výstupu bližší popis upřesňující název výstupu. Vysvětlení výstupu bližší popis upřesňující název výstupu. Rozsah změny informace, zda jde o zcela Nový výstup nebo o výstup starší, ale projektem Upravený, případě Rozšířený. 1.4 Právní klasifikace předmětu projektu V tabulce 6: Klasifikace předmětu projektu dle zákonů egovernmentu, z uvedené nabídky pro vybrané klasifikace uvedených variant zvolte skutečnosti odpovídající variantu: Druh informačního systému dle klasifikace zák. 365/2000 Sb., o informačních systémech VS pokud je předmětem projektu informační systém, uveďte, jakého je druhu dle popisů zák. o ISVS: Informační systém veřejné správy Informační systém nakládající s utajovanými skutečnostmi Provozní informační systém podléhající zák. č. 365/2000 Sb. Provozní informační systém nepodléhající zák. č. 365/2000 Sb. ISVS nepodléhající zák. č. 365/2000 Sb. Projektem není informační systém Zda je předmětem projektu Agendový informační systém dle zák. 111/2009 Sb., o základních registrech pokud je předmětem projektu informační systém, tak uveďte, zda je agendovým informačním systémem dle zák. č. 111/2009 Sb. (Ano) nebo není (Ne). Zda budou předmětem projektu přijímány a odesílány datové zprávy dle zák. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů uveďte, zda bude předmět projektu propojen s informačním systémem datových schránek pro příjem nebo odesílání datových zpráv (Ano) nebo nebude (Ne). Pro kladnou odpověď stačí příjem nebo odesílání automatizovaně prostřednictvím systému spisové služby. Klasifikace dle zák. o kybernetické bezpečnosti uveďte, do jaké míry podléhá předmět projektu zák. č. 181/2014 Sb., o kybernetické bezpečnosti, zejména zda projekt je: Kritická informační infrastruktura Významný informační systém Informační systém základní služby Nespadá pod definici dle ZoKB V tabulce 7: Vazba projektu na informace v Portálu veřejné správy, zvolte položku a vyplňte Zda budou v Portálu veřejné správy (resp. v Portálu občana) popsány všechny související životní situace v souladu s vyhláškou č. 442/2006 Sb. pokud je předmětem projektu podpora řešení některé životní situace, uveďte, zda bude při spuštění do ostrého provozu popsána životní situace v souladu s vyhláškou č. 442/2006 Sb., kterou se stanoví struktura informací zveřejňovaných o povinném subjektu způsobem umožňujícím dálkový přístup. Zda bude pro přístup občanů k el. službám úřadu využita struktura služeb v Portálu veřejné správy (resp. v Portálu občana) pokud je předmětem projektu dotčena některá služba 8

9 úřadu, která bude k dispozici veřejně v elektronické podobě, uveďte, zda bude na Portálu veřejné správy uveden hypertextový odkaz na uživatelské rozhraní této služby. Zda budou projektem využívané formuláře při el. komunikaci s klienty VS dostupné s využitím struktury služeb v Portálu veřejné správy (resp. Portálu občana) pokud je předmětem projektu dotčena struktura, dostupnost nebo zpracování příjmu elektronických formulářů, uveďte, zda bude na Portálu veřejné správy uveden hypertextový odkaz na tyto formuláře. V tabulce 8: Vysvětlení k základním podmínkám, uveďte vysvětlení / možné nejasnosti či potřebná doplnění vztahující se k celé kapitole 1. 2 A R C H I T E K T O N I C K É I N F O R M A C E O P R O J E K T 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 Použitelnost Důvěryhodnost 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 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 Elektronické služby musí zajistit adekvátní zabezpečení datového obsahu i přístupu 9

10 Název principu Spolupráce a sdílení Udržitelnost Technologická neutralita Znění principu 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 9: 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 10: 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 11: 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. 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. 10

11 V tabulce 12: 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 13: 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 14: 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. 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 15: 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. 11

12 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 16: 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 17: 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. 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 18: 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í. 12

13 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. 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 19: 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í. 13

14 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 20: 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 21: 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: 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 22: 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 14

15 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 23: 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 24: 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. 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 25: 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: 15

16 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 26: 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) 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. 16

17 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 27: 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í. V tabulce 28: 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í. 17

18 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 29: 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 30: 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ů 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. 18

19 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 31: 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 oblast uveďte plánovaný termín publikace. Oblastí dat rozumíme např. sadu údajů k danému typu entit/objektů (např. údaje o jízdních řádech), přičemž není nutné uvádět, jaké konkrétní údaje budou zveřejňovány. Pro seznam možností způsobu zajištění vedení dat uveďte následující údaje: Použito vyberte ze seznamu možností způsobu zajištění vedení dat Č. žá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í. 19

20 V tabulce 32: Nakládání s osobními a citlivými údaji, vyplňte Způsoby identifikace dat FO a PO v Agendovém IS (AIFO, IČO, rodné číslo nebo jiný identifikátor) popište, jaké všechny identifikátory fyzických a právnických osob evidujete nebo používáte pro výměnu dat mezi úřady či mezi agendami. Nejčastěji se jedná o AIFO od Základních registrů, IČO, rodné číslo nebo vlastní specifické identifikátory resortu. Způsoby zavedení základních principů práce s osobními a citlivými údaji dle nařízení GDPR popište, jak splňujete jednotlivé základní principy práce s osobními a citlivými údaji dle nařízení GDPR Zabezpečení zpracování dle článku 32 nařízení GDPR má správce a zpracovatel s přihlédnutím ke stavu techniky, nákladům na provedení, povaze, rozsahu, kontextu a účelům zpracování i k různě pravděpodobným a různě závažným rizikům pro práva a svobody fyzických osob, zajistit vhodná technická a organizační opatření k zajištění zabezpečení odpovídající danému riziku, včetně šifrování, pseudonymizace, integrity, důvěrnosti, testování a hodnocení. Je systém připraven na tuto možnost? Právo na přístup dle článku 15 nařízení GDPR má subjekt údajů právo získat od správce potvrzení, zda osobní údaje, které se ho týkají, jsou či nejsou zpracovávány, a pokud je tomu tak, má právo získat přístup k těmto osobním údajům. Je systém připraven na tuto možnost? Právo na opravu dle článku 16 nařízení GDPR má subjekt údajů právo na to, aby správce bez zbytečného odkladu opravil nepřesné osobní údaje, které se ho týkají. Je systém připraven na tuto možnost? Právo na výmaz dle článku 17 nařízení GDPR má subjekt údajů právo na to, aby správce bez zbytečného odkladu vymazal osobní údaje, které se daného subjektu údajů týkají, a správce má povinnost osobní údaje bez zbytečného odkladu vymazat. Je systém připraven na tuto možnost? Právo na omezení zpracování dle článku 18 nařízení GDPR má subjekt údajů právo na umožnění omezení zpracování údajů. Je systém připraven na tuto možnost? Právo na oznamovací povinnost dle článku 19 nařízení GDPR má subjekt údajů a další příjemci údajů právo na oznamovací povinnosti ohledně opravy nebo výmazu osobních údajů nebo omezení. Je systém připraven na tuto možnost? Právo na přenositelnost dle článku 20 nařízení GDPR má subjekt údajů právo získat osobní údaje, které se ho týkají, jež poskytl správci, ve strukturovaném, běžně používaném a strojově čitelném formátu, a právo předat tyto údaje jinému správci, aniž by tomu správce, kterému byly osobní údaje poskytnuty, bránil. Je systém připraven na tuto možnost? V tabulce 33: Dodržení architektonických principů, zvolte skutečnosti odpovídající z nabízených variant a vyplňte, zda je projekt v souladu uvedenými požadavky jednotlivých principů. V případě, kdy je požadavek pro projekt relevantní, ale není s ním v souladu, je většinou nutné požádat o výjimku z principu prostřednictvím přiložení formuláře žádosti o výjimku. 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, 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í. 20

21 V tabulce 34: Vysvětlení v kontextu datové architektury úřadu, tedy jaké k projektu existují či vznikají duplicity a proč a jaké jsou další souvislosti, vyplňte všechny duplicity, které se na datové vrstvě vyskytují. Například, jak souvisí navrhované evidované datové objekty s ostatními obdobnými datovými objekty organizace (například zda a proč potřebuje nová agenda znovu evidovat základní údaje a rodinné vztahy fyzické osoby) nebo naopak poukažte na to, jak nová agenda využije po úpravě stávajících aplikačních komponent, evidujících tytéž objekty. 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 budou datové objekty centrální části řešení, dostupné a užívané z lokálních pracovišť uvedeny do souladu či integrovány s týmiž lokálně udržovanými datovými objekty. Vysvětlení k datové architektuře 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í Technologická architektura vrstva IT technologie (HW a SW) Tato část architektury projektu objasňuje první polovinu celkové technologické architektury projektu, v dělení podle čtyřvrstvé vize architektury egovernmentu. Zaměřuje se na HW a systémový SW výpočetních technologií a na jejich technologické (tzv. platformové) funkce a služby. V tabulce 35: Katalog uzlů a klíčových funkcí nebo služeb, zvolte skutečnosti odpovídající z nabízených variant a vyplňte seznam technologických komponent, funkcí a platformových (IT) služeb datových center využívaných pro příslušné aplikační komponenty, zahrnuté do projektu. Důležité je uvést architektonicky podstatné informace, tj. zejména druhy IT zařízení (klientských i serverových), jejich operační systémy (OS), databáze (DB), virtualizační prostředí, apod. Pro katalog uzlů a klíčových funkcí nebo služeb uveďte následující údaje: Typ prvku určení, zda je položka katalogu uzel, funkce nebo služba. Název prvku název nebo označení prvku. Vysvětlení významu uzlu, funkce nebo služby 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. Modely technologické architektury pohled struktury IT technologické architektury 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 36: Využití sdílených IT technologických a platformových služeb, zvolte skutečnosti odpovídající z nabízených variant PaaS čerpání technologického výkonu jako služby (Platform as a Service), tedy pronájem technologií (zejména serverů) v datovém centru externího subjektu (třetí osoby) pro běh vlastních aplikačních komponent. V případě využití datového centra externího subjektu rozlište, zda se bude jednat o datové centrum v perimetru Národních datových center nebo o privátní datové centrum. DC egov využívání bezpečnostních služeb Dohledového centra egovernmentu Ministerstva vnitra. Dostupné především pro systémy MV a pro centrální sdílené služby egovernmentu ČR. Pro seznam sdílených IT technologií uveďte následující údaj: Použito výběr ze seznamu, zda je pro projekt prvek národního egovernmentu Nerelevantní nebo zda je jeho použití plánováno. V tabulce 37: Vysvětlení v kontextu technologické 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 technologické vrstvě vyskytují. Například, jak souvisí navrhované technologické komponenty s ostatními obdobnými komponentami úřadu (například zda a proč potřebuje nová agendová aplikace samostatné HW řešení nebo naopak jak nová agendová aplikační komponenta využije stávající virtualizované prostředí datového centra úřadu). Vysvětlete, jak bude integrována centrální komponenta s existujícími nebo připravovanými technologickými komponentami a funkcemi řešení na pracovištích rozšířeného řetězce dodávky této veřejné služby. 21

22 Vysvětlení technologické 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í Technologická architektura vrstva komunikační infrastruktury Tato část architektury projektu objasňuje druhou polovinu celkové technologické architektury projektu, v dělení podle čtyřvrstvé vize architektury egovernmentu. Zaměřuje se na infrastrukturu datových center a na komunikační infrastrukturu, jejich infrastrukturní funkce, případně služby. V tabulce 38: Katalog infrastrukturních komunikačních funkcí, sítí, cest a klíčových služeb, vyplňte seznam služeb komunikační infrastruktury, které využíváte pro příslušné platformové a aplikační komponenty, jste-li jejich spotřebitelem. Případně jaké technologické komponenty a funkce využíváte pro zajištění těchto síťových služeb, jste-li jejich poskytovatelem. Případně odpovídající kombinaci obou přístupů, pokud například využíváte KIVS, ale současně provozujete vlastní optickou síť. Pro katalog funkcí, sítí, cest a klíčových služeb uveďte následující údaje: Typ prvku určení, zda je položka katalogu funkce, síť, cesta nebo služba. Název prvku název nebo označení prvku. Vysvětlení významu uzlu, funkce nebo služby 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. Model technologické architektury pohled struktury komunikační infrastruktury 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 39: Využití sdílených služeb komunikační infrastruktury, vyplňte CMS využití některé ze služeb poskytovaných Centrálním místem služeb 2.0. V případě využití objasněte, které služby plánujete využívat do Vysvětlení architektury komunikační infrastruktury níže. KIVS využití Komunikační infrastruktury veřejné správy, tj. fyzického propojení infrastruktury úřadů nebo VPN připojení k CMS. NDC umístění vlastních technologií (serverů apod.) do Národního datového centra v perimetru Centrálního místa služeb. Housing (IaaS) umístění vlastních technologií (serverů apod.) do privátního datového centra externího subjektu. Jedná se o čerpání infrastruktury jako služby (Infrastructure as a Service). Pro seznam sdílených komunikačních služeb uveďte následující údaj: Použito výběr ze seznamu, zda je pro projekt prvek národního egovernmentu Nerelevantní nebo zda je jeho použití plánováno. CMS a KIVS jsou povinné pro všechny projekty, pro které jsou relevantní. U těchto znamená rozhodnutí o jejich nepoužití nutnost požádat o výjimku. Č. výjimky 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. Pro nepovinné požadavky (šedě podbarvené) se nevyplňuje. V tabulce 40: Vysvětlení v kontextu architektury komunikační infrastruktury úřadu, tj. prosíme, vyplňte, jaké k projektu existují či vznikají duplicity a proč a jaké jsou další souvislosti uveďte všechny duplicity, které se na komunikační vrstvě vyskytují. Například, jak souvisí navrhované komunikační komponenty s ostatními obdobnými komponentami úřadu. Vysvětlete, jak bude integrována centrální komponenta s existujícími nebo připravovanými technologický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í architektury komunikační infrastruktury 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í Bezpečnostní architektura Tato část architektury projektu objasňuje pasivní bezpečnostní pohled, tj. které prvky kterékoli z vrstev architektury projektu jsou hodny z hlediska své potřeby zabezpečení mimořádného zřetele a jakými 22

23 prostředky a opatřeními bude toto zabezpečení realizováno. Současně objasňuje z obráceného, aktivního pohledu, které prvky zvýšeného zabezpečení projekt do úřadu přináší a co a před čím jimi bude nově nebo lépe chráněno. V tabulce 41: Katalog bezpečnostní architektury projektu, vyplňte seznam objektů architektury úřadu, zahrnuté do rozsahu projektu, které jsou cílem nějaké hrozby nebo jejich implementace vyžaduje konkrétní bezpečnostní opatření a seznam hrozeb a rizik úřadu, které pomáhá navrhovaný projekt zmírnit, jakým objektem architektury a jakým implementovaným způsobem (opatřením). Pro katalog bezpečnostní architektury uveďte následující údaje: Dotčený nebo bezpečnostní prvek název nebo označení prvku, který je vystaven nějaké hrozbě či bezpečnostního prvku, jehož účelem je hrozbám předcházet a bránit. Hrozba / riziko název nebo označení rizika či hrozby, jež vůči prvku působí nebo jemuž prvek brání. Vysvětlení způsobu zmírnění hrozby / rizika prvkem architektury bližší objasnění obsahu a významu prvku, tak aby bylo zcela zřejmé, k čemu slouží a co zajišťuje, případně jaké opatření je navrženo, aby prvek hrozbě odolal. V tabulce 42: Dodržení architektonických principů, vyplňte/uveďte, zda je projekt v souladu uvedenými požadavky jednotlivých principů. V případě, kdy je požadavek pro projekt relevantní, ale není s ním v souladu, je většinou nutné požádat o výjimku z principu prostřednictvím přiložení formuláře žádosti o výjimku. 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, 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 43: Vysvětlení bezpečnostní architektury projektu, vyplňte/vysvětlete všechny potřebné souvislosti a pro projekt důležité informace, spojené s výše uvedenými architektonickými objekty, anebo je doplňující Shoda s pravidly, standardizace a dlouhodobá udržitelnost Tato část architektury projektu objasňuje, co projekt při realizaci plánovaných změn definuje a omezuje. V tabulce 44: Uveďte, které licence standardizovaných SW produktů budete pořizovat podle centrálních rámcových smluv zajištěných Ministerstvem vnitra, případně proč tento instrument nevyužijete, vysvětlete proč, vyplňte, které licence standardizovaných SW produktů budete pořizovat podle rámcové smlouvy zajištěné Ministerstvem vnitra. Případně vysvětlete, proč jste se rozhodli tohoto instrumentu nevyužít. Informace o aktuálně uzavřených rámcových smlouvách naleznete na adrese V tabulce 45: Shoda se strategickými dokumenty, vyplňte shoda se strategickými dokumenty popisující hlavní směr fungování elektronizace veřejné správy pro projekty úřadu, resortu či egovernmentu. Vyžadován je zde soulad s informační koncepcí úřadu, soulad s informační koncepcí státu a národním architektonickým plánem je do jejich plného zveřejnění nepovinná. V tabulce 46: Dodržení architektonických principů architektury shody s pravidly, vyplňte uveďte, zda je projekt v souladu uvedenými požadavky jednotlivých principů. V případě, kdy je požadavek pro projekt relevantní, ale není s ním v souladu, je většinou nutné požádat o výjimku z principu prostřednictvím přiložení formuláře žádosti o výjimku. Pro seznam architektonických principů uveďte následující údaje: 23

24 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, 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 47: Vysvětlení standardizace a udržitelnosti architektury projektu, vyplňte/vysvětlete všechny potřebné souvislosti a pro projekt důležité informace, spojené s výše uvedenými architektonickými objekty, anebo je doplňující Přehled služeb čtyřvrstvé architektury Tato část architektury projektu objasňuje, jak komponenty funkce nižší vrstvy architektury poskytují služby komponentám a funkcím vrstvy vyšší. Model služeb v čtyřvrstvé vizi architektury veřejné správy nebo jednotlivé modely využití každé vrstvy vrstvou 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 případě menšího rozsahu architektury navrhovaného projektu uveďte namísto dílčích diagramů Využití prvků vrstvy vyšší vrstvou, nebo ještě jednou vedle nich navíc, všechny tyto vazby mezi vrstvami společně, pohromadě v diagramu dle hlediska Přehled služeb čtyřvrstvé architektury s následující definicí (metamodelem) V tabulce 48: Dodržení architektonických principů 4 vrstvé architektury, vyplňte/uveďte, zda je projekt v souladu uvedenými požadavky jednotlivých principů. V případě, kdy je požadavek pro projekt relevantní, ale není s ním v souladu, je většinou nutné požádat o výjimku z principu prostřednictvím přiložení formuláře žádosti o výjimku. 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é. Č. žá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 49: Vysvětlení čtyřvrstvé architektury služeb projektu, vyplňte/vysvětlete všechny potřebné souvislosti a pro projekt důležité informace, spojené s výše uvedeným diagramem čtyřvrstvé architektury. 2.3 Kontrola shody architektury řešení projektu se vzory sdílených služeb egovernmentu V tabulce 50: Kontrola shody architektury řešení projektu se vzory sdílených služeb egovernmentu, zvolte pravdivou z nabízených variant popisující dodržení aktuálních Architektonických vzorů sdílených služeb egovernmentu (jsou publikovány dokumentem OHA MV ČR, dostupným na adrese: Uveďte, zda a jak předkládaný projekt dodržuje jednotlivé vzory architektury sdílených služeb egovernmentu. Pro seznam kontroly shody s architektonickými vzory uveďte následující údaje: 24

25 Dodržen vzor výběr ze seznamu, zda danou otázku týkající se vzoru projekt splňuje (Ano) nebo zda je požadavek Nerelevantní. Nenaplnění (Ne, žádáme o výjimku) znamená nutnost požádat o 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. Pro nepovinné požadavky (šedě podbarvené) se nevyplňují nikdy. Podrobný popis způsobu a míry dodržení vzorů návrhem řešení projektu vysvětlete, jakým způsobem je projektem naplněn požadavek, případně vysvětlete, proč naplněn není nebo je nerelevantní. 2.4 Plán projektu Zde popište, jaká je základní struktura projektu z hlediska jeho fází /milníků a jaké jsou návaznosti na ostatní projekty. V tabulce 51: Hrubý harmonogram předloženého projektu, vyplňte seznam jednotlivých fází a milníků projektu, včetně jejich začátků a konců, základní náplně a existujících návazností (podmíněnost) na ostatní fáze. Pro harmonogram projektu uveďte následující údaje: Fáze / milník název nebo označení fáze či milníku. Začátek datum zahájení fáze nebo datum nabytí milníku. Konec datum dokončení fáze. Základní náplň popis co je ve fázi projektu vykonáváno nebo čím je dosaženo milníku. Navazuje na výčet fází, na které tako fáze nebo milník navazují. V tabulce 52: Projektový kontext předkládaného projektu (v rozvojovém programu, portfoliu úřadu), vyplňte Předchozí projekty název a popis všech jednotlivých projektů, na které tento projekt navazuje a vysvětlení této návaznosti. Souběžné projekty název a popis všech jednotlivých projektů, které budou probíhat souběžně s tímto projektem a mají s ním nějakou souvislost (věcnou, místní či logickou) a vysvětlení této souvislosti. Navazující projekty název a popis všech jednotlivých projektů, jejichž realizace se předpokládá, a které na tento projekt budou navazovat a vysvětlení této návaznosti. V tabulce 53: Vysvětlení plánu projektu, vyplňte/vysvětlete, jakou roli v plánu rozvoje této oblasti úřadu hraje právě předkládaný projekt. 3 D A L Š Í Ú D A J E O P R O J E K T U Zde budou uvedeny všechny informace, které musí OHA ve svém stanovisku podle usnesení vlády ze dne 2. listopadu 2015, č. 889 zohlednit mimo konzistence architektury s architekturou egovernmentu, tj. zejména: potřebnost, účelnost, hospodárnost, realizovatelnost, připravenost, přínos, ekonomickou a personální náročnost, způsob řízení, analýzu rizik a navržený způsob řízení projektu. Tyto údaje by měly být známé především vedoucímu projektu popřípadě pracovníkovi sledujícímu dané oblasti v rámci projektu. 3.1 Připravenost projektu k realizaci Majetkoprávní vztahy projektu (povinné jen pro projekty zakázkového vývoje SW) Tato kapitola se vyplňuje výhradně pro projekty, jejichž součástí je vývoj aplikace na míru pro organizaci. Cílem je identifikovat, zda byla přijata základní pravidla zabránění vzniku závislosti na konkrétním dodavateli (tzv. vendor-lock). Pro každou otázku v tabulce 54 zvolte z nabízených variant skutečnosti odpovídající odpověď Ano nebo Ne a vysvětlete jakým způsobem a v jakém rozsahu bude otázka plněna či neplněna. 25

26 3.1.2 Finanční připravenost projektu Pro každou otázku v tabulce 55 zvolte z nabízených variant skutečnosti odpovídající odpověď Ano nebo Ne, případně v Poznámce upřesněte druh financování a způsob, jakým jste si finance z daného zdroje zajistili či zajistíte. Případně zda je pro projekt životně důležité dané financování Metodická připravenost projektu Pro každou otázku v tabulce 56 zvolte z nabízených variant skutečnosti odpovídající odpověď Ano nebo Ne, případně v Poznámce upřesněte druh financování a jakým způsobem je dané zajištění zapracováno do projektu, případné vysvětlení, proč tomu tak není a jaký to může mít dopad. 3.2 Ekonomické parametry projektu Hodnota výdajů a ekonomická náročnost projektu. Do hodnot TCO v tabulce 57 jsou dočasně vyžadovány k započtení pouze externí výdaje placené jiným subjektům (ne interním pracovníkům). V případě, že organizace sleduje i tyto výdaje a je schopna je adresně vyčíslit, může je uvést. Pro odhad plánovaných výdajů a/nebo nákladů projektu, se v rámci záměrného zjednodušení metodiky výpočtu TCO pro ICT VS ČR použijí jenom ty nákladové položky z plánu nákladových kategorií účelového TCO modelu (viz níže), které nejsou označeny oranžově, tj. A, B, C, D, E, F, G, a případně X pro SaaS, jež odpovídají plánovaným přímým výdajům a nákladům na projekt. Do plánu externích přímých výdajů je nutno započítat i výdaje za dodavatelem původního řešení při přípravě migrace a ukončení jeho provozu nebo archivaci viz nákladová komponenta C8 Pořízení/Migrace dat. Obdobně i interní náklady na totéž v odhadu celkové ekonomické náročnosti. Model účelového členění nákladů pro ukazatel TCO: 26

27 Ukazatel TCO pro ICT VS ČR Legenda: Jednorázové náklady Průběžné náklady A. Předběžné analýzy, zadání, výběr a nákup B. Pořízení Hardware/ Software (ne SaaS) C. Vývoj, imlementace / integrace a zk. provoz D. Provoz a podpora řešení (ne SaaS) E. Hardware/Software údržba a úpravy (ne SaaS) F. Projekty postupného zlepšování řešení (částečně pro SaaS) G. Projekty Upgrade (ne SaaS) H. Zvýšené náklady užívání řešení I. Konzervace a ukončení řešení (ne SaaS) X.Předplatné na služby (pouze SaaS) Z. Ostatní režijní náklady A1. Předběžné studie (proveditelnosti, ) A2. Náklady na proces zadání, výběru a nákupu B1. Technická infrastruktura (HW, sítě, ) B2. Stavební infrastruktura (budovy, chlazení ) B3. Systémové SW licence B4. Vývojové SW licence B5. Aplikační SW licence C1. Projektové řízení C2. Návrh změněných procesů C3. Řízení organizačních změn (OCM) C4. Technické nastavení řešení C5. Obsahové (aplikační) nastavení řešení C6. Vývoj aplikace nebo úprav na míru C7. Realizace rozhraní C8. Pořízení / Migrace dat C9. Testování C10.Školení C11.Předání do provozu a ověřovací provoz D1. Provoz budov a technologií dat. centra D2. Provoz a podpora IT tech. syst., OS a DB D3. Provoz a podpora aplikací E1. Údržba technologické infrastruktury E2. Údržba systémového SW a DB E3. Údržba aplikačního SW E4. Průběžné úpravy řešení /aplikačního SW F1. Funkční (procesní) zlepšování F2. Technické zlepšování F3. Roll-out projekty F4. Projekty (nákladové) optimalizace řešení G1. Aplikační upgrade G2. Upgrade systémového SW G3. Technologický upgrade G4. Infrastrukturní upgrade H1. Náklady ze ztráty produktivity H2. Náklady spojené s užíváním řešení I1. Útlum a archivace řešení I2. Příprava dat pro migraci I3. Likvidace zařízení X1. Nákup aplikačního SW jako služby (SaaS) Z1. Ostatní provozní režie Z2. Ostatní správní režie Hrubý odhad hodnoty záměru nákupu služeb či investic (externích výdajů), souvisejících s informačními a komunikačními technologiemi (projektu) Zdroje, které již žadatel má (nemusí na ně tudíž vydat nové externí výdaje) plánuje je pro daný projekt a jeho řešení použít, se do tohoto odhadu nezapočítají (např.: budova existujícího datového centra, pracovní stanice a přístupové licence referentů (CAL) k operačním a databázovým serverům (CORE licence) virtualizovaného prostředí). Do členění dle metodiky TCO vyplňte následující sloupce: 27

28 1 Výdaje na realizaci (výstavbu) projektu výdaje hrazené externím subjektům za realizaci projektu. Realizací projektu jsou myšleny veškeré činnosti prováděné před spuštěním ostrého provozu. Například se jedná o výdaje na vývoj informačních systémů, nákup licencí a hardware, tedy především o řádky A, B a C. V případě, že je projekt zaměřen na provozní stránku a realizační fázi neobsahuje, tak může být sloupec nulový. Pokud výdaj v řádku B přesahuje 10% celkové ceny projektu a současně přesahuje 1 mil. Kč, uveďte do tabulky 59 nebo samostatné přílohy rozpad výdajů. Při jakékoliv částce v řádku C uveďte do tabulky 59 nebo samostatné přílohy seznam rolí s počtem člověkodnů a cenu za člověkoden> 2 Výdaje na provoz a rozvoj (do konce aktuální smlouvy) výdaje hrazené externím subjektům za dobu provozu projektu. Započítejte veškeré předpokládané výdaje, které umožňují chystané obchodní vztahy na období od spuštění ostrého provozu do ukončení účinnosti smluv či objednávek. Například se jedná o výdaje na maintenance a rozvoj informačních systémů nebo platby za licence s termínem vypršení, tedy především o řádky D, E, F a G. V případě, že je projekt zaměřen jen na výstavbu/realizaci a provozní podpora není požadována, tak může být sloupec nulový. Pokud výdaj v řádku D nebo E přesahuje 20% celkové ceny řešení, uveďte do tabulky 59 nebo samostatné přílohy rozpad výdajů. 3 TCO 5 ((1) plus (2 odhadnutý na 5 let)) celkové externí výdaje projektu za dobu jeho realizace (výstavby) a přesně 5 let provozu ode dne spuštění do ostrého provozu. V případě, že je v rámci projektu plánováno uzavření smluv ohledně provozu a rozvoje na období 5 let, pak by TCO 5 mělo být rovno součtu sloupců 1 a 2. Pokud je projekt plánován včetně podpory na dobu delší než 5 let, tak se k výdajům na realizaci projektu připočítají provozní a rozvojové výdaje na prvních 5 let ostrého provozu. Pokud je plánován projekt včetně podpory na dobu kratší než 5 let od uvedení do ostrého provozu, tak se k výdajům na realizaci (výstavbu) připočítají odhadnuté výdaje na 5 let ostrého provozu. V tomto případě je nutné neopomenout připočítat i výdaje na očekávatelný rozvoj aplikací a obměnu technického vybavení. Do řádků tabulky ekonomické náročnosti uveďte následující údaje: Počet měsíců trvání fáze počet měsíců, které bude trvat příslušná fáze definovaná sloupcem. ve sloupci 1 se tedy bude jednat o počet měsíců uplynulých od Termínu plánovaného zahájení realizace projektu (zahájení výstavby, je-li součástí dle údaje v kapitole 1.2) do Termínu plánovaného dokončení realizace projektu (uvedení do ostrého provozu dle údaje v kapitole 1.2). ve sloupci 2 se tedy bude jednat o počet měsíců uplynulých od Termínu plánovaného zahájení provozu (spuštění ostrého provozu dle údaje v kapitole 1.2) do Termínu plánovaného ukončení provozu (konec smluvního vztahu s dodavatelem dle údaje v kapitole 1.2). ve sloupci 3 se tedy bude jednat o počet měsíců vyplněný ve sloupci 1 plus 60 měsíců provozu. A. až Z. částky externích výdajů pro jednotlivé skupiny dle metodiky TCO. Celkem součet finančních částek uvedených v příslušném sloupci v řádcích A. až Z. V tabulce 58: Vysvětlení a komentář k souhrnu výdajů a ekonomické náročnosti projektu, vyplňte komentář k souhrnu výdajů a ekonomické náročnosti projektu jakékoli potřebné vysvětlující komentáře k odhadu externích výdajů projektového záměru a k celkové ekonomické náročnosti projektu (TCO). 3.3 Analýza rizik projektu V tabulce 59: Přehled klíčových identifikovaných rizik neúspěchu projektu, vyplňte seznam klíčových rizik, která byla identifikována pro projekt, a to: Rizika během projektové přípravy, Rizika průběhu realizace projektu. Pro seznam rizik uveďte následující údaje: Označení rizika název nebo označení rizika. 28

29 Popis rizika bližší objasnění podstaty a významu rizika, tak aby bylo zcela zřejmé, čeho se týká a kdo je jeho nositelem. Opatření pro snížení rizika opatření, která se aplikují ke snížení možnosti nastání rizika, případně opatření při nastání rizika. 3.4 Plán údržby, dlouhodobá udržitelnost výstupů projektu Zde popište Váš plán na dlouhodobou udržitelnost výstupů projektu a jejich údržbu. Hlavním cílem je zajistit, aby výstupy bylo možné udržovat po stanovenou dobu a aby byla zajištěna kontinuita výstupů i po stanovené udržitelnosti. V tabulce 60 vyplňte plánovaný ověřovací provoz jednotlivých výstupů projektu seznam výstupů projektu s plánovaným ověřovacím (pilotním) provozem a plánovaná doba trvání tohoto provozu. V tabulce 61 vyplňte plánovanou životnost jednotlivých výstupů projektu seznam výstupu projektu s uvedením jejich plánované životnosti v letech a stručným popisem v budoucnu plánovaných změn a rozvoje. V tabulce 62 vyplňte, zda podpora bude zahrnovat rovněž udržování řešení v souladu s novými právními předpisy (tzv. legislativní update). Vysvětlete též, v jakém rozsahu pokud projekt zahrnuje i podporu informačního systému, vysvětlete v jaké šíři je do podpory zahrnut, legislativní update a proč právě v této. Legislativní update je smluvní ustanovení, kterým se dodavatel zavazuje udržovat systém v souladu s platnou legislativou a při změně právních předpisů na své náklady provede příslušnou změnu systému, kterou předá k akceptaci. V otázce Jakým způsobem bude legislativní update hrazen? Zvolte možnost, zda pomocí změnových požadavků na dodavatele nad rámec smlouvy o provozu a podpoře nebo zda je již součástí smlouvy. V tabulce 63 vyplňte, jak je plánován / bude zajištěn další budoucí rozvoj předmětné oblasti a její ICT podpory stručný popis představy zajištění dalšího rozvoje předmětné oblasti a její ICT podpory. V tabulce 64 vyplňte, jak je zajištěno řízené ukončení životnosti jednotlivých výstupů projektu a případný přechod na další řešení, či případná výměna dodavatele nad stejným řešením? (tzv. Exit strategie) stručný popis zajištění ukončení životnosti jednotlivých výstupů projektu. Jakým způsobem bude zajištěno ukončení stávajícího řešení a přechod na případné nové řešení? Je ošetřena migrace z budovaného řešení na případné nové řešení? 4 V Y J Á D Ř E N Í K B E Z P E Č N O S T N Í M A S P E K T Ů M V tabulce 65: Žadatel prohlašuje - toto vyjádření žadatel vyplňuje až na výzvu OHA! Standardně text obsahuje prohlášení žadatele, že předkládaný projekt realizuje plně v souladu s připomínkami/požadavky vznesenými bezpečnostními složkami, které učinily k předloženému projektu. Tyto připomínky/požadavky OHA žadateli pošle oficiálně přes ISDS a bude se čekat na zpětnou reakci. Do doby než bude žadatelem žádost doplněna o soulad s připomínkami, nemůže být vydáno souhlasné stanovisko. Praktický postup v tomto případě je následující: Zpracovatel pošle žádost o stanovisko OHA. V případě, že bezpečnostní složky nebudou mít připomínky, vydá OHA své stanovisko ve lhůtě do 30 dnů po obdržení (ve výjimečných situacích do 60 dní). V případě, že bezpečnostní složky budou mít připomínky, zašle OHA tyto připomínky zpět zpracovateli. Zpracovatel následně tyto připomínky nakopíruje do příslušného políčka, čímž s nimi vyjádří souhlas a takto aktualizovanou žádost o stanovisko zašle celou znovu oficiální cestou na OHA. 5 U P O Z O R N Ě N Í A D O P O R U Č E N Í 29

30 V tabulce 66: Upozornění a doporučení, vyplňte jakékoli další informace, které je třeba k žádosti doplnit a nebylo vhodné je uvést v žádné jiné části formuláře. 6 P Ř Í L O H Y V tabulce 67: Přílohy, vyplňte seznam všech příloh žádosti o stanovisko OHA. Nejčastěji se bude jednat o žádosti o výjimku. Pro seznam příloh uveďte následující údaje: Typ výběr zda se jedná o Žádost o výjimku, Dokumentaci nebo jiný typ přílohy. Číslo a název přílohy název nebo označení přílohy. Upřesnění výjimky/přílohy popis co je obsahem přílohy, v případě žádosti o výjimku upřesnění o výjimku z jakého nesouladu se jedná. 30

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

Metodický pokyn. k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ B3 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á

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 uzavření smluv na provoz, podporu, údržbu, rozvoj a další k existujícímu ICT řešení typ B1 Odbor Hlavního

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

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

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

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

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í 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

Statutární město Brno, městská část Brno-střed INFORMAČNÍ KONCEPCE

Statutární město Brno, městská část Brno-střed INFORMAČNÍ KONCEPCE Statutární město Brno, městská část Brno-střed INFORMAČNÍ KONCEPCE Pokyn tajemníka č.: 12 Bc. Petr Štika, MBA, LL.M., v.r. Vydání č.: 1 tajemník ÚMČ Brno-střed Účinnost: 16.07.2018 Vydal/schválil: Bc.

Více

Podrobná analýza k aktivitě č. 3 - implementace procesního řízení do praxe úřadu

Podrobná analýza k aktivitě č. 3 - implementace procesního řízení do praxe úřadu Příjemce dotace: Město Moravská Třebová Název projektu: Zvýšení kvality řízení a poskytovaných služeb MÚ Moravská Třebová Registrační číslo projektu: CZ.1.04/4.1.01/89.00116 Podrobná analýza k aktivitě

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

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

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

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

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

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

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

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é 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

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

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

Zásady Zastupitelstva Kraje Vysočina pro poskytování finančních příspěvků na zvyšování úrovně IT vybavení organizací zřizovaných Krajem Vysočina

Zásady Zastupitelstva Kraje Vysočina pro poskytování finančních příspěvků na zvyšování úrovně IT vybavení organizací zřizovaných Krajem Vysočina Zastupitelstvo Kraje Vysočina Zásady Zastupitelstva Kraje Vysočina pro poskytování finančních příspěvků na zvyšování úrovně IT vybavení organizací zřizovaných Krajem Vysočina ze dne 11. 12. 2018 č. 12/18

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

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

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

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

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

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

Zadavatel: Česká republika Český statistický úřad se sídlem Na padesátém 81/3268, Praha 10 Strašnice, IČO:

Zadavatel: Česká republika Český statistický úřad se sídlem Na padesátém 81/3268, Praha 10 Strašnice, IČO: Zadavatel: Česká republika Český statistický úřad se sídlem Na padesátém 81/3268, 100 82 Praha 10 Strašnice, IČO: 00025593 Veřejná zakázka: Nákup školících služeb pro ICT zadávaná v otevřeném řízení dle

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

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

OSNOVA PODNIKATELSKÉHO ZÁMĚRU (PZ)

OSNOVA PODNIKATELSKÉHO ZÁMĚRU (PZ) Příloha č. 4 OSNOVA PODNIKATELSKÉHO ZÁMĚRU (PZ) 1 Identifikační údaje žadatele o podporu 1.1 Obchodní jméno, sídlo, IČ/DIČ 1.2 Jméno a příjmení osoby statutárního zástupce žadatele/osoby oprávněné jednat

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

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

Č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

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

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

MOŽNOSTI FINANCOVÁNÍ ROZVOJE SPISOVÉ SLUŽBY A ZAJIŠTĚNÍ JEJÍ KYBERNETICKÉ BEZPEČNOSTI Z IROP. PhDr. Aleš Pekárek, Řídicí orgán IROP

MOŽNOSTI FINANCOVÁNÍ ROZVOJE SPISOVÉ SLUŽBY A ZAJIŠTĚNÍ JEJÍ KYBERNETICKÉ BEZPEČNOSTI Z IROP. PhDr. Aleš Pekárek, Řídicí orgán IROP MOŽNOSTI FINANCOVÁNÍ ROZVOJE SPISOVÉ SLUŽBY A ZAJIŠTĚNÍ JEJÍ KYBERNETICKÉ BEZPEČNOSTI Z IROP PhDr. Aleš Pekárek, Řídicí orgán IROP 25. 2. 2016 PRAHA INTEGROVANÝ REGIONÁLNÍ OPERAČNÍ PROGRAM Program schválen

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

MOŽNOSTI FINANCOVÁNÍ PROJEKTŮ EGOVERNMENTU A KYBERNETICKÉ BEZPEČNOSTI Z INTEGROVANÉHO REGIONÁLNÍHO OPERAČNÍHO PROGRAMU (IROP) V PROGRAMOVÉM OBDOBÍ

MOŽNOSTI FINANCOVÁNÍ PROJEKTŮ EGOVERNMENTU A KYBERNETICKÉ BEZPEČNOSTI Z INTEGROVANÉHO REGIONÁLNÍHO OPERAČNÍHO PROGRAMU (IROP) V PROGRAMOVÉM OBDOBÍ MOŽNOSTI FINANCOVÁNÍ PROJEKTŮ EGOVERNMENTU A KYBERNETICKÉ BEZPEČNOSTI Z INTEGROVANÉHO REGIONÁLNÍHO OPERAČNÍHO PROGRAMU (IROP) V PROGRAMOVÉM OBDOBÍ 2014 2020 8. 9. 2015 Mikulov INTEGROVANÝ REGIONÁLNÍ OPERAČNÍ

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

Praha PROJECT INSTINCT

Praha PROJECT INSTINCT Atestační středisko Equica Inspekční orgán č. 4045 INSPEKČNÍ ZPRÁVA Protokol o provedené zkoušce ATESTACE DLOUHODOBÉHO ŘÍZENÍ ISVS Statutární město Přerov Praha 29. 1. 2015 PROJECT INSTINCT Obsah 1. Identifikace

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

Katalog služeb a podmínky poskytování provozu

Katalog služeb a podmínky poskytování provozu Příloha č. 1 Servisní smlouvy Katalog služeb a podmínky poskytování provozu Část P2_1 P2_1_Katalog služeb a podmínky poskytování provozu 1 Obsah 1 OBSAH... 2 2 DEFINICE POJMŮ... 3 3 DEFINICE SLUŽEB, KOMPONENT

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

Účinnost Tato vyhláška nabývá účinnosti dnem 1. ledna 2007.

Účinnost Tato vyhláška nabývá účinnosti dnem 1. ledna 2007. VYHLÁŠKA 442/2006 Sb. ze dne 31. srpna 2006, kterou se stanoví struktura informací zveřejňovaných o povinném subjektu způsobem umožňujícím dálkový přístup Ministerstvo informatiky stanoví podle 21 odst.

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

Sbírka zákonů ČR Předpis č. 442/2006 Sb.

Sbírka zákonů ČR Předpis č. 442/2006 Sb. Sbírka zákonů ČR Předpis č. 442/2006 Sb. Vyhláška, kterou se stanoví struktura informací zveřejňovaných o povinném subjektu způsobem umožňujícím dálkový přístup Ze dne 31.08.2006 Částka 143/2006 Účinnost

Více

Problematika digitální technické mapy. RNDr. Ivo Skrášek, Zlínský kraj

Problematika digitální technické mapy. RNDr. Ivo Skrášek, Zlínský kraj Problematika digitální technické mapy RNDr. Ivo Skrášek, Zlínský kraj 20.10.2009 Souvislosti Digitální technické mapy (DTM) V současné době neexistuje v České republice jednotný a ucelený rámec pro tvorbu

Více

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

Informační systémy veřejné správy (ISVS) Informační systémy veřejné správy (ISVS) zákon č.365/2000 Sb. ve znění pozdějších změn Informační systémy veřejné správy soubor informačních systémů, které slouží pro výkon veřejné správy Správci ISVS

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

Ú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á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

Stav realizace a priority Národní strategie elektronického zdravotnictví v roce 2018 na čem pracujeme pro ehealth

Stav realizace a priority Národní strategie elektronického zdravotnictví v roce 2018 na čem pracujeme pro ehealth Stav realizace a priority Národní strategie elektronického zdravotnictví v roce 2018 na čem pracujeme pro ehealth Martin Zeman ředitel odboru informatiky pověřeného výkonem činností Národního centra elektronického

Více

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

Specifické informační a komunikační systémy a infrastruktura I. Ministerstvo pro místní rozvoj České republiky oznamuje změny ve 23. 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

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

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

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

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

3. Podmínky dotačního řízení Obecné podmínky pro podání žádosti o doplatek dotace

3. Podmínky dotačního řízení Obecné podmínky pro podání žádosti o doplatek dotace Vyhlášení dotačního řízení o poskytnutí doplatku neinvestiční účelové dotace na pokrytí výdajů na činnosti vykonávané obcí s rozšířenou působností v agendě sociálně-právní ochrany dětí za rok 2018 Ministerstvo

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 vyhlašuje 28. výzvu 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 infrastruktura

Více

Příloha č. 1 Výzvy č. 89: Zvýšení kvality řízení, financování a good governance v úřadech územní veřejné správy. Podporujeme vaši budoucnost

Příloha č. 1 Výzvy č. 89: Zvýšení kvality řízení, financování a good governance v úřadech územní veřejné správy. Podporujeme vaši budoucnost Příloha č. 1 Výzvy č. 89: Zvýšení kvality řízení, financování a good governance v úřadech územní veřejné správy Upřesnění výzvy v bodě 3.4 a specifikace podporovaných klíčových aktivit Cílem výzvy je v

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

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

Obsah Strategie rozvoje infrastruktury pro prostorové informace v ČR do roku (GeoInfoStrategie) Jiří Čtyroký, vedoucí Zpracovatelského týmu

Obsah Strategie rozvoje infrastruktury pro prostorové informace v ČR do roku (GeoInfoStrategie) Jiří Čtyroký, vedoucí Zpracovatelského týmu Obsah Strategie rozvoje infrastruktury pro prostorové informace v ČR do roku 2020 (GeoInfoStrategie) Jiří Čtyroký, vedoucí Zpracovatelského týmu Prostorové informace jako součást digitální budoucnosti,

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

Č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

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

Inspiromat 7. Dokumentace místního akčního plánu vzdělávání

Inspiromat 7. Dokumentace místního akčního plánu vzdělávání Inspiromat 7 Dokumentace místního akčního plánu vzdělávání listopad 2017 DOKUMENTACE MAP Složka s kompletní dokumentací Místního akčního plánu vzdělávání bude v deskách a bude obsahovat: 1 Titulní list

Více

Otázky kurzu 4IT417 Řízení podnikové informatiky verze z 1/2/2009. 1.Podniková informatika pojmy a komponenty

Otázky kurzu 4IT417 Řízení podnikové informatiky verze z 1/2/2009. 1.Podniková informatika pojmy a komponenty Otázky kurzu 4IT417 Řízení podnikové informatiky verze z 1/2/2009 1.Podniková informatika pojmy a komponenty (1) Objasněte pojmy: IS, ICT, ICT služba, ICT proces, ICT zdroj. Jakou dokumentaci k ICT službám,

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

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

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

Přehled změn ke 12. květnu Položka Popis změny Zdůvodnění změny

Přehled změn ke 12. květnu Položka Popis změny Zdůvodnění změny Ministerstvo pro místní rozvoj České republiky oznamuje změny v 10. výzvě k předkládání žádostí o podporu z Integrovaného regionálního operačního programu KYBERNETICKÁ BEZPEČNOST Přehled změn ke 12. květnu

Více