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

Save this PDF as:
 WORD  PNG  TXT  JPG

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"

Transkript

1 Metodický pokyn k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu Odbor Hlavního architekta egovernmentu MV Praha, Únor 2016 verze 4.01

2 Obsah Úvodní informace a pokyny Základní podmínky projektu Úvodní informace zpracovatele žádosti Charakteristika projektu Souhlasy zpracovatele Architektonické informace o projektu Naplnění Strategických cílů rozvoje ICT služeb Dodržení architektonických principů NA VS ČR Enterprise architektura projektu dle pravidel NA VS ČR Motivační architektura strategie a směrování Efektivita projektu výkonnostní architektura Byznys architektura - poskytování veřejných služeb Architektura informační systémů 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 Architektura (pozice) navrhovaného řešení v kontextu strategické architektury úřadu a navazujících subjektů veřejné správy Pozice řešení v byznys architektuře úřadu Pozice řešení v architektuře informačních systémů úřadu Pozice řešení v IT technologické architektuře úřadu Pozice řešení v komunikační infrastruktuře úřadu Architektura (pozice) navrhovaného řešení v kontextu egovernmentu - způsob využití sdílených prvků architektury úřadu a egovernmentu Využití sdílených prvků egovernmentu v byznys architektuře úřadu Využití sdílených prvků egovernmentu v architektuře IS úřadu Využití sdílených prvků egovernmentu v IT technologické architektuře úřadu Využití sdílených prvků egovernmentu v komunikační infrastruktuře úřadu Architektura řešení projektu Plán dlouhodobého rozvoje architektury projektu (Roadmapa) Etapy a milníky plánu zavedení architektury projektu Ostatní klíčové milníky úřadu související s projektem Ostatní klíčové milníky egovernmentu související s projektem Další údaje o projektu Potřebnost a výstupy projektu Připravenost projektu k realizaci Technická připravenost projektu

3 Finanční připravenost projektu Personální připravenost projektu Metodická připravenost projektu Podmínky a průběh realizace projektu Ekonomické parametry projektu Hodnota výdajů a ekonomická náročnost projektu Personální náročnost projektu Analýza rizik a negativních důsledků Identifikace rizik neúspěchu projektu Identifikace negativních důsledků projektu Plán údržby, dlouhodobá udržitelnost výstupů projektu Plánovaná životnost jednotlivých výstupů projektu Plánovaná péče o výstupy projektu v jednotlivých letech životnosti Připravenost na řízené ukončení životnosti výstupu projektu a případný přechod na další řešení Přehled Požadovaných výjimek Výjimky z naplnění cílů Strategie rozvoje ICT služeb Výjimky z dodržení architektonických principů Výjimky z požadavku na využití sdílených prvků architektury úřadu Výjimky z požadavku na využití sdílených prvků egovernmentu ČR Výjimky z dodržení architektonických vzorů Upozornění a doporučení Přílohy Příloha 1: Vzor žádosti o udělení výjimky Historie verzí Verze Datum Poznámky k verzi Verze schválená OHA Změny v konzistenci dokumentů formuláře a pokynu Úpravy pravopisu Úpravy popisu tabulky byznys architektury, tabulky shody s předpisy a popisu zainteresovaných osob, zapracované zpřesnění postupu odhadu hodnoty projektu a TCO Úprava podpisových doložek 3

4 Ú 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 ruky, vznikl na základě úkolu uloženého ministru vnitra usnesením vlády České republiky ze dne č. 889 k dalšímu rozvoji informačních a komunikačních technologií služeb veřejné správy, vč. přílohy č. 2 - Základní zásady postupu pro 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ě. Vzor žádosti se sestává ze dvou samostatných dokumentů 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). Žádost je podána MVČR, Odboru Hlavního architekta egovernmentu (OHA) do datové schránky ID: 6bnaawp. Přílohou Žádosti je vyplněný formulář. Proces posuzování projektů je následující. OHA zkontroluje kompletnost žádosti, v případě nedostatků si vyžádá doplnění, a rozhodne o délce lhůty: Základní projekty lhůta na schválení do 30 kalendářních dnů nebo Složité projekty lhůta na schválení do 60 kalendářních dnů Lhůta na vyřízení začíná běžet převzetím kompletní žádosti. V průběhu posouzení si OHA může vyžádat doplnění nebo vysvětlení ze strany Žadatele, po tuto dobu je běh lhůty pozastaven. OHA vydá stanovisko, které zašle zpět prostřednictvím ISDS na adresu původního Žadatele. Pro urychlení vyřízení je možné, v odůvodněných případech, konzultovat projekt ještě před podáním žádosti samotné. Způsob vyplnění Formuláře žádosti. Formulář žádosti obsahuje dva typy položek k vyplnění: tabulku, do které vkládejte požadované informace do příslušných buněk, prostor pro vložení diagramu, označený <zde vložte diagram(y)>. Vzor žádosti (Formulář i Metodický pokyn) jsou univerzálně použitelné a robustní tak, aby pokryly celé spektrum možných projektů, na které se vztahuje schvalovací povinnost. Vzor žádosti je nutno aplikovat pro každý projekt individuálně a metodické postupy použít přiměřeně ke složitosti a zaměření projektu. V případě, že není, ta která část Formuláře, pro váš projekt nebo kontext projektu relevantní, uveďte není relevantní, aby bylo zřejmé, že jste položku záměrně nevyplnili z důvodu, že nemá smysl. V případě, že váš projekt není v souladu s: a) strategickými cíli rozvoje služeb VS a ICT služeb 1 b) architektonickými principy Národní architektury VS, viz kap 2.2 Vzoru žádosti c) architektonickými vzory sdílených služeb egovernmentu 2, ale přesto existuje objektivní důvod realizovat jej žádaným způsobem, uveďte do předmětné části formuláře, že žádáte o výjimku, a pro každou takovou vyplňte žádost o udělení výjimky, kterou naleznete v příloze č. 1 Formuláře žádosti. 1 Viz. Strategie rozvoje ICT služeb veřejné správy a její opatření na zefektivnění ICT služeb, přijatá usnesením vlády ze dne č

5 1. Z Á K L A D N Í P O D M Í N K Y P R O J E K T U Podkapitoly této úvodní kapitoly mají charakter hlavičky či krycího listu celé žádosti o stanovisko OHA. Nachází se v nich vše podstatné o projektu na jediný pohled Úvodní informace zpracovatele žádosti Zde uveďte základní identifikační údaje Vaší organizace, která podle usnesení vlády vystupuje současně jako žadatel i jako zpracovatel. Obchodní jméno, sídlo, IČO a kód organizace zpracovatele. Jméno, příjmení a kontakty na statutárního zástupce. Jméno, příjmení a kontakty na kontaktní osobu pro projekt. Jméno, příjmení a kontakty na architekta/architekty projektu. Datum vypracování. Kód organizace je jednoznačné písmenné označení organizace veřejné správy, dostupné například v rámci údajů seznamu datových stránek na portálu veřejné správy zde: a jeho údaj se nachází po rozkliknuti organizace na záložce doplňkové údaje. Statutárním zástupcem se pro účely žádosti o výjimku myslí osoba, oprávněná podpisovým řádem úřadu schválit a podat takovou žádost Charakteristika projektu Zde uveďte výpis souhrnných údajů Vašeho projektu ze žádosti: Název projektu. Hlavní cíl projektu. Zainteresovaní - Kdo má hlavní zájem 3 na úspěchu projektu. Místo realizace projektu. Termíny plánovaného zahájení a dokončení realizace projektu. Shrnutí synergických nebo komplementárních vazeb projektu. Shrnutí shody se základními principy Národní architektury egovernmentu. Určení věcného správce, technického správce a provozovatele. 4 Externí výdaje na ICT spojené s projektem 5 - roční průměr a počet let pro roční průměr Externí výdaje na ICT spojené s projektem za 5 let Celkové náklady vlastnictví (TCO) za 5 let 6 Personální náročnost. Jako zainteresované zde do souhrnu uveďte ty vybrané osoby, nejčastěji v úřadu zpracovatele, které mají zájem a současně vliv na úspěch projektu, tj. zejména tzv. sponzora a případně několik dalších. Plný seznam klíčových zainteresovaných uveďte v kapitole Definice: Při uplatnění všech, v metodice TCO uvedených principů, na odstavec d) citovaných Základních zásad platí, že projekt (záměr) se stává relevantním pro povinnost podat žádost o stanovisko OHA tehdy, pokud souhrn všech nově zamýšlených, s vlastnictvím nebo užíváním nového řešení, nebo jeho nové části, spojených externích výdajů na přípravu, pořízení, úpravu, zavedení a 5 leté (případně kratší) období užívání, udržování a rozvíjení ICT služby k žádosti předmětného řešení přesáhne hodnotu 30 mil. Kč bez DPH (případně úměrně době užívání hodnotu alikvotně nižší), resp. roční průměr takových souhrnných výdajů, vztažený k rozhodné době užívání služby (5, případně méně let) přesáhne hodnotu 6 mil. Kč bez DPH ročně. 3 Z angl. Stakeholders, zainteresovaní na projektu 4 Jednotlivé role jsou definovány ve Strategii rozvoje ICT služeb VS a její opatření na zefektivění služeb kapitola 5.1 str Podle Čl. 2, odst. d) Přílohy 2 usnesení vlády ze dne 2. listopadu 2015 č. 889: Základní zásady 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 vyšší než 6 mil. Kč ročně. 6 Podle Čl. 2, odst. e) tamtéž 5

6 Relevantní pro žádost (ani pro výpočet její hodnoty) tedy nejsou takové budoucí výdaje, které již plynou z dříve uzavřených závazků (smluv) zpracovatele žádosti, například opakovaná platba licence na údržbu, protože nepředstavují žádný nový záměr. Pro vyplnění odhadu průměrných plánovaných výdajů projektu uveďte údaj, odpovídající podílu souhrnu všech externích výdajů za období přípravy a za deklarovaný počet let užívání ICT služby a tohoto počtu let. Jako odhad celkové hodnoty projektu za 5 let (nebo výjimečně kratší dobu životnosti projektu) uveďte souhrnný údaj externích výdajů použitý pro nalezení ročního průměru. Pro stanovení souhrnu plánovaných výdajů použijte libovolnou účelovou, druhovou (účetní 7 ) či jinou strukturu výdajů, která Vám pomůže snadno a správně nalézt odhad výdajů, odpovídající plně výše uvedené definici. Takto můžete postupovat zejména tehdy, máte-li pocit, že váš záměr hranici relevance pro žádost o stanovisko OHA nepřekročí a vy tedy pravděpodobně nebudete plánovat kompletní TCO v dalších pasážích žádosti. Tento odhadovaný souhrn výdajů bude při zpracování žádosti následně, jakožto externí náklady, rozdělen při plánování TCO do jednotlivých nákladových kategorií podle životního cyklu řešení v tabule TCO, viz kap 3.4 Formuláře žádosti, sloupec 3 kapitola Pokud je z velikosti řešení zjevné, že budete podávat žádost, doporučujeme obrácený postup. Začněte připravovat žádost, její architekturu, její roadmapu a kompletní plán TCO, interních a externích nákladů. Pak vezměte součet externích výdajů ve sloupci 3 z tabulky v kapitole a tuto hodnotu uplatněte jako rozhodnou hodnotu výdajů pro relevanci žádosti v přehledové tabulce v kapitole 1.2 Formuláře žádosti, jak v celkové výši, tak ji použijte pro výpočet průměru za rozhodnou dobu. Jako celkové náklady vlastnictví za 5 let (nebo případně skutečnou kratší, výše uvedenou rozhodnou dobu, odpovídající životnosti řešení) v této souhrnné tabulce uveďte hodnotu součtového řádku ve sloupci 4 tabulky TCO v kapitole Rozhodnou dobou 5 let (nebo v odůvodněných případech méně) se myslí doba skutečného (produktivního) užívání ICT služby, ať již byla služba pořízena jakkoli. U řešení, jehož potřeba (podporovaná veřejná služba) pomine dříve než za 5 let nebo jehož životnost skončí dříve, a to bez náhrady navazujícím řešením, tj. u nějž přestane být ICT služba využívána dříve než za 5 let, se jako doba TCO, a jako rozhodná doba pro výši výdajů pro žádost o stanovisko OHA, uvažuje tato skutečná kratší doba užívání (provozu). Tato kratší doba slouží v tom případě také pro výpočet odpovídajících průměrných ročních výdajů Všechny finanční hodnoty výše jsou myšleny bez DPH Souhlasy zpracovatele Zde uveďte souhlasy osob zodpovědných za projekt v uvedených rolích, s obsahem a podáním žádosti o stanovisko OHA: Souhlas sponzora (doporučený) Souhlas ředitele informatiky Souhlas statutárního zástupce úřadu Sponzorem se stejně jako v předchozí kapitole myslí klíčový stakeholder, ten/ta, kdo má největší zájem na úspěchu projektu, aktivně v jeho prospěch vystupuje a ve své manažerské pozici může zásadními rozhodnutími a podporou úspěch projektu ovlivnit. Tyto podpisové doložky můžete vyplnit různými způsoby: 1) Vyplnit jména a datumy a soubor následně podepsat elektronicky 2) Vytisknout pouze danou stránku, vyplnit a podepsat ručně a následně vložit zpět do dokumentu jako přílohu 7 Například podle tabulky rozpočtové skladby ICT projektu dle NKÚ, kterou některé úřady pro takový účel používají. 6

7 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. Ostatní atributy definice projektu se nacházejí v kapitole 0-7

8 Další údaje o projektu. Struktura architektonické části dokumentu vychází ze struktury domén obsahu Národní architektury VS ČR, viz také Metodika modelování NA VS ČR 8. Tato struktura se skládá ze čtyř základních bloků informací. Vertikální domény představují všechny formy (složky) motivace organizace ke konání veřejné služby a k její změně. Jsou to: Strategie a směrování Kam chceme jít? - jaké politiky si úřad naplánoval a proč Výkonnost a jakost Jak dobří chceme být v tom, co děláme? jaká máme měřítka výkonnosti a jakosti Rizika a bezpečnost Čeho se chceme vyvarovat a jak se proti tomu bráníme? Shoda s pravidly, standardizace a udržitelnost Jaká pravidla jsme si pro svou cestu stanovili (či nám byla dána)? Další oblastí informací o struktuře a fungování úřadu je vlastní výkon všeho, co dělá. Tedy: Kdo jsme a co děláme? To je obsaženo ve žluté vrstvě tzv. byznys architektury, zde zvané opisem Architektura výkonu a provozu veřejné správy. Třetí nezbytnou součástí úřadu jsou jeho zdroje, aktiva (majetek, lidé a znalosti), potřebná pro tyto činnosti. Zde, při použití architektury pro podporu řízení IT projektů se jedná pouze o tzv. informační a technologická aktiva, modelovaná v tyrkysových a zelených horizontálních vrstvách architektury. Poslední oblastí architektonických informací je tzv. Roadmapa, tedy plán cesty k cílové architektuře úřadu přes jednotlivé klíčové milníky a jejich přechodné architektury. Tato struktura obsahu architektury se uplatní jak při popisu obsahu projektu, tak v širších kontextech celého úřadu, jeho resortu či krajské korporace a celého českého egovernmentu a vybraných prvků z EU. Souhrn těchto všech tvoří tzv. Národní architekturu veřejné správy ČR. Pro zjednodušení struktury žádosti jsou některé vyšší architektury vynechány. Pokud je to důležité, připište informace o resortu a korporaci k architektuře úřadu a informace o EU k architektuře egovernmentu. Pro účely této Žádosti o stanovisko, jsou pro zjednodušení u popisu širšího kontextu projektu také vynechány motivační, vertikální domény architektury, viz následující schéma. Zde jsou do jednotlivých oblastí obsahu vepsána odpovídající čísla kapitol Žádosti: 8 Metodika je společně s ostatními materiály k Žádosti dostupná na webových stránkách 8

9 Pod bloky tzv. Enterprise architektury (architektury úřadu a širšího kontextu), které odpovídají na existenciální otázku: Co je, respektive co bude?, se nachází blok tzv. architektur řešení, které odpovídají na otázku: Jak to funguje, respektive má fungovat? Architektura řešení je však v této Žádosti, na rozdíl od například Zadávací dokumentace podle Zákona o veřejných zakázkách, vyžadována pouze v minimální míře, slouží pro prokázání, zda a jakým způsobem se v architektuře budoucího řešení uplatní povinné Architektonické vzory sdílených služeb egovernmentu, které mírou svého detailu odpovídají právě architektuře řešení Naplnění Strategických cílů rozvoje ICT služeb Všechny předkládané ICT projekty po již musí odpovídat duchu i znění platné ICT strategie státu, kterou je aktuálně Strategie rozvoje ICT služeb veřejné správy a její opatření na zefektivnění veřejných služeb, schválená vládou ČR dne , usnesením č Uveďte, zda a čím předkládaný projekt naplňuje jednotlivé cíle Strategie rozvoje ICT služeb. Pokud je Váš projekt pro naplnění cílů Strategie nerelevantní, pak uveďte <nerelevantní> a přidejte zdůvodnění, proč se tak domníváte - například, že jde o IT komoditu typu tonery, která z podstaty není reformní. Nemůžete-li prokázat soulad projektu s cíli Strategie, uveďte do tabulky, že žádáte o výjimku: <žádáme výjimku>, a ve formuláři dle dané přílohy 6.1 zformulujte text a parametry této výjimky

10 2.2. 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. Uveďte do tabulky, zda a čím předkládaný projekt naplňuje jednotlivé architektonické principy: Název principu Znění principu 10 Dostupnost 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. Použitelnost 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. Důvěryhodnost 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 k datům a službám samotným. Spolupráce a Elektronické služby veřejné správy jsou navrhovány a budovány primárně na principu sdílení spolupráce a sdílení informací a zdrojů mezi úřady veřejné správy. Udržitelnost 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é. Technologická neutralita 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ů. Při tom se řiďte zde uvedenými důsledky principů, tj. právě tím, jak se mají architektonické principy promítat do projektů. Prověřte, zda a jak jsou u předloženého projektu splněna níže uvedená tvrzení: Název principu Dostupnost Použitelnost Důvěryhodnost Důsledky 11 principu pro projekty Všechny nové nebo zásadně měněné veřejné služby musí být navrhovány jako vnitřně plně elektronické. Každá služba musí být realizovatelná rovnocenně přes povinná elektronická rozhraní egovernmentu, samoobslužná (on-line i off-line) a asistovaná. Uživatelům musí být umožněno učinit podání vůči veřejné správě v plně elektronické podobě (a bez místní příslušnosti), bez nutnosti následného dokládání papírových dokumentů a kdykoli (kromě okamžiků nezbytné údržby systémů). Služby musí být koncipovány tak, aby všechny postupy při jejich využití byly srozumitelné, jednotné, služby byly snadno a rychle použitelné, využívaly inteligentní a interaktivní formuláře s automatickým doplněním známých informací a podporou on-line finančních transakcí a vedly k automatickému zpracování informací od klienta. Pro zajištění opakované použitelnosti je nutné, aby uživatelům na straně veřejnosti i veřejné správy byla dostupná plná historie vzájemné komunikace, úplný přehled v minulosti řešených souvisejících životních situací a archiv všech relevantních dokladů a dokumentů. Služby a jejich IT podpora musí být koncipovány tak, aby mohly být v případě spolupráce úřadů na řešení životní situace klienta řazeny (orchestrovány) do společného komplexního automatizovaného řešení této situace. Procesní i informační design nových služeb musí zajistit, aby vzájemně vyměňované informace (mezi klientem a úřadem i mezi úřady navzájem) byly spolehlivé, přesné, relevantní a aktuální. Odesílatel musí mít jistotu, že elektronicky odesílané informace budou doručeny, nebo že je lze z pohledu právních důsledků za doručené považovat. Obdobně to platí pro platnost a závaznost elektronicky obdržených dokumentů od VS. 10 Z angl. Statement (volně) 11 Z angl. Implications (dle TOGAF, volně přeloženo) 10

11 Název principu Transparentnost Bezpečnost Spolupráce sdílení Udržitelnost Technologická neutralita a Důsledky 11 principu pro projekty Elektronické služby veřejné správy musí využívat jednotný důvěryhodný identitní prostor pro klienty veřejné správy (i pro úředníky), jakmile bude k dispozici, a podporovat využívání elektronické identity. Při tvorbě koncepčních materiálů v oblasti rozvoje služeb veřejné správy musí být vždy jejich součástí i principy zajištění zpětné vazby od veřejnosti a mechanismy jejího promítnutí do výsledné koncepce. Nové služby musí být vždy koncipovány s ohledem na požadavek na publikování veřejných dat v adekvátním formátu. Veřejnosti musí být zajištěn přístup k výstupům prováděných auditů výkonu služeb veřejné správy a jiných forem hodnocení jejich výkonu. Prostředky poskytování elektronických veřejných služeb musí být adekvátně chráněny před poškozením a zneužitím. U elektronických veřejných služeb musí být zajištěna adekvátní ochrana osobních údajů a utajovaných skutečností. Služby musí být vždy koncipovány jako auditovatelné a pro tento účel musí vytvářet adekvátní auditní stopu. Nové služby (nebo jejich součásti) musí být navrhovány jako univerzální, sdílené, opakovatelně použitelné, bez omezujících vazeb na specifické agendy. Návrhy služeb veřejné správy a jejich IT podpory musí přednostně využívat existující stavební kameny, již vybudované ve shodě s principy sdílené architektury veřejné správy ČR. Na návrzích služeb veřejné správy se musí podílet ve vzájemné spolupráci odborné týmy napříč veřejnou správou. Řešení podporující výkon veřejné služby nesmí fixovat pouze stávající podobu podporovaných procesů a pravidel a musí být koncipována jako modulární, škálovatelná a parametrizovatelná. Sdílení nebo nákup nové standardní služby musí být vždy upřednostněno před vývojem vlastní služby. Dílčí vývoj na míru je přípustný pouze pro prokazatelnou lokální zvláštnost, přinášející VS výhodu. Nová nebo zásadně pozměněná IT řešení mají být vytvářena vždy výhradně na podporu inovovaných služeb egovernmentu. Není záměrem investovat do nových řešení na podporu nezměněných, zastaralých procesů a služeb. Řešení podporující výkon veřejné služby musí být navržena pro efektivní údržbu a rozvoj, tj. musí být standardizovaná, rozšiřitelná, integrovatelná, upgradovatelná a podporovatelná i vlastními silami úřadu. Služby veřejné správy musí být dostupné na všech běžně používaných platformách, stejně jako tomu je dnes u všech ostatních informačních řešení v soukromém sektoru. Řešení egovernmentu musí být vybudována na kvalitní, otevřené architektuře tak, aby bylo možné vyměňovat jednotlivé prvky řešení bez nutnosti měnit jejich okolí. Technologická neutralita musí být zajištěna jak při nezávislém využívání služeb mezi vrstvami architektur, tak při záměnách prvků uvnitř vrstvy. Oporou pro hledání odpovědi k vyplnění jsou Vám otázky ve formuláři, do nichž byly důsledky principů pro přiblížení přeformulovány. Uveďte tedy do tabulky, do řádku s názvem principu, zda předkládaný projekt naplňuje jednotlivé architektonické principy. Pod to, k jednotlivým otázkám, stručně uveďte, jakým způsobem předkládané řešení principy naplní. Pokud je Váš projekt pro uplatnění pravidla nerelevantní, pak uveďte <nerelevantní> a přidejte zdůvodnění, proč se tak domníváte - například, že jde o IT komoditu typu tonery, která z podstaty není reformní. Nemůžete-li prokázat soulad projektu s principy, uveďte do tabulky, že žádáte o výjimku: <žádáme výjimku>, a ve formuláři dle dané přílohy 6.1 zformulujte text a parametry této výjimky. 11

12 2.3. Enterprise architektura projektu dle pravidel NA VS ČR Popište a graficky znázorněte schopnostní architekturu úřadu 12 v oblastech spojených s předkládaným projektem, také zvanou úvodní EA projektu 13. Dělení architektur úřadu vysvětluje podrobněji Metodika modelování NA VS ČR a ukazuje jej následující schéma: Architektura schopností - představuje dílčí architekturu úřadu, sloužící pro podrobnější porozumění určité oblasti úřadu a jeho skupině externích, interních nebo průřezových schopností. Například schopnosti přidělovat a spravovat identitu občanů, schopnosti provozovat nemovitosti úřadu nebo schopnosti spravovat dokumenty, spojené s kteroukoli jinou hlavní schopností. Architektura schopností je nejčastěji vytvářena ve spojení s nějakou předpokládanou, ve vyšších architekturách identifikovanou změnou, kterou je potřeba na úrovni podnikové architektury rozpracovat do příležitostí a plánu změn dříve, než budou zahájeny práce na hledání detailní architektury možných řešení. Právě takovou architekturu byste nyní měli předkládat pro Žádost o Stanovisko OHA. Místo vlastní architektury projektu v tomto dokumentu, v kontextu architektury celého úřadu a celého egovernmentu ČR, ukazuje vybarvená část následujícího schématu. 12 Z angl. Government Enterprise Architecture Capability Architecture 13 Z angl. PSA Project Start Architecture 12

13 Již popsané prvky architektury pak v následných digramech mají barvu světle šedou, dosud nepopsané bílou. Vlastní architektonické informace uveďte v následujících podkapitolách. Každá doména architektury je ve shodě s Metodikou modelování NA VS ČR popsána pomocí katalogů základních objektů dané domény, grafických diagramů a vysvětlujícího textového bloku. U prvků architektury řešení informačního systému (aplikační, technologická a komunikační architektura) uveďte ve vysvětlujících textech na konci každé podkapitoly, mezi jakými variantami schopnostní architektury pro projekt bylo rozhodováno a proč byla vybrána právě předkládaná varianta. 13

14 Motivační architektura strategie a směrování Tato část architektury projektu objasňuje, pro jakou změnu je projekt navržen, co změnu vyvolalo, kdo stojí o její realizaci a jak se pozná, že se to podařilo. Tedy: Kterým směrem změn se úřad vydává? Katalog zainteresovaných stran (stakeholders): Uveďte jména, funkce, potřeby a zájmy (z pohledu přínosů projektu) tzv. zájmových skupin, zejména zainteresovaných jednotlivců 14. Zvláště pak zdůrazněte tzv. výkonného sponzora, tj. osobnost z vedení úřadu, která je klíčovým zadavatelem, podporovatelem projektu, má zásadní zájem na jeho úspěchu a nejvíce se zasazuje za jeho realizaci. Dále uveďte ostatní klíčové manažerské i politické osobnosti, osobně nebo funkčně zainteresované na projektu, jejich zájmy, potřeby a cíle spojené s realizací projektu. Zde neuvádějte cílové skupiny uživatelů či jejich role, pro ně určena kapitola Katalog motivátorů a potřeb: Uveďte motivátor 15, tj. externí vliv či veřejnou potřebu/potřeby, na něž úřad reaguje politickou či strategickou iniciativou. Zde motivátor ve významu externího (úřadem přímo neovlivnitelného vlivu) může mít podobu například, nárůstu nezaměstnanosti, válečného stavu v sousední zemi, pokles zásob podzemní vody apod. Katalog strategických cílů: Dále uveďte s projektem spojené strategické cíle 16 této (výše uvedené) politiky / iniciativy. Takové cíle nejde realizovat přímo, nýbrž prostřednictvím splnění dílčích úkolů, viz následující tabulka Katalog proveditelných úkolů: Zde uveďte s projektem splněné proveditelné cíle / úkoly 17, takové, jejichž splněním lze realizovat strategické cíle politiky / iniciativy. Katalog metrik: Uveďte (byznys a politické) metriky, pomocí nichž se pozná, že celá politika byla úspěšná, stanovené cíle a úkoly splněné. Zvláště označte kritéria, která budou sloužit jako měřítko úspěchu implementace předkládaného projektu. Modely motivační architektury (NEPOVINNÉ): Zde vložte diagramy vzájemných vztahů výše uvedených objektů motivace ke změně architektury, zahrnuté do projektu. Tedy strategické iniciativy (politiky) ve vztahu k motivátorům, na něž reagují, strategické cíle a proveditelné úkoly jednotlivých iniciativ, případně vazby cílů a architektonických principů egovernmentu a úřadu. Vysvětlení motivační architektury projektu: Zde 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í. 14 Z angl. Stakeholders (dle TOGAF) 15 Z angl. Driver (dle TOGAF) 16 Z angl. Goal (dle TOGAF) 17 Z angl. Objectives (dle TOGAF) 14

15 Efektivita projektu výkonnostní architektura Tato část architektury projektu objasňuje, s jakými přínosy je projekt spojen, jaké ukazatele efektivity a kvality jsou pro projekt relevantní, pokud nějaké a jak je možné je měřit. Tedy: Jak dobří chceme díky projektu být? Rozdělení ukazatelů výkonnosti vychází z osvědčeného tzv. Logického modelu řízení výkonnosti a zodpovědnosti, viz následující schéma. Z něho je jasně 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. Katalog ukazatelů výkonnosti a kvality: Uveďte ukazatele zlepšení výkonnosti předmětné, projektem implementované nebo měněné ukazatele zlepšení výkonnosti předmětné veřejné služby a jejich očekávané hodnoty (míra zlepšení) 3E. Zvýšení hospodárnosti 18 čerpání zdrojů pro veřejnou službu Zvýšení účinnosti 19 práce zdrojů při tvorbě výstupů Zvýšení účelnosti 20 výstupů služby pro dosažení výsledků 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. Katalog výsledků, dopadů a multiplikačních efektů politiky (strategické iniciativy), podpořené předloženým projektem: Uveďte přehled výsledků a dopadů projektu a očekávané významné multiplikační efekty projektu (např. nepřímo vytvořená pracovní místa nebo poptávka), jejich kvantifikovaný odhad. Pro orientaci mezi typy ukazatelů využijte následující logický model řízení výkonnosti veřejné správy. Vysvětlení výkonnostní architektury projektu: Zde 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í. 18 Hospodárnost (Economy) vztahuje se k nákladům na zdroje pro spotřebovávané vstupy. Metriky hospodárnost se používají k posouzení, zda za pořízení nezbytných zdrojů je placena odpovídající cena. 19 Účinnost (Efficiency) účinnost představuje vztah mezi vstupy a výstupy, je poměrem dosažených výstupů ke spotřebovaným vstupům. Účinnost je výrazem dimenze dělat věci správně a ukazuje na výkonnost ve smyslu způsobu, jakým je činnost uskutečňována. 20 Účelnost (Effectiveness) je výrazem míry jakou produkované výstupy vedou k očekávaným výsledkům. Metriky účelnosti se zaměřují na sílu vztahu mezi provedenou intervencí a dosaženým výsledkem. Účelnost je výrazem dimenze dělat správné věci a ukazuje na výkonnost ve smyslu volby činnosti, která je uskutečňována. 15

16 Byznys architektura - poskytování veřejných služeb 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. Externí nebo interní činnosti úřadu mohou být popsány jako tzv. funkce, tj. konání, které má někdo v popisu práce, ale které neřídíme ani jako službu s SLA 21, ani je neřídíme jako proces. Známé procesy a služby je možno jako doplněk identifikovaných funkcí uvést. Tedy: Kdo jsme, kolik nás je a co děláme v rámci projektu? Katalog organizačních jednotek, aktérů a rolí: Uveďte, které OVM a které jejich organizační jednotky a jakékoli další subjekty budou zapojeny do poskytování veřejné služby podporované projektem. Uveďte typické a významné aktéry, jejich role jako uživatelů řešení, poskytovatelů a klientů veřejné služby. Uveďte u organizací, rolí nebo typů aktérů jaký v těchto kategoriích odhadujete počet uživatelů informačních systémů, které jsou předmětem posuzovaného projektu. Je to důležitá informace o jeho velikosti i o požadavcích na jeho architekturu. 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. Dokážete-li to, vyplňte co nejlépe ve všech kategoriích. Katalog funkcí, procesů veřejné správy: Uveďte, jaké činnosti výkonu veřejné správy předložený projekt zavádí nebo mění. Tyto činnosti popište jako interní funkce, které budou řešením podporovány, a k tomu jako procesy (sekvence funkcí), pokud v úřadu budou cílově tyto funkce jako procesy řízeny. Katalog služeb veřejné správy: Uveďte, jaké služby 22 veřejné správy předložený projekt zavádí nebo mění. Služby popište jako externí výkon směrem ke klientovi (občanovi, organizaci) s tím, že uvedete, kdo službu poskytuje (typicky která role), kdo jí využívá a přijímá její hodnotu (která role) a přes jaké rozhraní (komunikační, obslužný kanál). Je to velmi důležité, neboť většina principů a požadavků architektury egovernmentu je spojena právě se službymi VS, zejména s elektronickými službami VS. Katalog komunikačních (obslužných) rozhraní, kanálů: Uveďte všechna komunikační rozhraní, kterými budou klienti službu veřejné správy využívat. Přitom se vyjádřete k míře využití povinných elektronických rozhraní, on-line i off-line, samoobslužných i asistovaných. Uveďte odhadovaný počet klientů (ostatních úředníků) obsluhovaných jednotlivými kanály ročně. Přitom berte v úvahu vývoj této veřejné služby v průběhu celých 5 let a očekávaný nárůst preference elektronických kanálů. Při velkých změnách využití kanálů na začátku a konci 5 letého období uveďte nejvyšší odhady a vysvětlete v popisu průběh změn. Pokud je Váš projekt pro využití povinných komunikačních rozhraní nerelevantní, pak uveďte <nerelevantní> a přidejte zdůvodnění, proč se tak domníváte - například, že předložený projekt z podstaty neužívá žádné komunikační rozhraní pro klienty veřejné správy. Nemůžete-li prokázat soulad projektu s požadovanými povinnými komunikačními rozhraními, uveďte do tabulky, že žádáte o výjimku: <žádáme výjimku>, a ve formuláři dle dané přílohy 6.1 zformulujte text a parametry této výjimky. Model byznys architektury (výkonu veřejné správy) pohled funkcí a/nebo procesní pohled: Zde vložte diagram 21 Z angl. Service Level Agreement, ujednání o parametrech úrovně poskytované služby. 22 Služba je nehmotná aktivita (funkce) přinášející přidanou hodnotu, vykonaná poskytovatelem pro příjemce na základě jeho požadavku a v souladu se vzájemnou dohodou (smlouvou) o parametrech služby, HRABĚ, Pavel. Úloha služeb v rámci podnikové architektury (Enterprise Architecture), článek v časopise Systémová integrace, číslo 1/

17 Model byznys architektury (výkonu veřejné správy) pohled organizační struktury: Zde vložte diagram Vysvětlení byznys architektury projektu: Zde 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í 17

18 Architektura informační systémů Podle Metodiky modelování NA VS ČR se doména (vrstva) architektury informačních systémů 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 IS 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ží. Tedy: Jaké IT aplikace podpoří změny našich veřejných služeb? Katalog aplikačních komponent a klíčových aplikačních funkcí: Uveďte všechny zaváděné nebo měněné aplikační komponenty podporující služby veřejné správy, zahrnuté do projektu, jejich základní aplikační funkce. Katalog aplikačních rozhraní: Uveďte aplikační rozhraní aplikačních komponent zahrnutých do projektu na ostatní s nimi integrované komponenty (interní a externí z pohledu úřadu) Modely aplikační architektury pohled struktury aplikací: Zde vložte diagram dle Metodiky, který ukazuje přehled aplikačních komponent, zahrnutých do projektu. Modely aplikační architektury pohled využití aplikací: Zde vložte diagram dle Metodiky, který ukazuje vazby komponentami zahrnutými do projektu (případně funkcemi a službami komponent) a odpovídajícími byznys funkcemi. Modely aplikační architektury pohled komunikace aplikací: Zde vložte diagram dle Metodiky, který ukazuje vazby rozhraní mezi komponentami projektu navzájem a mezi nimi a světem vně projektu. Vysvětlení aplikační architektury projektu: Zde 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í 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. Tedy: Co si budeme o svém konání evidovat a jak velká to bude evidence? Datovou architekturu je doporučeno postihnout tzv. na konceptuální úrovni, tj. pomocí byznys objektů. Komu je to bližší, může klíčové objekty představit na logické úrovni, tj. pomocí datových entit, jimiž budou informace o nich zachycovány. Katalog základních datových entit projektu: Uveďte, které důležité objekty a subjekty reality a práva jsou předmětem evidence navrhovaného informačního systému. Použijte <Objekt> a <Datový objekt>, k nim v tabulce připojte vysvětlující komentář. Uveďte, jak velké budou počty evidovaných objektů (občanů, případů, rozhodnutí platební výměrů apod.) celkem na konci 5 letého období. Model konceptuální datové architektury projektu: Zde vložte diagram podle Metodiky, tj. tzv. Pohled informační struktury. Nebo použijte jakoukoli Vám blízkou podobu konceptuálního, případně logického ERD 23 modelu základních objektů evidence v projektu. Vysvětlení datové architektury projektu: Zde 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í. 23 Z angl. Entity-Relationship Diagram. 18

19 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 egovenrmentu. Zaměřuje se na HW a systémový SW výpočetních technologií a na jejich technologické (tzv. platformové) funkce a služby. Tedy: Jaké IT technologie potřebujeme pro běh aplikací našeho projektu? Katalog technologických komponent a klíčových platformových funkcí: Uveďte technologické komponenty, případně funkce a platformové (IT) služby datového centra využívané pro příslušné aplikační komponenty, zahrnuté do projektu. Modely technologické architektury pohled struktury technologické architektury Zde vložte diagram dle Metodiky modelování Modely technologické architektury pohled využití technologické architektury Zde vložte diagram dle Metodiky modelování Vysvětlení IT technologické architektury projektu: Zde 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í 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. Tedy: Jakou infrastrukturu datových center a komunikace potřebujeme pro provoz IT technologie našeho projektu? Katalog infrastrukturních komponent, funkcí a služeb: Uveďte technologické komponenty a funkce, případně služby, komunikační infrastruktury využívané pro příslušné platformové a aplikační komponenty. Modely technologické architektury pohled struktury komunikační infrastruktury: Zde vložte diagram dle Metodiky modelování Modely technologické architektury pohled využití komunikační infrastruktury: Zde vložte diagram dle Metodiky modelování Vysvětlení architektury komunikační infrastruktury projektu: Zde 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í. 19

20 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 prostředky a opatřeními bude toto zabezpečení realizováno. Tedy: Co v mém projektu potřebuje chránit a co s tím pomůže? 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. Tedy: Která rizika a hrozby úřadu pomůže projekt zmírnit a čím? Katalog pasivní bezpečnostní architektury projektu: Uveďte, které navrhované objekty architektury úřadu, zahrnuté do rozsahu projektu, jsou cílem nějaké hrozby nebo jejich implementace vyžaduje konkrétní bezpečnostní opatření. Uveďte jaké. Katalog aktivní bezpečnostní architektury projektu: Uveďte, které hrozby a rizika úřadu pomáhá navrhovaný projekt zmírnit, jakým objektem architektury a jakým implementovaným způsobem, opatřením. Diagram bezpečnostní architektury Volitelně vložte objasňující diagram /diagramy pasivní i aktivní bezpečnostní architektury v libovolné notaci (verze ArchiMate 2.1 objekty bezpečnostní architektury dosud neobsahuje). Vysvětlení bezpečnostní architektury projektu: Zde 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í. V souvislosti s projekty egovernmentu hraje podstatnou roli otázka prokazování identity, její ověřování a přidělování oprávnění pro práci v informačních systémech podporujících službu veřejné správy. Proto je do části bezpečnostní architektury uvedena sekce, požadující vysvětlení, jak budou tyto funkce řešeny. Identifikace, autentizace a autorizace subjektů/uživatelů v jejich rolích Zde postupně vysvětlete: Jakými prostředky způsoby mohou subjekty /uživatelé prokázat svoji identitu (eop, uživatel ISDS apod.). Obecně platí, že dobrý projekt by měl umožňovat použití všech aktuálně dostupných a v blízké době připravovaných prostředků prokázání identity, fyzické a (zejména) elektronické. Jakým způsobem bude řešení ověřovat identitu subjektů/uživatelů v jejich rolích Jakým způsobem budou uživatelům v jejich rolích přidělována oprávnění pro IS 20

21 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, ať ji to jsou: a) právní předpisy a normy b) platné mezinárodní, národní nebo místní standardy c) dobrovolná pravidla pro dlouhodobou udržitelnost Tedy: Čím jsme při realizaci projektu definování a omezeni? Katalog předpisů a norem: Uveďte, které existující nebo teprve připravované právní a interní normy formalizují, regulují naplnění strategie projektem představovanými změnami. Uveďte jenom předpisy, které přímo formují architekturu řešení, spojeného s projektem, ať již ovlivňují architekturu jako celek nebo formují jenom některý dílčí prvek architektury (třeba dílčí proces nebo službu). Pak uveďte, který je to prvek a jaký na něj má předpis vliv. Uveďte, které další předpisy libovolné právní váhy mají přímý vliv na kterýkoli výše navrhovaný prvek řešení. Katalog v projektu uplatněných standardů: Uveďte, které mezinárodní, národní nebo místní standardy úřadu a dříve za standard architektury úřadu prohlášené stavební bloky architektury se v návrhu uplatnily. Cílem je jednak v architektuře uplatnit maximum standardů, a současně znovupoužít maximum v architektuře úřadu identifikovaných již existujících stavebních bloků řešení (SBB 24 ) nebo předem standardizovaných architektonických stavebních bloků (ABB 25 ). Katalog v návrhu znovupoužitých stavebních bloků řešení a úřadem standardizovaných architektonických stavebních bloků Uveďte, které existující stavební bloky řešení (SBB) nebo předem standardizované architektonické stavební bloky (ABB) se v navrhovaném řešení uplatní. Popřípadě můžete uvést, pokud t tak plánujete, které části vašeho řešení se mají stát opakovaně využitelnými stavebními bloky SBB/ABB pro navazující projekty úřadu, resortu či egovernmentu. Katalog zásad a opatření dlouhodobé udržitelnosti úřadu (nepovinný): Pokud v úřadu zavádíte či již uplatňujete zásady dlouhodobé udržitelnosti 26 úřadu, například dle metodiky CSR 27, uveďte (nepovinně), které zásady a která opatření jsou předkládaným projektem implementována a která mají na projekt významný vliv, a to v těchto oblastech: Ekonomická udržitelnost Sociální udržitelnost Environmentální udržitelnost Vysvětlení legislativy, standardizace a udržitelnosti architektury projektu: Zde 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í. 24 Z angl. Solution Building Blocks 25 Z angl. Architecture Building Blocks 26 Z angl. Sustainability 27 Z angl. Corporate Social Responsibility 21

22 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šší. Tedy: Jaká je vnitřní i vnější struktura služeb úřadu, zahrnutých do projektu? 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): Pokud v úřadu vztahy mezi vrstvami dosud neřídíte pomocí služeb 28, můžete vazby mezi vrstvami namodelovat napřímo (třeba aplikační komponenta -> byznys funkce) a služby (dočasně) přeskočit. S tím, že byste si ale měli dát za cíl, řízení pomocí služeb zavést. 28 Definice Služba je nehmotná aktivita (funkce) přinášející přidanou hodnotu, vykonaná poskytovatelem pro příjemce na základě jeho požadavku a v souladu se vzájemnou dohodou (smlouvou) o parametrech služby. (Hrabě, Úloha služeb v rámci podnikové architektury (Enterprise Architecture), 2010) 22

23 2.4. Architektura (pozice) navrhovaného řešení v kontextu strategické architektury úřadu a navazujících subjektů veřejné správy V následujících podkapitolách formuláře představte a vysvětlete pozici (kontext) navrhovaného projektu ve strategické (celkové) architektuře úřadu, resp. případně resortu nebo vyššího správního celku, jak jej ukazuje barevná část schématu dokumentu níže: Prokažte na každé z vrstev čtyřvrstvé vize architektury egovernmentu modelu vlastního úřadu 29, že navrhované řešení využívá všechny dostupné i potenciální sdílené komponenty a služby a že do architektury úřadu nevkládá duplicitu nebo multiplicitu. V případě, že projektem podporovanou veřejnou službu nelze efektivně poskytnout bez spolupráce s partnerskými úřady nebo pobočkovou sítí například na krajských úřadech nebo ORP, musí být v této kapitole žádosti představen model architektury celého rozšířeného řetězce dodávky veřejné služby 30. V budoucnu se analýza a prohlášení ve všech vrstvách bude týkat postupně i shody nebo podobnosti nejen v úřadu, ale i v resortu, korporaci, celém státu a případně EU typ modelu VLST, dle Metodiky modelování NA VS ČR 30 typ modelu ROZS 31 typ modelu SPOL 23

24 Pozice řešení v byznys architektuře úřadu V celkové klasifikované mapě hierarchie dovedností (nebo funkcí nebo procesů nebo služeb) úřadu představte, která část dovedností úřadu bude součástí rozsahu projektu a předmětem podpory implementovanými aplikačními komponentami. Tedy: Jak souvisí činnosti zahrnuté do projektu s jinými jinde v úřadu, resortu? Diagram byznys architektury hledisko funkcí veřejné správy (Mapa) zde vložte diagram Vysvětlení architektury projektu v kontextu byznys architektury úřadu: Zde vysvětlete například, jak souvisí implementovaná služba s ostatními službami úřadu. Nebo například jak nová služba využívá všechny sdílené komunikační kanály úřadu (přepážky, CzechPOINT, portál úřadu nebo PVS, apod.). Uveďte do kontextu všechny do projektu zahrnuté funkce (procesy či služby). Vysvětlete, jak případně tato služba souvisí s ostatními vykonávanými službami pracovišť rozšířeného řetězce. Prohlášení o jedinečnosti zaváděné byznys architektury: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou, pouze parametricky odlišnou, dovednost VS (funkci, proces nebo službu), jaká již v úřadu nebo rozšířeném řetězci existuje. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku> Pozice řešení v architektuře informačních systémů úřadu Pozice řešení v aplikační části architektury IS úřadu V celkové klasifikované mapě hierarchie aplikačních komponent (nebo funkcí nebo služeb) úřadu představte, která skupina aplikací bude součástí rozsahu projektu. Tedy: Jak souvisí aplikace zahrnuté do projektu se všemi ostatními aplikacemi úřadu, resortu? Diagram aplikační architektury IS hledisko portfolia aplikačních komponent a funkcí (Mapa) zde vložte diagram Vysvětlení architektury projektu v kontextu aplikační architektury úřadu: Zde vysvětlete 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). Současně v případě rozšířeného řetězce 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. Prohlášení o jedinečnosti zaváděné aplikační architektury IS: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou aplikační komponentu (funkci nebo službu), jaká již v úřadu nebo řetězci existuje. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku>. 24

25 Pozice řešení v datové části architektury IS úřadu V celkovém konceptuálním datovém modelu klíčových objektů evidence úřadu (nebo datových objektů) úřadu představte, které prvky datového modelu úřadu budou součástí rozsahu projektu a předmětem podpory veřejných služeb implementovanými aplikačními komponentami. Tedy: Jak souvisí datové objekty evidované projektem s hlavními datovými objekty, evidovanými kdekoli jinde v úřadu, resortu? Diagram datové architektury IS hledisko struktury informací nebo hledisko konceptuální ERD zde vložte diagram Vysvětlení architektury projektu v kontextu datové architektury úřadu: Zde vysvětlete například, jak souvisí navrhované evidované datové objekty s ostatními obdobnými datovými objekty úřadu nebo pracovišť řetězce (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. Současně v případě rozšířeného řetězce 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. Prohlášení o jedinečnosti zaváděné datové architektury IS: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádný stejný nebo podobný, pouze parametricky v některých atributech odlišný, datový objekt k témuž reálnému byznys objektu (třeba osoba), jaký již v úřadu nebo řetězci existuje. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku> Pozice řešení v IT technologické architektuře úřadu V celkové klasifikované mapě hierarchie technologických komponent (nebo funkcí nebo služeb) úřadu představte, která skupina technologických IT prvků bude součástí rozsahu projektu. Tedy: Jak souvisí IT technologické prvky (HW a systémový SW) se všemi ostatními takovými prvky v úřadu, resortu? Diagram technologické architektury hledisko portfolia IT technologických komponent a funkcí (Mapa) popisuje IT technologie z hlediska jejich typů bez ohledu na společné umístění, představuje logickou technologickou architekturu. zde vložte diagram Diagram technologické architektury tzv. infrastrukturní hledisko IT technologií (popisuje IT technologie podle logiky instalace zařízení společně a v lokalitách, představuje fyzickou technologickou architekturu) zde vložte diagram Vysvětlení architektury projektu v kontextu IT technologické architektury úřadu: Zde vysvětlete 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). Současně v případě rozšířeného řetězce 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. Prohlášení o jedinečnosti zaváděné IT technologické architektury IS: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou technologickou komponentu (funkci nebo službu), jaká již v úřadu nebo řetězci existuje. 25

26 Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku> Pozice řešení v komunikační infrastruktuře úřadu V celkové klasifikované mapě hierarchie technologických komponent (nebo funkcí nebo služeb) komunikační infrastruktury úřadu představte, která skupina technologických IT prvků bude součástí rozsahu projektu. Tedy: Jak souvisí infrastruktura projektu s celkovou infrastrukturou úřadu, resortu? Diagram technologické architektury hledisko portfolia infrastrukturních komunikačních komponent a funkcí (Mapa) popisuje komunikační infrastrukturu z hlediska jejích typů bez ohledu na společné umístění, představuje logickou infrastrukturní architekturu. zde vložte diagram Diagram technologické architektury tzv. infrastrukturní hledisko komunikační infrastruktury (popisuje komunikační technologie podle logiky instalace zařízení společně a v lokalitách, představuje fyzickou technologickou architekturu). zde vložte diagram Vysvětlení architektury projektu v kontextu architektury komunikační infrastruktury úřadu: Zde vysvětlete například, jak souvisí navrhované komunikační komponenty s ostatními obdobnými komponentami úřadu. Současně v případě rozšířeného řetězce 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. Prohlášení o jedinečnosti zaváděné architektury komunikační infrastruktury: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou komunikační infrastrukturní komponentu (funkci nebo službu), jaká již v úřadu nebo řetězci existuje. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku>. 26

27 2.5. Architektura (pozice) navrhovaného řešení v kontextu egovernmentu - způsob využití sdílených prvků architektury úřadu a egovernmentu Představte a vysvětlete pozici (kontext) navrhovaného projektu ve strategické (celkové) architektuře egovernmentu České republiky. Prokažte na každé z vrstev čtyřvrstvé vize architektury egovernmentu modelu vlastního úřadu (typ VLST), že navrhované řešení využívá všechny dostupné i potenciální (pro jeho kontext vhodné) sdílené komponenty a služby egovernmentu a že do architektury úřadu nevkládá duplicitu nebo multiplicitu vůči těmto centrálním sdíleným prvkům egovernmentu. V případě, že projektem podporovanou veřejnou službu nelze efektivně poskytnou bez spolupráce s partnerskými úřady nebo pobočkovou sítí, například na krajských úřadech nebo ORP, musí být v této kapitole žádosti míra využití sdílených prvků egovernmentu posouzena z pohledu celého rozšířeného řetězce dodávky veřejné služby (model typu ROZS), tedy jak tyto partnerské organizace využijí sdílené prvky egovernmentu. V budoucnu se analýza a prohlášení ve všech vrstvách bude týkat postupně i míry využití sdílených služeb Governmentu na úrovni EU. 27

28 Využití sdílených prvků egovernmentu v byznys architektuře úřadu Představte a vysvětlete, které byznys služby veřejné správy bude navrhovaný projekt využívat z nabídky sdílených služeb egovernmentu ČR. Přesvědčte se, že všechny navrhované funkce (procesy a služby) z byznys architektury projektu, kapitola 2.3.3, plně využívají nabídku sdílených služeb egovernmentu a nezavádějí lokální duplicitu. Prohlášení o plném využití sdílených služeb egovernmentu v byznys architektuře projektu: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou, pouze parametricky odlišnou, dovednost VS (funkci, proces nebo službu), jaká již je k dispozici jako sdílená služba egovernmentu. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku> Využití sdílených prvků egovernmentu v architektuře IS úřadu Využití sdílených prvků egovernmentu v aplikační části architektury IS úřadu Představte a vysvětlete, které aplikační služby veřejné správy bude navrhovaný projekt využívat z nabídky sdílených služeb egovernmentu ČR. Přesvědčte se, že všechny navrhované aplikační komponenty (funkce a služby) z aplikační architektury projektu, kapitola 0, plně využívají nabídku sdílených služeb egovernmentu a nezavádějí lokální duplicitu. Prohlášení o plném využití sdílených služeb egovernmentu v aplikační architektuře projektu: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou aplikační komponentu (funkci nebo službu), jaká již je k dispozici jako sdílená služba egovernmentu. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku> Využití sdílených prvků egovernmentu v datové části architektury IS úřadu Představte a vysvětlete, které byznys a datové objekty veřejné správy bude navrhovaný projekt využívat z nabídky sdíleného datového fondu egovernmentu ČR. Přesvědčte se, že všechny navrhované datové objekty z datové architektury projektu, kapitola 2.3.5, plně využívají nabídku sdíleného datového fondu egovernmentu, dodržují pravidla sdílení dat a nezavádějí lokální duplicitní evidenci. Prohlášení o plném využití sdílených služeb egovernmentu v datové architektuře projektu: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádný stejný nebo podobný, pouze parametricky v některých atributech odlišný, datový objekt k témuž reálnému byznys objektu (třeba osoba), jaký již je k dispozici jako součást sdíleného datového fondu egovernmentu. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku>. 28

29 Využití sdílených prvků egovernmentu v IT technologické architektuře úřadu Představte a vysvětlete, které IT technologické služby veřejné správy bude navrhovaný projekt využívat z nabídky sdílených služeb egovernmentu ČR. Přesvědčte se, že všechny navrhované IT technologické komponenty (funkce a služby) z technologické architektury projektu, kapitola 2.3.5, plně využívají nabídku sdílených služeb egovernmentu a nezavádějí lokální duplicitu. Prohlášení o plném využití sdílených služeb egovernmentu v IT technologické architektuře projektu: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou technologickou komponentu (funkci nebo službu), jaká již je k dispozici jako sdílená služba egovernmentu. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku> Využití sdílených prvků egovernmentu v komunikační infrastruktuře úřadu Představte a vysvětlete, které komunikační, infrastrukturní služby veřejné správy bude navrhovaný projekt využívat z nabídky sdílených služeb egovernmentu ČR. Přesvědčte se, že všechny navrhované infrastrukturní komunikační komponenty (funkce a služby) z komunikační architektury projektu, kapitola 2.3.6, plně využívají nabídku sdílených služeb egovernmentu a nezavádějí lokální duplicitu. Prohlášení o plném využití sdílených služeb egovernmentu v komunikační infrastruktuře projektu: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou komunikační infrastrukturní komponentu (funkci nebo službu), jaká již je k dispozici jako sdílená služba egovernmentu. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku>. 29

30 2.6. Architektura řešení projektu Prokažte vysvětlením a odpovídajícím diagramem architektury, jak jsou v architektuře předkládaného řešení dodrženy aktuální Architektonické vzory sdílených služeb egovernmentu, publikované dokumentem 32 OHA MV ČR. Viz barevná část pod dosud popsanými enterprise architekturami projektu, úřadu a egovernmentu. Uveďte, zda a jak předkládaný projekt dodržuje jednotlivé vzory architektury sdílených služeb egovernmentu. Pokud je Váš projekt pro dodržení vzoru nerelevantní, pak uveďte <nerelevantní> a přidejte zdůvodnění, proč se tak domníváte - například, že jde o projekt rozpočetnictví úřadu nebo znalostní báze utajovaných skutečností, kde se aktuální vzory neuplatní. Nemůžete-li prokázat soulad projektu se vzory, uveďte do tabulky, že žádáte o výjimku: <žádáme výjimku>, a ve formuláři dle dané přílohy 6.1 zformulujte text a parametry této výjimky. Diagram aplikační architektury hledisko spolupráce aplikací Architektonické diagramy by měly v korespondenci s Vaším textem v jednom nebo několika diagramech ukazovat, jak přesně se publikované vzory uplatní ve spojení s projektem nově zaváděnými nebo měněnými aplikačními komponentami

31 2.7. Plán dlouhodobého rozvoje architektury projektu (Roadmapa) Pokud na cestě rozvoje od současného stavu k cílovému stavu za 5 let je identifikováno jeden a více postupných přechodových stavů architektury, pak musí být přehledně představeny a vysvětleny v této kapitole. V rámci celého formuláře se etapou myslí jedna část celku, která má svoji architekturu. Etapa je tedy typicky samotný projekt. Každá etapa má své fáze. V rámci projektu jakožto etapy jsou to typicky fáze příprava, realizace, ukončení. Tyto fáze jsou předmětem projektového managementu a v rámci architektury dlouhodobého rozvoje nehrají žádnou roli (v hrubém pojetí jsou potřeba ve 3. Kapitole) Přechod mezi etapami, stav na konci etapy, je přechodová architektura. Etapa 1 Samotný Projekt Etapa 2 Rozvoj v dalším projektu Etapa 3 Přechod na jiné řešení Fáze 1 Příprava Přechodová architektura Přechodová architektura Fáze 1 Fáze 2 Realizace Fáze 1 Fáze 2 Fáze 2 Fáze 3 Fáze 3 Ukončení Fáze 4 31

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

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

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

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

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

Enterprise Architecture na MPSV 23.9.2015

Enterprise Architecture na MPSV 23.9.2015 Enterprise Architecture na MPSV 23.9.2015 Mgr. Bc. et Bc. Robert Baxa, náměstek ministryně Mgr. Jiří Károly, ředitel odboru rozvoje a bezpečnosti ICT Enterprise Architecture (EA) na MPSV Východiska pro

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

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

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

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

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

Řízení výkonnosti v rámci NAP a práce OHA Ministerstva vnitra ČR

Řízení výkonnosti v rámci NAP a práce OHA Ministerstva vnitra ČR Řízení výkonnosti v rámci NAP a práce OHA Ministerstva vnitra ČR 20.6.2017 Ing. Pavel Hrabě, PhD. Externí poradce - metodik Národního architektonického plánu veřejné správy ČR Odbor hlavního architekta

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

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

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

Chytrá systémová architektura jako základ Smart Administration

Chytrá systémová architektura jako základ Smart Administration Chytrá systémová architektura jako základ Smart Administration Ing. Petr Škvařil, Pardubický kraj Dipl. Ing.Zdeněk Havelka PhD. A-21 s.r.o. 1 Nepříjemné dotazy Jsme efektivní v provozování veřejné správy?

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

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

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

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

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

Občani a občanky miniblok ministerstva vnitra o egovernmentu

Občani a občanky miniblok ministerstva vnitra o egovernmentu Občani a občanky miniblok ministerstva vnitra o egovernmentu Sekce informačních a komunikačních technologií Ministerstvo vnitra Roman Vrba ředitel Odbor egovernmentu Petr Kuchař ředitel Odbor hlavního

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

Podnikatelský záměr - PZ (Osnova)

Podnikatelský záměr - PZ (Osnova) Příloha č. 5 Podnikatelský záměr - PZ (Osnova) 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

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

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

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

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

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

Metodické postupy tvorby architektury

Metodické postupy tvorby architektury Metodické postupy tvorby architektury Název Metodické postupy tvorby architektury Datum zhotovení 14. 3. 2016 Zhotovitel KPMG Česká republika, s.r.o. Zpracoval za zhotovitele Tomáš Martinka Verze 2.1 Veřejná

Více

STRATEGICKÝ RÁMEC ROZVOJE VEŘEJNÉ SPRÁVY ČESKÉ REPUBLIKY Mgr. Bohdan Urban

STRATEGICKÝ RÁMEC ROZVOJE VEŘEJNÉ SPRÁVY ČESKÉ REPUBLIKY Mgr. Bohdan Urban STRATEGICKÝ RÁMEC ROZVOJE VEŘEJNÉ SPRÁVY ČESKÉ REPUBLIKY 2014+ Mgr. Bohdan Urban Mikulov, 3.9.2013 Východiska Návrh koncepce reformy veřejné správy Usnesení vlády ČR ze dne 30. března 1999 č. 258 Koncepce

Více

Pořízení nových systémů na MPSV děláme to ponovu

Pořízení nových systémů na MPSV děláme to ponovu Pořízení nových systémů na MPSV děláme to ponovu 13. dubna 2015 Hradec Králové Ing. Iva Merhautová, MBA Mgr. Bc. et Bc. Robert Baxa Michal Rada ICT MPSV Základní oblasti řízení: ICT ministerstva práce

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

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

SMĚRNICE MŽP č. 9/2013

SMĚRNICE MŽP č. 9/2013 MINISTERSTVO ŽIVOTNÍHO PROSTŘEDÍ SMĚRNICE MŽP č. 9/2013 V Praze dne 13.6.2013 Č. j.: 38821/ENV/13 2924/M/13 o poskytování finančních prostředků v rámci programu Nová zelená úsporám 2013 Ministerstvo životního

Více

Současný stav a rozvoj elektronického zdravotnictví - pohled Ministerstva zdravotnictví

Současný stav a rozvoj elektronického zdravotnictví - pohled Ministerstva zdravotnictví Současný stav a rozvoj elektronického zdravotnictví - pohled první ročník semináře ehealth 2012 kongresový sál IKEM 1.11.2012 Elektronizace zdravotnictví: 1. jedná se o dlouhodobé téma 2. povede ke zvýšení

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

GEOINFOSTRATEGIE AKTUÁLNÍ STAV

GEOINFOSTRATEGIE AKTUÁLNÍ STAV GEOINFOSTRATEGIE AKTUÁLNÍ STAV Radek Horáček MV ČR Odbor egovernmentu GEOINFOSTRATEGIE V POLOČASE CO SE UDĚLALO CO DĚLÁME DNES CO BUDE V ROCE 2020 GEOINFOSTRATEGIE Současný stav (východiska, informační

Více

Integrovaný regionální operační program SC 2.2 Sociální podnikání

Integrovaný regionální operační program SC 2.2 Sociální podnikání Integrovaný regionální operační program SC 2.2 Sociální podnikání 26. 1. 2016 Hradec Králové Ing. Michaela Brožová Centrum pro regionální rozvoj České republiky Specifický cíl 2.2 sociální podnikání Specifický

Více

Zhodnocení průběžného plnění Informační strategie hl. m. Prahy do roku 2010 (Cesta k e-praze) Duben 2009

Zhodnocení průběžného plnění Informační strategie hl. m. Prahy do roku 2010 (Cesta k e-praze) Duben 2009 Zhodnocení průběžného plnění Informační strategie hl. m. Prahy do roku 2010 (Cesta k e-praze) Duben 2009 Agenda 1 2 3 4 5 6 7 8 Manažerské shrnutí Strategické podněty Plnění programů a projektů Financování

Více

Petr Kuchař ředitel odboru odbor hlavního architekta egov MV ČR. Ondřej Felix Digitální šampion ČR, odbor hlavního architekta egov MV ČR

Petr Kuchař ředitel odboru odbor hlavního architekta egov MV ČR. Ondřej Felix Digitální šampion ČR, odbor hlavního architekta egov MV ČR Národní architektura ICT ve veřejné správě ČR Národní architektonický plán Architektonické vzory Role odboru Hlavního architekta egovernmentu Role jednotlivých OVM ve vztahu Národní architektuře Petr Kuchař

Více

Hodnotící tabulka. Kritérium 1 platné od: Schváleno usnesením MV: č. 098/MV13/11. Kritérium 2 platné od:

Hodnotící tabulka. Kritérium 1 platné od: Schváleno usnesením MV: č. 098/MV13/11. Kritérium 2 platné od: Příloha č. 3 Hodnotící tabulka Kritéria pro výběr projektů předkládaných v rámci prioritní osy 2 Podpora prosperity regionu, dílčí oblasti podpory 2.1.2 Rozvoj infrastruktury sociálních služeb. Pro výzvu

Více

Zdeněk Dutý 09/ Nástroj na generování formulářů pro schvalovací proces dle UV 889/2015

Zdeněk Dutý 09/ Nástroj na generování formulářů pro schvalovací proces dle UV 889/2015 Zdeněk Dutý 09/12 2 0 1 6 Nástroj na generování formulářů pro schvalovací proces dle UV 889/2015 Kuchařka pro žadatele dle UV č.889/2015 Část první Recept: Polévka OHA Příprava přečteme si něco o vaření

Více

Referenční model a jeho využití v praxi MěÚ Benešov

Referenční model a jeho využití v praxi MěÚ Benešov MěÚ Benešov Referenční model a jeho využití v praxi MěÚ Benešov Mgr. Bc. Miluše Stibůrková tajemnice MěÚ Benešov E-mail: stiburkova@benesov-city.cz Telefon: 317 754 144, 317 754 145 Městský úřad Benešov

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

P ístup k centrálním sdíleným službám z pohledu kraje

P ístup k centrálním sdíleným službám z pohledu kraje P ístup k centrálním sdíleným službám z pohledu kraje Zpracoval(a): Ing. Tomáš Vašica Datum: 5. 4. 2016 Architektura ICT kraje krajské korporace STRATEGIE KRAJSKÉHO Ú ADU MORAVSKOSLEZSKÉHO KRAJE DO ROKU

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

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

NÁRODNÍ ARCHITEKTURA ČR CESTA KE STABILITĚ A EFEKTIVNOSTI VÝVOJE VS A JEJÍCH IS

NÁRODNÍ ARCHITEKTURA ČR CESTA KE STABILITĚ A EFEKTIVNOSTI VÝVOJE VS A JEJÍCH IS NÁRODNÍ ARCHITEKTURA ČR CESTA KE STABILITĚ A EFEKTIVNOSTI VÝVOJE VS A JEJÍCH IS Pavel Hrabě - Enterprise Architect, SAP ČR listopad 2013 Public Obsah prezentace Architektura jako společný jazyk transformace

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

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

Výkonnostní audit a výkonnost veřejné správy

Výkonnostní audit a výkonnost veřejné správy Výkonnostní audit a výkonnost veřejné správy Štefan Kabátek, NKÚ Národní konference ČIIA, 15. 16. října 2014, Špindlerův Mlýn Co znamená výkonnost pro veřejný sektor? 2 Data, informace, znalosti, efektivnost

Více

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

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

Více

Základní registry 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

Veřejná správa veřejně a správně

Veřejná správa veřejně a správně Veřejná správa veřejně a správně Ministerstvo vnitra ČR Procesní modelování agend Josef Beneš Mikulov, 9/9/2014 Veřejná správa veřejně a správně OBSAH PREZENTACE Důvody realizace Program PMA Využití procesních

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

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

Komise pro informatizaci

Komise pro informatizaci Komise pro informatizaci veřejné správy Rady AK Zdeněk Ryšavý, předseda komise radní kraje Vysočina pro informatiku Územní plánování a životní prostředí 11/08/2009 egovernment a kraje V rámci projektu

Více

Národní infrastruktura pro elektronické zadávání veřejných zakázek (NIPEZ)

Národní infrastruktura pro elektronické zadávání veřejných zakázek (NIPEZ) Ministerstvo pro místní rozvoj ČR, Odbor veřejného investování, květen 2011 Národní infrastruktura pro elektronické zadávání veřejných zakázek (NIPEZ) Obsah prezentace 1. Základní vymezení NIPEZ... 3-6

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

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

POKYNY PRO ŽADATELE PŘÍLOHA C2 ZÁVAZNÉ OSNOVY PRO ZPRACOVÁNÍ STUDIE PROVEDITELNOSTI K AKCI PŘEDKLÁDANÉ DO GS JKS GRANTOVÁ SCHÉMATA SROP

POKYNY PRO ŽADATELE PŘÍLOHA C2 ZÁVAZNÉ OSNOVY PRO ZPRACOVÁNÍ STUDIE PROVEDITELNOSTI K AKCI PŘEDKLÁDANÉ DO GS JKS GRANTOVÁ SCHÉMATA SROP Moravskoslezský kraj POKYNY PRO ŽADATELE PŘÍLOHA C2 ZÁVAZNÉ OSNOVY PRO ZPRACOVÁNÍ STUDIE PROVEDITELNOSTI K AKCI PŘEDKLÁDANÉ DO GS JKS 28.6.2006 Strana 1 z 5 ZÁVAZNÁ OSNOVA STUDIE PROVEDITELNOSTI (SP) TITULNÍ

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

Strategické řízení IS v podmínkách VS přínosy a problémy

Strategické řízení IS v podmínkách VS přínosy a problémy Strategické řízení IS v podmínkách VS přínosy a problémy Ing. David Melichar, PhD., ČSSI Ing. Tomáš Hrabík, CORTIS Consulting 1.12.2008 Setkání informatiků, Kladno Trendy ve veřejné správě Smart Administration,

Více

Statut pracovního výboru pro Architekturu a strategii Rady vlády pro informační společnost

Statut pracovního výboru pro Architekturu a strategii Rady vlády pro informační společnost Statut pracovního výboru pro Architekturu a strategii Rady vlády pro informační společnost (dále jen statut ) Článek 1 Úvodní ustanovení (1) Pracovní výbor pro Architekturu a strategii (dále jen pracovní

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

Charta projektu úplné znění pro MŠMT a jeho příspěvkové organizace a Českou školní inspekci

Charta projektu úplné znění pro MŠMT a jeho příspěvkové organizace a Českou školní inspekci Charta projektu úplné znění pro MŠMT a jeho příspěvkové organizace a Českou školní inspekci 1 Obsah Manažerské Shrnutí... 3 Definice projektu rámcová část... 3 Stručný kontext realizace projektu... 3 Cíle

Více

Strategie a Perspektivy ČP OZ ICT Služby 2015

Strategie a Perspektivy ČP OZ ICT Služby 2015 Strategie a Perspektivy ČP OZ ICT Služby 2015 Jan Přerovský Česká pošta, s.p., Odštěpný závod ICT služby 9. 9. 2014 1 Mikulov 09.09. 2014 Obsah Obsah Cíle strategie předpoklady úspěchu strategie přehled

Více

Regionální operační program. Postupy čerpání dotací z

Regionální operační program. Postupy čerpání dotací z Regionální operační program Střední Morava Postupy čerpání dotací z Evropské unie 1. Audit shody připravenost Úřadu Regionální rady k implementaci ROP Střední Morava a. Nyní probíhá reaudit b. Vliv na

Více

Společného monitorovacího výboru operačních programů Praha Adaptabilita a Praha Konkurenceschopnost

Společného monitorovacího výboru operačních programů Praha Adaptabilita a Praha Konkurenceschopnost U S N E S E N Í Společného monitorovacího výboru operačních programů Praha Adaptabilita a Praha Konkurenceschopnost číslo 3 ze dne 5. prosince 2007 ke Kritériím pro výběr projektů Operačního programu Praha

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

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT)

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Charta projektu má za cíl poskytnout úplné a pevné informační základy pro schválení projektu. Následně je Charta projektu rozpracována do

Více

Evaluační plán ROP SZ na období

Evaluační plán ROP SZ na období EVALUAČNÍ PLÁN Regionálního operačního programu regionu soudržnosti Severozápad Seznam použitých zkratek ČR DPH EK ES EU NOK OM OP OŘP PSE ROP SZ ROP SZ RR SZ ŘO ŘO ROP SZ ÚRR SZ Česká republika daň z

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

Miroslav Kalous Miloš Vystrčil Dan Jiránek

Miroslav Kalous Miloš Vystrčil Dan Jiránek Výkon veřejné správy a její reformy Miroslav Kalous Miloš Vystrčil Dan Jiránek Koncepce reformy veřejné správy 90 léta min. stol. nultá fáze reformy VS Vytvoření krajů Ukončení okresních úřadů Obce s rozšířenou

Více

Protokol o atestačním řízení

Protokol o atestačním řízení Atestační středisko: ADA, s. r. o. pověření k výkonu atestací MI ČR reg. č. 3 rozhodnutím č. j. 3/2001 A ze dne 11.10.2001, se sídlem Čermákova 28, 625 00 Brno adresa pro poštovní styk Sokolská 725, 664

Více

EIDAS, DIGITÁLNÍ DŮVĚRA A MODERNÍ PAPERLESS V PRAXI. Jan Tejchman Business Consultant

EIDAS, DIGITÁLNÍ DŮVĚRA A MODERNÍ PAPERLESS V PRAXI. Jan Tejchman Business Consultant EIDAS, DIGITÁLNÍ DŮVĚRA A MODERNÍ PAPERLESS V PRAXI Jan Tejchman Business Consultant Digitální Evropa Digitální transformace Moderní paperless Právní validita Služby vytvářející důvěru Business aplikace

Více

Úvod do projektu. Standardizace provozních funkcí ÚSC. Součást projektu Korporátní styl řízení ve veřejné správě

Úvod do projektu. Standardizace provozních funkcí ÚSC. Součást projektu Korporátní styl řízení ve veřejné správě Úvod do projektu Standardizace provozních funkcí ÚSC Součást projektu Korporátní styl řízení ve veřejné správě Měníme zvyky a posouváme mentální bloky POPTÁVKA Tlak na rozpočet, obtížně stanovitelné rozpočtové

Více

Veřejná soutěž o zajištění návrhu SW a HW architektury pro provoz IS a o zajištění funkčního vzorku IS

Veřejná soutěž o zajištění návrhu SW a HW architektury pro provoz IS a o zajištění funkčního vzorku IS Veřejná soutěž o zajištění návrhu SW a HW architektury pro provoz IS a o zajištění funkčního vzorku IS zápis z úvodního setkání se zájemci o účast v soutěži Místo Technologická agentura ČR, Evropská 2589/33b,

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

Nová koncepce elektronického zdravotnictví pro období 2014 + 17. ročník konference ISSS

Nová koncepce elektronického zdravotnictví pro období 2014 + 17. ročník konference ISSS Nová koncepce elektronického zdravotnictví pro období 2014 + 17. ročník konference ISSS Programové prohlášení vlády určuje jako jeden ze svých hlavních cílů: - zvyšování kvality zdravotnické péče - zvyšování

Více

egovernment ready úřad

egovernment ready úřad egovernment ready úřad Ing. Václav Koudele Strategy architect Tel.: +420 602 191 122 Vaclav.koudele@microsoft.com Ing. Zdeněk Dutý Ředitel pro egovernment Tel.: +420 910 972 131 zdenek.duty@autocont.cz

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

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Pořadové číslo dodatečných informací: 14. ČÁST 1: Přesné znění žádosti dodavatele o dodatečné informace Otázka

Více

PŘÍLOHA Č. 5 POVINNÁ OSNOVA PODNIKATELSKÉHO ZÁMĚRU

PŘÍLOHA Č. 5 POVINNÁ OSNOVA PODNIKATELSKÉHO ZÁMĚRU PŘÍLOHA Č. 5 POVINNÁ OSNOVA PODNIKATELSKÉHO ZÁMĚRU 1. Základní údaje o žádosti Název projektu: 2. Údaje o žadateli 2.1.1. Základní údaje Obchodní firma: Právní forma: IČ: Počet zaměstnanců: DIČ: 2.1.2.

Více

KRITÉRIA PRO VÝBĚR IPRÚ č. 20/ podoblast podpory V 20 VK 1.0_3.1.2

KRITÉRIA PRO VÝBĚR IPRÚ č. 20/ podoblast podpory V 20 VK 1.0_3.1.2 KRITÉRIA PRO VÝBĚR IPRÚ č. 20/2010 - podoblast podpory 3.1.2 V 20 VK 1.0_3.1.2 Revize. č. Předmět revize Strana Platné od Podpis a datum... 10 Verze č. 1 10 Za zpracovatelský tým Ověřil Schválil Jméno

Více

Sjednocení dohledových systémů a CMDB

Sjednocení dohledových systémů a CMDB Řízení dodávky IT služeb v enterprise společnosti Sjednocení dohledových systémů a CMDB Václav Souček, ČEZ ICT Services, a.s. Jaroslav Jičínský, AutoCont CZ, a.s. 26. Ledna 2012 Agenda Úvod Výchozí stav

Více

Kritéria pro hodnocení 1. výzvy k programu podpory OP PIK Partnerství znalostního transferu

Kritéria pro hodnocení 1. výzvy k programu podpory OP PIK Partnerství znalostního transferu Příloha č. 4 Kritéria pro hodnocení 1. výzvy k programu podpory OP PIK Partnerství znalostního transferu Metodika bodování Kritéria pro hodnocení jsou rozdělena na pět základních částí: A Binární (vylučovací)

Více

Management kvality a jeho využití v praxi MěÚ Benešov

Management kvality a jeho využití v praxi MěÚ Benešov MěÚ Benešov Management kvality a jeho využití v praxi MěÚ Benešov Mgr. Bc. Miluše Stibůrková tajemnice MěÚ Benešov E-mail: stiburkova@benesov-city.cz Telefon: 317 754 144, 317 754 145 Městský úřad Benešov

Více

Nízkouhlíkové technologie

Nízkouhlíkové technologie Příloha č. 3 - Kritéria pro hodnocení Specifického cíle 3.4 Nízkouhlíkové technologie Metodika bodování Kritéria pro hodnocení jsou rozdělena na pět základních částí: A Binární (vylučovací) kritéria B

Více

Dodatek č. 1 k Přílohám I Směrnice Ministerstva životního prostředí

Dodatek č. 1 k Přílohám I Směrnice Ministerstva životního prostředí Dodatek č. 1 k Přílohám I Směrnice Ministerstva životního prostředí č. 13/2006 o poskytování finančních prostředků ze Státního fondu životního prostředí ČR platným od 1. listopadu 2008 Dodatek č. 1 k Přílohám

Více

Integrovaný plán rozvoje města Liberec atraktivní a kvalitní život v Liberci

Integrovaný plán rozvoje města Liberec atraktivní a kvalitní život v Liberci Integrovaný plán rozvoje města Liberec atraktivní a kvalitní život v Liberci Pokyny pro vyplnění formuláře žádosti Název předkladatele: Uveďte oficiální název organizace Název projektu: Předpokládaný operační

Více

PŘÍLOHA č. 11e) příruček pro žadatele a příjemce OP VaVpI. ZÁVAZNÁ OSNOVA STUDIE PROVEDITELNOSTI v rámci prioritní osy 3, číslo výzvy 4.

PŘÍLOHA č. 11e) příruček pro žadatele a příjemce OP VaVpI. ZÁVAZNÁ OSNOVA STUDIE PROVEDITELNOSTI v rámci prioritní osy 3, číslo výzvy 4. PŘÍLOHA č. 11e) příruček pro žadatele a příjemce OP VaVpI ZÁVAZNÁ OSNOVA STUDIE PROVEDITELNOSTI v rámci prioritní osy 3, číslo výzvy 4.3 Příloha č. 11e): Závazná osnova Studie proveditelnosti Pro projekty

Více

Vyzýváme Vás k podání nabídky na veřejnou zakázku malého rozsahu s názvem E-shop pro Centrální nákup Plzeňského kraje.

Vyzýváme Vás k podání nabídky na veřejnou zakázku malého rozsahu s názvem E-shop pro Centrální nákup Plzeňského kraje. PLZEŇSKÝ KRAJ KRAJSKÝ ÚŘAD, odbor informatiky Škroupova 18, 306 13 Plzeň NAŠE ZN.: IT/1127/13 VYŘIZUJE: Mgr. Pavel Sloup TEL.: +420 377195194 FAX: +420 377195208 E-MAIL: pavel.sloup@plzensky-kraj.cz DATUM:

Více

Výběrová kritéria pro výzvu 5.3 Efektivní systém hodnocení programů účelové podpory

Výběrová kritéria pro výzvu 5.3 Efektivní systém hodnocení programů účelové podpory Příloha A) Výběrová kritéria pro výzvu 5.3 Efektivní systém hodnocení programů účelové podpory Proces hodnocení projektů v rámci výzvy 5.3 oblasti podpory 3.2 prioritní osy 3 OP VaVpI sestává ze dvou částí.

Více

Odůvodnění účelnosti veřejné zakázky. Odůvodněníí veřejjné zakázky Popis potřeb, které mají být splněním veřejné zakázky naplněny.

Odůvodnění účelnosti veřejné zakázky. Odůvodněníí veřejjné zakázky Popis potřeb, které mají být splněním veřejné zakázky naplněny. Odůvodněníí veřejjné zakázky 1) Odůvodnění účelnosti veřejné zakázky: Popis potřeb, které mají být splněním veřejné zakázky naplněny. Popis předmětu veřejné zakázky. Odůvodnění účelnosti veřejné zakázky

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

Kritéria pro hodnocení 1. výzvy k programu podpory OP PIK Smart Grids II. (Přenosová síť)

Kritéria pro hodnocení 1. výzvy k programu podpory OP PIK Smart Grids II. (Přenosová síť) SG II_Příloha č. 4 Kritéria pro hodnocení 1. výzvy k programu podpory OP PIK Smart Grids II. (Přenosová síť) Metodika bodování Kritéria pro hodnocení jsou rozdělena na pět základních částí: A B C D E Binární

Více