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

Transkript

1 Vydávání stanovisek k ICT projektům dle usnesení vlády č. 889 z část 3: Obsah žádosti a postup při vydávání stanoviska OHA OHA, Ing. Pavel Hrabě, PhD. Externí poradce Odbor hlavního architekta egov MV ČR

2 Obsah prezentace 1. Úvod do problematiky Motivace k architektuře úřadů Přehled principů a aktuálních výstupů Národní architektury VS ČR (NA VS ČR) 2. Detail Obsah žádosti a postup při vydávání stanoviska OHA 2

3 2. Detail Obsah žádostí a postup při vydávání stanoviska OHA 3

4 O čem je usnesení vlády č.889? I. jde o milník srovnatelný se zák.365/2000 o ISVS usnesení přineslo v příloze Základní zásady postupu při čerpání finanačních prostředků na výdaje související s ICT s hodnotou více než 6M/rok zásady ukládají zpracovatelům záměru nákupu služeb či investic nad hranici 6M/rok resp. 30M/5let seznámit s projektem útvar OHA a do obdržení souhlasného stanoviska neinvestovat jakékoliv finanční prostředky do realizační fáze, řídit se stanovisky OHA a zásadní změny konzultovat 4

5 O čem je usnesení vlády č.889? II. zásady ukládají OHA vydat do 30 dnů (60 dnů u složitějších) odůvodněné stanovisko ke kompletnímu projektu ve stanovisku zohlednit mimo architektonické konzistence s architekturou egovernmentu také potřebnost, účelnost, hospodárnost, realizovatelnost, připravenost, přínos, ekonomickou a personální náročnost, analýzu rizik a způsob řízení projektu na to vše se OHA musí zeptat v dotazníku 5

6 O čem je usnesení vlády č.889? III. Pojmy: Zpracovatel projektu: ministerstvo, ÚSÚ, jiná organizační složka státu, Kancelář PSP a Senátu, bez ohledu na způsob financování Výdaje na ICT: zejména výdaje na služby nebo investice, na opravy a udržování myšleno externě zaplacené peníze. Ty musí být nad 6M/ročně Ekonomická náročnost: finanční vyčíslení předpokládané náročnosti podle TCO 5 let myšleno všechny náklady, i interní zdroje 6

7 Výklad 6M/rok resp. 30M/5let I. nákup služeb či investic s hodnotou více než 6 miliónů ročně resp. 30 mil. za 5 let 70 Výdaj [Mil. Kč] Uvedení sytému do provozu 60 Začátek projektu úprava systému 50 Uvedení úpravy systému do provozu M 5 let po uvedení do provozu M x 5 let = 15M rok 2.rok 3.rok 4.rok 5.rok 6.rok 7.rok 8.rok 9.rok 10.rok původní investice a provoz projekt "úpravy systému" Čas [léta] Celkem záměr = 35 mil Kč. Celkem TCO řešení na 5 let služby = 85 mil Kč. 7

8 Výklad 6M/rok resp. 30M/5let II. Pokud tedy máme projekt za 20 mil Kč, který se rok bude stavět a pak 10 let provozovat za 3 mil Kč ročně tak: - jeho cena pro účely prahu pro žádost je: 20M + 5let *3M =35M, protože se podle metodiky počítá TCO na 5 let miliónů Kč je více než kritérium 30 miliónů za 5 let a tudíž tento projekt podléhá usnesení vlády č.889 Pokud by existoval projekt, jehož doba užívání by nedosáhla 5 a více let, bere se jeho investiční i provozní náročnost na takový počet let, na který je plánováno užívání projektu, tj. 1 až 4 roky. 8

9 Posuzování projektů a formuláře I. Formulář je zveřejněn spolu s metodickým pokynem k jeho vyplnění na URL: Protože se během ledna 2016 ukázalo, že schvalování projektů se přirozeně dělí do určitých kategorií podle svých vlastností, navrhuje OHA rozdělení na následující 4 situace: 9

10 Posuzování projektů a formuláře II. 4 kategorie ICT záměrů podle předmětu schvalování a k nim zjednodušené formuláře (pro A, B1, B2, B3 a C): A. Nové IS, nové funkcionality existujících IS plný dotazník, jak je zveřejněn na webu MVČR B. Kontrakty na údržbu či podporu existujících IS protože některé údržby jsou ve skutečnosti rozvoj velkých řešení: B1 souhlas s rámcovou smlouvou jakési ohlášení řešení a objemu smlouvy B2 žádost o stanovisko s dílčí, architektonicky relevantní úpravou B3 žádost o stanovisko s celkovou cílovou EA řešení a její roadmapou (5let) C. Nákup komoditního HW, SW či služeb zjednodušený dotazník, aby bylo vidět co, proč a za kolik se zda není možné využít či nabídnout sdílenou službu. Výjimkou komodity zahrnuté pod usnesení vlády č. 913 z D. Nákup spotřebního materiálu a náhradních dílů protože na tom ve skutečnosti není co schvalovat, navrženo zrušení povinnosti schvalovat chce koupit a RVIS ke 10

11 Obsah žádosti o stanovisko k projektu, struktura dotazníku Typ A, B3 1. ZÁKLADNÍ PODMÍNKY PROJEKTU 2. ARCHITEKTONICKÉ INFORMACE O PROJEKTU 2.1 Shoda s cíli Strategie rozvoje ICT sl. VS ČR 2.2 Shoda s architektonickými principy 2.3 Enterprise architektura projektu samotného 2.4 Pozice navrhovaného řešení v kontextu enterprise architektury úřadu 2.5 Způsob využití sdílených prvků egovernmentu 2.6 Podrobnější architektura částí řešení projektu 2.7 Plán dlouhodobého rozvoje architektury projektu (Roadmapa) 3. DALŠÍ ÚDAJE O PROJEKTU 3.1 Potřebnost a výstupy projektu 3.2 Připravenost projektu k realizaci 3.3 Podmínky a průběh realizace projektu 3.4 Ekonomické parametry projektu 3.5 Analýza rizik a negativních důsledků 3.6 Plán údržby, udržitelnost a ukončení projektu (exit strategie) 4. PŘEHLED POŽADOVANÝCH VÝJIMEK 5. UPOZORNĚNÍ A DOPORUČENÍ ZPRACOVATELE 6. Příloha: VZOR FORMULÁŘE ŽÁDOSTI O VÝJIMKU 11

12 2.1 Shoda s cíli Strategie rozvoje ICT služeb VS ČR Cíl C1 C2 Obsah cíle Od nekoordinovaného řízení ICT státu ke koordinovanému, postavenému na jednotné architektuře a jednotných pravidlech. Od závislosti na dodavatelích k vlastní kompetenci k efektivnímu řízení vývoje a provozu ICT v ČR. C3 C4 C5 C6 C7 C8 Od nezávislých a nejednotných procesů veřejné správy ke standardizovaným, provázaným, kvalitním, efektivním a měřitelným službám veřejné správy. Od specializovaných úředních přepážek k digitální samoobsluze umožněné koordinovanou publikaci uživatelsky přívětivých ICT služeb. Od izolovaných dat k propojeným a otevřeným datům veřejné správy a ke kvalifikovaným rozhodnutím vedoucím k vyšší efektivnosti služeb VS. Od izolovaných výpočetních systémů ke sdíleným ICT službám (od izolovaných provozních prostředí ke koordinované síti Národních a regionálních datových center propojených bezpečnou komunikační infrastrukturou). Od izolovaných identitních systémů k jednotným identitním systémům uživatelů služeb veřejné správy a úředníků veřejné správy Od pasivního přijímání legislativy a ICT projektů EU k aktivní participaci na přípravě nové legislativy a ICT projektů EU. <splňuje> <nerelevantní> <žádáme výjimku> Příspěvek projektu k naplnění cíle 12

13 2.2 Shoda s architektonickými principy egovernmentu ČR - I Podpůrné otázky pro ověření naplnění architektonických principů egovernmentu P1 Dostupnost Dodrželi jste princip, že každá nová nebo zásadně měněná veřejná služba musí být vnitřně plně elektronická? Máte pro každou službu všechny povinné obslužné kanály egovernmentu, samoobslužné (on-line i off-line) a asistované? Umožnění projekt učinit podání vůči VS v plně elektronické podobě kdekoli (bez nutnosti následného dokládání papírových dokumentů) a kdykoli (kromě okamžiků nezbytné údržby systémů)? Máte na pobočkách úřadu veřejná internetová připojení (Kiosky) pro samoobslužná podání? P2 Použitelnost Jak v projektu zajistíte, aby všechny formuláře služeb v projektu byly předvyplněny všemi státu známými údaji klienta? Jak zajistíte dostupnost plné historie vzájemné komunikace klienta a VS, aby byla využitelná pro opakované použití? Jak připravíte design služeb i systému, aby mohly být v případě spolupráce úřadů na řešení životní situace klienta řazeny (orchestrovány) do komplexního automatizovaného řešení? P3 Důvěryhodnost Co uděláte pro to, aby vzájemně vyměňované informace byly spolehlivé, relevantní, aktuální a klienti elektronické komunikaci důvěřovali? Jak zajistíte oboustranné garantované doručení a platnost elektronických dokumentů? Je projekt připraven využívat jednotný důvěryhodný identitní prostor pro klienty veřejné správy (jakmile bude k dispozici)? Využívá projekt jednotný identitní prostor úředníků (JIP/KAAS)? P4 Transparentnost Jak jste veřejnosti představili záměry a cíle projektu? Jak je projekt připraven zveřejňovat svá data jako otevřená a propojená? Počítá projekt s prostředky pro zveřejňování měření a auditů výkonnosti poskytovaných služeb? <splňuje> <nerelevantní> <žádáme výjimku> Vysvětlete uplatnění principu v řešení 13

14 2.2 Shoda s architektonickými principy egovernmentu ČR - II P5 Bezpečnost Jak projekt ochrání prostředky elektronických veřejných služeb před poškozením a zneužitím? Jak je v projektu zajištěna adekvátní ochrana osobních údajů a utajovaných skutečností? Počítá projekt s auditovatelností veřejných služeb a vytvářením auditní stopy pro tento účel? P6 Spolupráce a sdílení Koncipuje projekt nové služby (nebo jejich součásti) jako univerzální, tj. aby byly sdílitelné a opakovatelně použitelné, bez omezujících vazeb na specifické agendy? Ověřili jste si předem, jaké lze využít existující služby a komponenty, již vybudované ve shodě s principy sdílené architektury veřejné správy ČR? Byly/budou do návrhu služeb VS projektu zapojeny ve vzájemné spolupráci odborné týmy napříč VS s cílem sdílet KH? Jak? P7 Udržitelnost Je návrh a) byznys b) IT řešení natolik robustní, modulární, škálovatelný a parametrizovatelný, aby se přizpůsobil očekávaným změnám po dobu jeho životnosti? Jak jste se vypořádali s principem nutného upřednostnění nákupu a implementace standardní služby před vývojem vlastního řešení? Představuje-li projekt nové nebo zásadně pozměněné IT řešení, bude podporovat inovované služby egovernmentu? Jak je řešení navrženo pro efektivní údržbu a rozvoj, tj. jako standardizované, rozšiřitelné, integrovatelné, upgradovatelné a podporovatelné i vlastními silami úřadu? P8 Technologická neutralita Budou el. služby VS v projektu dostupné na všech běžně používaných platformách, stejně jako je to v soukromém sektoru? Jak otevřená modulární architektura projektu umožňuje vyměňovat jednotlivé prvky řešení bez nutnosti měnit jejich okolí? Jak má řešení zajištěnu nezávislost při čerpání služeb na všech ostatních rozhraních uvnitř čtyřvrstvé architektury? <splňuje> <nerelevantní> <žádáme výjimku> Vysvětlete uplatnění principu v řešení 14

15 EA 2.5 Kontext enterprise architektury egovernmentu 2.4 Kontext enterprise architektury úřadu Enterprise architektura projektu Pavel Hrabě 2014 SA Architektonické vzory řešení egovernmentu Uplatnění vzorů v architektuře řešení projektu 15

16 Obsah žádosti o stanovisko k projektu, struktura dotazníku Typ A 16

17 2.3 Enterprise architektura projektu samotného 2.5 Kontext enterprise architektury egovernmentu Kontext enterprise architektury úřadu Enterprise architektura projektu Pavel Hrabě

18 2.3 Enterprise architektura projektu samotného Úkolem zpracovatele je v této architektuře představit prvky řešení na všech vrstvách tzv. čtyřvrstvé vize architektury egovernmentu, jejich stávající a plánovanou existenci a vzájemné vztahy. Zejména: Zájmové skupiny, motivátory (externí a interní vlivy), strategické iniciativy (politiky), proveditelné cíle a jejich měřítka. Funkce (nebo procesy) a služby veřejné správy (externí a interní), které budou řešením podporovány. Role klientů řešení a komunikační kanály, kterými budou klienti službu VS využívat. Aplikační komponenty podporující služby veřejné správy, jejich základní aplikační funkce a aplikační rozhraní na ostatní komponenty (interní a externí z pohledu úřadu). Technologické komponenty a platformové (IT) služby datového centra využívané pro příslušné aplikační komponenty Technologické komponenty a služby komunikační infrastruktury využívané pro příslušné aplikační a technologické komponenty. 18

19 2.3 Enterprise architektura projektu samotného 19

20 2.3 Enterprise architektura projektu samotného Motivační architektura - strategie a směrování Zainteresovaní, zájmové skupiny Motivátory, externí vlivy Strategie, politiky a jejich cíle Proveditelné úkoly Metriky úspěchu politiky, splnění úkolu Modely motivační architektury (NEPOVINNÉ) Výkonnostní architektura - efektivita projektu Ukazatele hospodárnosti, účinnosti, účelnosti (3E) a kvality služby Výsledky a dopady politiky, multiplikační efekty 20

21 Metamodel strategické (motivační) architektury 21

22 Příklad motivační architektury 22

23 Definice struktury KPI Logický model výkonnosti Strategie (politika) Zlepšo vání Definice KPI Audit výkonu Plánování Vyhodnocení Měření Potřeby Dopady Vnější vlivy Cíle Výsledky Zdroje a vstupy Činnosti Výstupy Užití výstupů úroveň služby účinnost účelnost hospodárnost Zdroj: Hrabě (ČSSI, 2013), podle Svoboda, J., Zeithamlová, Š., CH-16 Metodická pomůcka pro audit výkonu v orgánech veřejné správy. Centrální harmonizační jednotka pro FK MF ČR, a MANUÁL PRO AUDIT VÝKONNOSTI. Skupina CEAD, Evropský účetní dvůr. LUXEMBOURG,

24 2.3 Enterprise architektura projektu samotného Byznys architektura - poskytování veřejných služeb Organizační jednotky, byznys role a aktéři Interní funkce a procesy Externí/interní služby (poskytované a přijímané rolemi v komunikačních kanálech). Komunikační (obslužné) kanály 24

25 Metamodel byznys architektury 25

26 26

27 27

28 Příklady byznys architektury funkční pohled 28

29 Příklady byznys architektury procesní pohled 29

30 2.3 Enterprise architektura projektu samotného Architektura informačních systémů (aplikací a dat) Aplikační komponenty, funkce, případně služby Aplikační rozhraní 30

31 Metamodel aplikační architektury 31

32 Aplikační objekty metamodelu ArchiMate 32

33 Hledisko využití aplikací Příklad pohledu (diagramu) dle hlediska využití aplikací Prvky a vztahy hlediska využití aplikací 33

34 Příklad hlediska spolupráce aplikací 34

35 Metamodel datové architektury Objekt / subjekt veřejné správy (orig. Business Object) představuje všechny věci, které v prostředí veřejné správy prostě jsou. A některé z nich jsou pro nás zajímavé do té míry, že si o nich vedeme datové záznamy. Datový objekt je logickým obrazem skutečného objektu, promítnutého do vrstvy informačních systémů. Datový artefakt, tedy soubor, tabulka, záznam na disku je fyzickou reprezentací dat o objektu. Artefakt je také používán jako fyzická reprezentace SW, ať již aplikační komponenty nebo systémového SW. 35

36 Příklad datové architektury projektu 36

37 2.3 Enterprise architektura projektu samotného TA vrstva IT technologie (HW a SW) Technologické komponenty (uzly, provozní SW, zařízení, interní síťové prvky) Technologické funkce, případně služby TA vrstva komunikační infrastruktury Technologické komponenty (uzly, provozní SW, zařízení, síťové prvky) Technologické funkce, případně služby 37

38 38

39 39

40 Příklad IT technologické architektury projektu - struktura 40

41 Příklad IT technologické architektury projektu - užití 41

42 2.3 Enterprise architektura projektu samotného Bezpečnostní architektura Prvky pasivní bezpečnosti Prvky aktivní bezpečnosti Popis identifikace, autentizace a autorizace Shoda s pravidly, standardizace a dlouhodobá udržitelnost Zákonné a podzákonné předpisy Interní standardy, Architektonické stavební bloky Pravidla udržitelnosti (CSR Corporate Social Responisibility) 42

43 2.3.9 Pohled čtyřvrstvé architektury Pohled na model Metamodel 43

44 Příklad 4-vrstvé architektury

45 Příklad 4-vrstvé architektury

46 2.4 Pozice řešení v kontextu enterprise architektury úřadu 2.5 Kontext enterprise architektury egovernmentu Kontext enterprise architektury úřadu Enterprise architektura projektu Pavel Hrabě

47 2.4 Pozice řešení v kontextu enterprise architektury úřadu Pro kontext úřadu je nutné na každé z vrstev architektury umístit prvky architektury projektu do celkové mapy příslušné vrstvy architektury úřadu a ukázat na souvislosti. Například: jak souvisí implementovaná služba s ostatními službami úřadu, jak nová služba využívá sdílené komunikační kanály úřadu (přepážky, CzechPOINT, DS, portály apod.), zda nově implementovaná aplikační komponenta je první svého druhu v úřadu nebo zda vzniká duplicita či multiplicita - a proč zda řešení sdílí infrastrukturu úřadu nebo užívá NDC, pokud ne tak proč Postupně budou pro usnadnění k dispozici referenční mapy jednotlivých vrstev architektury, zpřesňované pilotními projekty. 47

48 2.4 Pozice řešení v kontextu enterprise architektury úřadu 48

49 Příklad klasifikací MPO 49

50 Portfolio mapa byznys architektury - definice 50

51 51

52 52

53 Základ architektonické vize VS SK - de facto referenční architektura 53

54 Základ architektonické vize VS SK - de facto referenční architektura 54

55 Mapa aplikačního portfolia - definice 55

56 Referenční model AA VS v notaci ArchiMate - celý 56

57 2.5 Způsob využití sdílených prvků architektury úřadu a egovernmentu 2.5 Kontext enterprise architektury egovernmentu Kontext enterprise architektury úřadu Enterprise architektura projektu Pavel Hrabě

58 2.5 Způsob využití sdílených prvků architektury úřadu a egovernmentu V textech a diagramech architektury je třeba vyjádřit: V byznys (procesní) vrstvě vztah funkcí, procesů a služeb veřejné správy, zahrnutých do projektu, k existujícím nebo plánovaným sdíleným službám VS V aplikační vrstvě vztah k následujícím existujícím a připravovaným centrálním a sdíleným systémům a aplikačním službám: ZR (ISZR, ROB, ROS, RUIAN, RPP, ORG) Agendové systémy přispívající do Propojeného datového fondu CMS/KIVS, NDC, CzP, egsb, elegislativa, esbírka, JIP/KAAS, eop, JIP/SPFO, JIP/SPPO, ISDP, ISDS, ISoISVS, NDA, OpenData, PVS, SPA, MůjArchiv a KYB. V technologické vrstvě vztah projektu k existujícím nebo připravovaným sdíleným IT službám Národních datových center, případně dalším sdíleným IT službám. Ve vrstvě komunikační infrastruktury vztah prvků infrastruktury projektu ke sdíleným prvkům komunikační infrastruktury egovernmentu. 58

59 Pokus o model komunikačních kanálů VS 59

60 Komunikační kanály příklad Slovensko 60

61 Národní datová centra a jejich služby 61

62 2.6 Uplatnění povinných vzorů v architektuře řešení projektu Architektonické vzory řešení egovernmentu Uplatnění vzorů v architektuře řešení projektu Je třeba prokázat 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é OHA: 62

63 Publikace Architektonických vzorů 63

64 Kontrola shody architektury řešení projektu se vzory sdílených služeb egovernmentu Název architektonického vzoru egovernmentu Centrální místo služeb Dodržen vzor <Ano/Ne> Způsob a míra dodržení vzorů návrhem řešení projektu <vysvětlete> CzechPOINT <Ano/Ne> <vysvětlete> Datové schránky <Ano/Ne> <vysvětlete> Elektronická identita <Ano/Ne> <vysvětlete> Propojený datový fond Úplné elektronické podání <Ano/Ne> <Ano/Ne> <vysvětlete> <vysvětlete> 64

65 Architektonické vzory Sdílených služeb egovernmentu 65

66 CzechPOINT Pohled AIS To-Be 66

67 Datové schránky Pohled AIS To-Be 67

68 Elektronická identita Centrální pohled TO-BE NA Vydávání VS stanovisek ČR k ICT projektům, OHA MV ČR 68

69 Elektronická identita Pohled AIS TO-BE NA Vydávání VS stanovisek ČR k ICT projektům, OHA MV ČR 69

70 Propojený datový fond Pohled centrálních systémů TO-BE NA Vydávání VS stanovisek ČR k ICT projektům, OHA MV ČR 70

71 Propojený datový fond Pohled AIS TO-BE 71

72 Úplné elektronické podání Pohled AIS To-Be 72

73 2.7 Plán dlouhodobého rozvoje architektury projektu (Roadmapa) 2.5 Kontext enterprise architektury egovernmentu 2.4 Kontext enterprise architektury úřadu Enterprise architektura projektu Pavel Hrabě

74 2.7 Plán dlouhodobého rozvoje architektury projektu (Roadmapa) Etapy a milníky plánu zavedení architektury projektu Je třeba uvést výčet a podstatu etap rozvoje oblasti úřadu zahrnuté do projektu:. Jakých schopností, funkcí nebo komponent se přechodové architektury týkají a jaké jsou plánované milníky realizace přechodových architektur (uvedení do provozu). Vysvětlit, jakou roli v plánu rozvoje (roadmapě) této oblasti úřadu hraje předkládaný projekt Ostatní klíčové milníky úřadu související s projektem Všechny plánované, očekávané události života úřadu a jeho architektury, které by mohly mít dopad na projekt a jeho následný rozvoj. Všechny podstatné milníky, vytvářející stupně přechodové architektury kdekoli v úřadu (například centralizace spisových služeb za 2 roky, výměna agendového systému do 5 let, přenesení agendových IS do Národních datového centra apod.) Ostatní klíčové milníky egovernmentu související s projektem Všechny plánované, očekávané události života egovernmentu ČR (nebo EU) a jeho celkové architektury, které by mohly mít dopad na projekt a jeho následný rozvoj. Všechny takové podstatné milníky, vytvářející stupně přechodové architektury (například implementace nařízeni eidas). 74

75 3.4 Ekonomické parametry projektu dle modelu TCO Rozsah výdajů a/nebo nákladů se v rámci Žádosti o stanovisko OHA k ICT projektům posuzuje dvakrát, různým způsobem a pro různý účel: Odhad, resp. plán výdajů pro záměr realizovat nákup služeb či investic související s informačními a komunikačními technologiemi s předpokládanou hodnotou více než 6 milionů Kč ročně, resp. 30 milionů Kč vynaložených za 5 let (bez DPH), pro rozhodnutí zda projekt spadá do kategorie projektů posuzovaných OHA. Slovo výdajů znamená externí náklady přímo placené jiným subjektům, v tabulce sloupec 3. *) Plán nákladů pro finanční vyčíslení celkové předpokládané ekonomické náročnosti projektu založené na metodologii 5 letých celkových nákladů vlastnictví (tzv. total costs of ownership). Kromě předchozího bodu (plán výdajů, tj. externích nákladů) se zde musí započítat i interní náklady úřadu, v tabulce sloupec 1 a případné interní náklady jinde ve veřejné správě, v tabulce sloupec 2.**) Zdroj: *) Čl 2, odst. d) Základních zásadu postupu při čerpání finančních prostředků na výdaje související s informačními a komunikačními technologiemi s hodnotou více než 6 mil. Kč ročně, které jsou přílohou č. 2 usnesení vlády ze dne 2. listopadu 2015 č **) Čl.2, odst. e) tamtéž. 75

76 3.4.1 Ekonomické parametry projektu hodnota výdajů Projekt (záměr) se stává relevantním pro povinnost podat žádost o stanovisko OHA tehdy, pokud: souhrn všech zamýšlených, s vlastnictvím nebo užíváním řešení, nebo jeho čá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ě. 76

77 Souhrnná položka modelu TCO (5 let) v tis. Kč A. Předběžné analýzy, tvorba zadání, výběr řešení a dodavatele náklady nákupního procesu B. Nákup SW a HW pro projekt (ne v případě SaaS) C. Analýza, vývoj, implementace a zkušební provoz D. Provoz a podpora řešení HW a SW (ne v případě SaaS) E. Hardware/Software údržba a průběžné úpravy (ne v případě SaaS) F. Projekty postupné inovace a zlepšování (plánované) 3.4 Ekonomické parametry projektu 1 Interní náklady úřadu 2 Interní náklady jinde ve VS 3 Externí náklady (=výdaje) G. Projekty upgrade (pokud jsou plánovány) H. Zvýšené náklady užívání řešení (pokud se vyskytnou) 4 Náklady celkem Vysvětlení k položce TCO Nepovinné, uveďte jen, je-li pro projekt významné I. Útlum, konzervace a ukončení řešení Nepovinné, uveďte jen, je-li pro projekt významné X. Licence, HW, provoz, podpora, údržba, průběžný rozvoj - vše v subskripci (pouze SaaS) Z. Ostatní nerozlišené režijní náklady Nepovinné, uveďte jen, je-li pro projekt významné Celkové TCO projektu (5let) Rozhodující pro relevanci k posouzení OHA 77

78 Postup vydávání stanoviska Žádost je podána MVČR, Odboru Hlavního architekta egovernmentu do datové schránky ID: 6bnaawp OHA zkontroluje kompletnost žádosti, v případě nedostatků si vyžádá doplnění a rozhodne o délce lhůty: běžná lhůta na schválení do 30 dnů nebo Složité projekty lhůta na schválení do 60 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, o tuto dobu se lhůta prodlužuje OHA vydá stanovisko 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 záměr před podáním žádosti 78

79 Vzdělávání školení Příprava a podpora na sestavení žádosti OHA připravuje kurzy NAP a žádosti Za 2 dny naučíme základy architektury úřadu a pomůžeme porozumět žádosti Společně nalezneme otevřené architektonické otázky Konzultace Ke konkrétním architektonickým otázkám egovernmentu K metodice NAP a žádosti 79

80 Děkujeme za pozornost tým OHA 80