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 architekta egovernmentu MV Praha, říjen 2016 verze 2.0 Toto dílo podléhá licenci Creative Commons Uveďte původ 4.0 Mezinárodní Licence.
Obsah Úvodní informace a pokyny... 3 1. Základní podmínky projektu... 5 1.1. Úvodní informace o zpracovateli projektu... 5 1.2. Shrnutí charakteristik projektu uzavření smlouvy... 5 1.3. Potřebnost a výstupy projektu... 6 1.4. Právní klasifikace předmětu projektu... 6 2. Architektonické informace o projektu... 7 2.1. Plán projektu... 8 3. Další údaje o projektu... 9 3.1. Připravenost projektu k realizaci... 9 3.1.1. Majetkoprávní vztahy projektu (Povinné jen pro projekty vývoje SW)... 9 3.1.2. Finanční připravenost projektu... 9 3.1.3. Metodická připravenost projektu... 9 3.2. Ekonomické parametry projektu... 9 3.2.1. Hodnota výdajů a ekonomická náročnost projektu.... 9 3.2.2. Personální náročnost projektu... 12 3.3. Plán zavedení, údržby, dlouhodobá udržitelnost výstupů projektu... 12 4. Vyjádření k bezpečnostním aspektům... 13 5. Upozornění a doporučení... 13 6. Přílohy... 13 Historie verzí Verze Datum Poznámky k verzi 2.0 31. 10. 2016 Nová verze metodického pokynu odpovídající inovované podobě formuláře žádosti o stanovisko OHA ve verzi 2.0 z října 2016.
Ú 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 2. 11. 2015 č. 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). Způsob podání žádosti: Žádost je podána MVČR, Odboru Hlavního architekta egovernmentu (OHA) do datové schránky ID: 6bnaawp. Žádost je ve formě volného dopisu obsahujícího text žádám o posouzení projektu dle usnesení vlády č. 889 ze dne 2. listopadu 2015 na hlavičkovém papíře (v šabloně) organizace žadatele podepsaný osobou oprávněnou k podání žádosti jménem organizace. Přílohou takovéto Žádosti je vyplněný formulář žádosti o stanovisko OHA včetně všech případných příloh tohoto formuláře. Posuzování a finanční limit (6 mil. Kč ročně) se dle Základních zásad vztahuje na záměr vydat prostředky, bez ohledu na to, kolika projekty či soutěžemi bude realizace záměru provedena. Pokud se více záměrů týká jednoho řešení, pak je možno žádost o stanovisko k těmto záměrům spojit do jediné žádosti. 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 Informačního systému Datových schránek na adresu původního Žadatele. Pro urychlení vyřízení je možné konzultovat projekt ještě před podáním žádosti samotné. Způsob vyplnění Formuláře žádosti. Formulář žádosti obsahuje tabulky k vyplnění, do které vkládejte požadované informace do příslušných buněk. Tento zkrácený vzor žádosti byl připraven pro použití v případech záměru uzavřít smlouvu o provozu, podpoře, údržbě a podobném k existujícímu ICT řešení, jehož aplikační a technická architektura se těmito pracemi PODSTATNĚ nemění. Pokud by v rámci projektu (záměru) mělo dojít ke ZMĚNĚ EXISTENCE (vzniku či zániku) jakéhokoli prvku enterprise architektury ICT řešení (například aplikační komponenty, rozhraní, komunikačního kanálu), spojeného se záměrem, a pokud takovou změnu bylo možno plánovat či předvídat, například na základě zastarávání některé z komponent nebo podle plánu legislativních prací úřadu, pak je potřeba žádat s využitím formuláře typu A. Zkrácení formuláře B spočívá v rozdělení splnění povinnosti kontroly a schválení konzistence architektury projektu s architekturou egovernmentu do takových časových okamžiků, kdy již budou operativní i strategické změny architektury známy. Formulář B byl za tím účelem rozdělen do tří dílčích formulářů: Formulář B1 žádost o stanovisko OHA k záměru, spojená se závazkem zpracovatele průběžně předem informovat OHA o dílčích záměrech provádět úpravy řešení, případně měnit jeho architekturu a se závazkem ve stanovené lhůtě (aktuálně 1 rok, po individuální dohodě s OHA maximálně 2 roky, od obdržení rámcového souhlasu) seznámit OHA s popisem celkové architektury předmětného řešení. Formulář B2 žádost o stanovisko OHA ke každé připravované dílčí změně řešení, realizované v rámci smlouvy, pokud bude mít dopad do architektury řešení a jeho shody s architekturou egovernmentu a 3
současně o všech úpravách řešení, které budou mít dopad do jeho architektury nebo jejichž pracnost přesáhne 100 člověkodní (v souhrnu interních a externích) či výdaj přesáhne 1 mil. Kč. Formulář B3 žádost o stanovisko OHA k celkové architektuře předmětného řešení v okamžiku podání této žádosti. 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 nevyplnili záměrně. V případě, že architektura vašeho projektu, popsaná ve formuláři žádosti, není v souladu s architektonickými principy Národní architektury VS, požadavky na soulad řešení s kontextem architektury úřadu, požadavky na soulad řešení s kontextem architektury egovernmentu, architektonickými vzory řešení sdílených služeb egovernmentu apod., ale přesto existuje objektivní důvod realizovat jej žádaným způsobem, vyberte z rozbalovacího seznamu v příslušné části formuláře, že žádáte o výjimku, a pro každou takovou výjimku vyplňte žádost o udělení výjimky, kterou naleznete na webu OHA 1 a uveďte žádost o výjimku do poslední kapitoly s názvem Přílohy. 1 http://www.mvcr.cz/clanek/hlavni-architekt-egovernmentu.aspx 4
1. Z Á K L A D N Í P O D M Í N K Y P R O J E K T U 1.1. Úvodní informace o zpracovateli projektu Zde uveďte základní identifikační údaje Vaší organizace, která podle usnesení vlády vystupuje současně jako žadatel o stanovisko i jako zpracovatel projektu. Organizace zpracovatele uveďte plný oficiální název organizace, adresu sídla a identifikační číslo (IČ). Ředitel pro informatiku nebo Statutární zástupce uveďte jméno a příjmení, název zastávané funkce v organizaci, mailovou adresu a telefonní kontakt osoby, která svým podpisem stvrzuje podání žádosti o stanovisko OHA, a která je k tomu oprávněná podpisovým řádem organizace. Kontaktní osoba projektu uveďte jméno a příjmení, název zastávané funkce v organizaci, mailovou adresu a telefonní kontakt osoby, na níž se OHA může obrátit s případnými žádostmi a nejasnosti souvisejícími s žádostí o stanovisko. V případě, že se nejedná o interního zaměstnance organizace, uveďte k funkci rovněž název organizace. Architekt projektu uveďte jméno a příjmení, název zastávané funkce v organizaci, mailovou adresu a telefonní kontakt osoby, která při přípravě projektu působí v roli architekta. V případě, že se nejedná o interního zaměstnance organizace, uveďte k funkci rovněž název organizace. Datum vypracování žádosti datum dokončení posledních úprav formuláře žádosti o stanovisko. V případě podávání aktualizované žádosti toto pole nezapomeňte změnit. 1.2. Shrnutí charakteristik projektu uzavření smlouvy Název projektu srozumitelný název projektu, k němuž je podávána žádost o stanovisko. Nepoužívejte zkratky, které nejsou všeobecně známé v prostředí ICT nebo ve veřejné správě. Hlavní cíl projektu stručně rozepište výstup projektu, tedy co bude projektem realizováno. Termín plánovaného zahájení realizace projektu (zahájení výstavby, je-li součástí) předpokládané datum zahájení realizačních prací na projektu. Jedná se o zahájení vývojářských, implementačních nebo obdobných prací předcházejících ostrému provozu. Neuvádějte datum výběrového řízení, ale častěji až datum podpisu či začátku účinnosti smlouvy. Pokud projekt nezahrnuje realizační fázi, ale jedná se např. o využívání aplikačního nástroje jako služby, pak tento údaj nevyplňujte. Termín plánovaného dokončení realizace projektu (uvedení do ostrého provozu) předpokládané datum dokončení realizačních prací na projektu včetně testování. Jedná se o datum předání posledních výstupů projektu do ostrého nebo pilotního provozu. Pokud projekt nezahrnuje realizační fázi, ale jedná se např. o využívání aplikačního nástroje jako služby, pak tento údaj nevyplňujte. Termín plánovaného zahájení provozu (spuštění ostrého provozu) předpokládané datum zahájení ostrého provozu výstupů projektu. Jedná se o datum předání prvních výstupů projektu do ostrého nebo pilotního provozu. Pokud projekt nezahrnuje provozní podporu, maintenance nebo rozvoj, pak tento údaj nevyplňujte. Termín plánovaného ukončení provozu (konec smluvního vztahu s dodavatelem) předpokládané datum ukončení smluvního vztahu na provoz výstupů projektu. Jedná se o datum, ke kterému bude projekt ukončen, bude uzavřena navazující smlouva na provoz výstupů projektu. Pokud projekt nezahrnuje provozní podporu, maintenance nebo rozvoj, pak tento údaj nevyplňujte. Předpokládaný počet let využívání výstupů projektu (počet let od začátku využívání do konce využívání) hrubý odhad počtu let od zahájení ostrého provozu do předpokládaného vyřazení z provozu. Vyřazením z provozu je myšleno nahrazení jiným projektem nebo ukončení bez náhrady. V případě, že je předpokládáno využívání (provoz) více než 5 let, pak je možné uvést jen Více než 5 Určení věcného správce, technického správce a provozovatele Věcný správce Věcný správce (gestor) je útvar nebo organizace, jenž rozhoduje o obsahu a pravidlech fungování služby. Tzn., že je zodpovědný za definici procesu, který službu dodává, definici funkcionality a dat podpůrné ICT služby, za shodu funkcionality aplikace s legislativou a za definici objemových a kvalitativních parametrů podpůrné ICT služby (počet uživatelů, doba provozu služby, dostupnost služby, doba odezvy atd.). Věcným správcem může být pouze OVM (ministerstva, správní úřady, samosprávné celky). Každá agendová služba má vždy jen jednoho správce. Je jím ministerstvo zodpovědné za službu 5
(agendu). Provozní služba mívá obvykle více správců. Když služba má jednoho správce, jedná se o centralizovaně řízenou službu. Technický správce Technický správce je útvar nebo organizace, jenž rozhoduje o technickém zajištění služby (jakým softwarem a hardwarem bude služba realizována). Stanovuje podmínky realizace podpůrných ICT služeb tak, aby služba byla dodávána v souladu s požadavky věcného správce. Technický správce je pro každou veřejnou službu jen jeden, určuje ho věcný správce, a to na základě obecně platných pravidel. Provozovatel Provozovatel (poskytovatel) je útvar nebo organizace, jenž službu provozuje a dodává zákazníkům. Provozovatelů služby může být více (viz např. výdej občanských průkazů, e-mail). Když služba má jednoho provozovatele, jedná se o centralizovaně provozovanou službu. Aktuální (počáteční) plánované (rozpočtované) výdaje projektu (položka posledního řádku tabulky TCO v kapitole 3.2.1) v Kč bez DPH předběžný kvalifikovaný odhad výše hodnoty projektu v českých korunách bez DPH. Jedná se o součet všech plánovaných smluv, objednávek apod., kterými bude projekt realizován a provozován. Je nutné zahrnout i výši všech opcí a práv čerpat služby, pokud jsou k projektu zamýšlena. Jedná se o součet sloupců 1 a 2 tabulky v kapitole 3.2.1, resp. o celkový součet těchto sloupců uvedený v řádku Celkem žádáno uvedené tabulky. TCO 5 (součet sloupce 3 tabulky TCO v kapitole 3.2.1) v Kč bez DPH předběžný kvalifikovaný odhad výše externích výdajů projektu v českých korunách bez DPH při započtení přesně 5-letého provozu. Jedná se o celkový součet sloupce 3 tabulky v kapitole 3.2.1. Prakticky jde o projekci výše výdajů na realizaci projektu a provoz jeho výstupů, pokud by byl provoz spočítán přesně pro 5 let od uvedení do ostrého provozu. 1.3. Potřebnost a výstupy projektu Výchozí stav popis výchozí situace projektu popište výchozí stav, ze kterého projekt vychází. Příklad výchozí situace může být zastaralý informační systém, který již v průběhu příštího roku nebude odpovídat legislativě. Projekt bude navázán na určitý projektový okruh v rámci egovernmentu a bude odpovídat přijatým strategiím. Popis projektu podrobnější popis v čem projekt spočívá, jaký má rozsah a návaznosti. Přehled výstupů (plnění) projektu, smlouvy seznam všeho, co bude projektem realizováno. Příkladem výstupů je informační systém, upravená rozhraní napojených systémů nebo zakoupené licence. Označení výstupu jedinečné označení výstupu názvem nebo číslem. Množství a jednotka množství a jednotky množství (nejčastěji ks kusy) výstupu, tedy kolik jednotek dané položky je výstupem (např. počet rozhraní informačních systémů nebo počet nakoupených serverů) Vysvětlení výstupu bližší popis upřesňující název výstupu. Předpokládaná cena za jednotku (v Kč bez DPH) informace o předpokládané ceně za položku. 1.4. Právní klasifikace předmětu projektu Klasifikace předmětu projektu dle zákonů egovernmentu Druh informačního systému dle klasifikace zák. 365/2000 Sb., o informačních systémech VS pokud je předmětem projektu informační systém, tak uveďte, jakého je druhu dle popisů zák. o ISVS: Informační systém veřejné správy Informační systém nakládající s utajovanými skutečnostmi Provozní informační systém Informační systém veřejné správy nepodléhající zák. č. 365/2000 Sb., o informačních systémech veřejné správy Projektem není informační systém Je projektem Agendový informační systém dle zák. 111/2009 Sb., o základních registrech pokud je předmětem projektu informační systém, tak uveďte, zda je agendovým informačním systémem dle zák. č. 111/2009 Sb. (Ano) nebo není (Ne). Budou předmětem projektu přijímány a odesílány datové zprávy dle zák. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů? uveďte, zda bude předmět projektu propojen s informačním systémem datových schránek pro příjem nebo odesílání datových zpráv (Ano) 6
nebo nebude (Ne). Pro kladnou odpověď stačí příjem nebo odesílání automatizovaně prostřednictvím systému spisové služby. Klasifikace dle zák. o kybernetické bezpečnosti uveďte, do jaké míry podléhá předmět projektu zák. č. 181/2014 Sb., o kybernetické bezpečnosti: Kritická informační infrastruktura Významný informační systém Nespadá pod definici dle ZoKB Vazba projektu na informace v Portálu veřejné správy Jsou na Portálu veřejné správy popsány všechny související životní situace v souladu s vyhláškou č. 442/2006 Sb.? pokud je předmětem projektu podpora řešení některé životní situace, uveďte, zda bude při spuštění do ostrého provozu popsána životní situace v souladu s vyhláškou č. 442/2006 Sb., kterou se stanoví struktura informací zveřejňovaných o povinném subjektu způsobem umožňujícím dálkový přístup. Bude k dispozici pro přístup občanů k el. službám úřadu využita navigace v Portálu veřejné správy? pokud je předmětem projektu dotčena některá služba úřadu, která bude k dispozici veřejně v elektronické podobě, uveďte, zda bude na Portálu veřejné správy uveden hypertextový odkaz na uživatelské rozhraní této služby. Jsou na Portálu veřejné správy dostupné všechny formuláře využívané projektem? pokud je předmětem projektu dotčena struktura, dostupnost nebo zpracování příjmu elektronických formulářů, uveďte, zda bude na Portálu veřejné správy uveden hypertextový odkaz na tyto formuláře. Pro Vazbu projektu na informace v PVS uveďte následující údaje: Vyberte odpověď na otázku ve sloupci Klasifikace z možností Ano, Ne, Nerelevantní. Nerelevantní je tehdy, pokud předmět projektu nezahrnuje nic, co by mohlo být publikováno na Portálu veřejné správy (např. interní informační systémy nebo datová centra). Vysvětlete bližší objasnění k souladu/souvislosti předmětu projektu se zveřejněnými informacemi. 2. A R C H I T E K T O N I C K É I N F O R M A C E O P R O J E K T U V této kapitole jsou uvedeny informace o všem, co ovlivňuje motivaci a obsah předkládaného projektu, zejména pak všechny aspekty struktury a chování části úřadu, zahrnuté do projektu. Dále pak kontext architektury úřadu ve vztahu ke sdíleným službám egovernmentu. Struktura architektonické části dokumentu vychází ze struktury domén obsahu Národní architektury VS ČR. Vysvětlení podstatných architektonických myšlenek spojených se záměrem uzavřít smlouvu vysvětlete všechny podstatné architektonické myšlenky, ke kterým má uzavření smlouvy přispět. Zejména se to týká případů, kdy součástí smlouvy je i drobný rozvoj. 7
Prohlášení o respektování strategických cílů a architektonických principů egovernmentu vyberte, zda souhlasíte s uvedeným prohlášením. Pokud ne, nemůže být žádost schválena prostřednictvím tohoto typu žádosti. Prohlášení o závazku zpracovatele žádat o stanovisko HAeG k průběžným změnám řešení vyberte, zda souhlasíte s uvedeným prohlášením. Pokud ne, nemůže být žádost schválena prostřednictvím tohoto typu žádosti. Prohlášení o závazku zpracovatele žádat o stanovisko HAeG k cílové architektuře řešení a jeho roadmapě vyberte, zda souhlasíte s uvedeným prohlášením. Pokud ne, nemůže být žádost schválena prostřednictvím tohoto typu žádosti. Publikování výstupů v podobě otevřených dat Plánujete publikovat část datové základny projektu jako otevřená data? uveďte, zda budou z řešení, jež je předmětem projektu, generovány datové sady a publikovány v podobě otevřených dat dle zák. č. 106/1999 Sb., o svobodném přístupu k informacím, včetně uvedení v Národním katalogu otevřených dat. Nerelevantní se použije výhradně tehdy, pokud není předmětem projektu dotčena žádná databáze nebo databáze obsahuje pouze data, která není možné publikovat ani v podobě souhrnných statistik. Č. výjimky v případě, že je v předchozí položce zvolena možnost Ne, žádáme výjimku, tak uveďte číslo příslušné žádosti o výjimku, jaké má v poslední kapitole Přílohy. Jaké datové sady plánujete publikovat a kdy? uveďte rámcově jaká data/datové sady předpokládáte k publikaci a v jakém termínu. Využití centrálního nákupu softwarových produktů vysvětlete, které licence standardizovaných SW produktů budete pořizovat podle rámcové smlouvy zajištěné Ministerstvem vnitra. Případně vysvětlete, proč jste se rozhodli tohoto instrumentu nevyužít. Informace o aktuálně uzavřených rámcových smlouvách naleznete na adrese http://www.mvcr.cz/smlouvy-na-software.aspx Katalog komponent, které bude možné znovu využít v jiných projektech (nepovinné) seznam částí (prvků) řešení se mají stát opakovaně využitelnými stavebními bloky pro navazující projekty úřadu, resortu či egovernmentu. Například zda je vyžadováno dodání aplikace pod open-source licencí nebo zda prvek bude poskytovat sdílené služby jiným prvků v rámci organizace nebo i jiným organizacím. 2.1. Plán projektu Zde popište, jaká je základní struktura projektu z hlediska jeho fází /milníků a jaké jsou návaznosti na ostatní projekty. Hrubý harmonogram předloženého projektu seznam jednotlivých fází a milníků projektu, včetně jejich začátků a konců, základní náplně a návazností na ostatní fáze (pokud existují). Pro harmonogram projektu uveďte následující údaje: Fáze / milník název nebo označení fáze či milníku. Začátek datum zahájení fáze nebo datum nabytí milníku. Konec datum dokončení fáze. Základní náplň popis co je ve fázi projektu vykonáváno nebo čím je dosaženo milníku. Navazuje na výčet fází, na které tako fáze nebo milník navazují. Projektový kontext předkládaného projektu (v rozvojovém programu, portfoliu úřadu) Předchozí projekty název a popis všech jednotlivých projektů, na které tento projekt navazuje a vysvětlení této návaznosti. Souběžné projekty název a popis všech jednotlivých projektů, které budou probíhat souběžně s tímto projektem a mají s ním nějakou souvislost (věcnou, místní či logickou) a vysvětlení této souvislosti. 8
Navazující projekty název a popis všech jednotlivých projektů, jejichž realizace se předpokládá, a které na tento projekt budou navazovat a vysvětlení této návaznosti. Vysvětlení plánu projektu vysvětlete, jakou roli v plánu rozvoje této oblasti úřadu hraje právě předkládaný projekt. 3. D A L Š Í Ú D A J E O P R O J E K T U Zde budou uvedeny všechny informace, které musí OHA ve svém stanovisku podle usnesení vlády č. 889/2015 zohlednit mimo konzistence architektury s architekturou egovernmentu, tj. zejména: potřebnost, účelnost, hospodárnost, realizovatelnost, připravenost, přínos, ekonomickou a personální náročnost, způsob řízení, analýzu rizik a navržený způsob řízení projektu. Tyto údaje by měly být známé především vedoucímu projektu popřípadě pracovníkovi sledujícímu dané oblasti v rámci projektu. 3.1. Připravenost projektu k realizaci 3.1.1. Majetkoprávní vztahy projektu (Povinné jen pro projekty vývoje SW) Tato kapitola se vyplňuje výhradně pro projekty, jejichž součástí je vývoj aplikace na míru pro organizaci. Cílem této kapitoly je identifikovat, zda byla přijata základní pravidla zabránění vzniku závislosti na konkrétním dodavateli (vendor-lock). Pro každou otázku odpovězte Ano (zaškrtnutí boxu) nebo Ne (ponechání nezaškrtnutého boxu) a vysvětlete jakým způsobem a v jakém rozsahu bude otázka plněna či neplněna. Máte možnost přejít k jinému dodavateli, pokud stávající nebude plnit (tj. existuje více než jeden dodavatel)? Budou vám udělena výhradní práva k užívání k dodávanému produktu? Budou vám udělena nevýhradní práva k užívání k dodávanému produktu? Budou práva k autorskému dílu nějak omezena (IČO, konkrétní uživatel, převoditelnost a další šíření, úpravy produktu, parametry )? Budete mít přístup ke zdrojovému kódu pro čtení? Bude vám či třetímu subjektu umožněno provádět údržbu, měnit produkt, upravovat jej či rozšiřovat bez souhlasu dodavatele? Budete mít přístup k aktuální technické dokumentaci produktu? Obsahuje budoucí smlouva ujednání o vyloučení odpovědnosti za výpadky fungování? 3.1.2. Finanční připravenost projektu Pro každou otázku odpovězte Ano (zaškrtnutí boxu) nebo Ne (ponechání nezaškrtnutého boxu) a případně upřesněte druh financování a způsob, jakým jste si finance z daného zdroje zajistili či zajistíte. Případně zda je pro projekt životně důležité dané financování. 3.1.3. Metodická připravenost projektu Pro každou otázku odpovězte Ano (zaškrtnutí boxu) nebo Ne (ponechání nezaškrtnutého boxu) a případně upřesněte druh financování a jakým způsobem je dané zajištění zapracováno do projektu, případné vysvětlení, proč tomu tak není a jaký to může mít dopad. 3.2. Ekonomické parametry projektu 3.2.1. Hodnota výdajů a ekonomická náročnost projektu. Po dobu prací RVIS a jejího pracovního výboru na konceptu TCO je vyplnění interních nákladů úřadu a ostatních spolupracujících OSS dočasně nepovinné. Po tuto dobu je ve formuláři vyžadováno zjednodušené zadání ekonomické náročnosti projektu. Do hodnoty TCO jsou tedy dočasně vyžadovány k započtení výhradně externí výdaje placené jiným subjektům. Pro odhad plánovaných výdajů a/nebo nákladů projektu, se v rámci záměrného zjednodušení metodiky výpočtu TCO pro ICT VS ČR použijí jenom ty nákladové položky z plánu nákladových kategorií účelového TCO 9
modelu (viz níže), které nejsou označeny oranžově, tj. A, B, C, D, E, F, G, a případně X pro SaaS, jež odpovídají plánovaným přímým výdajům a nákladům na projekt. Do plánu externích přímých výdajů je nutno započítat i výdaje za dodavatelem původního řešení při přípravě migrace a ukončení jeho provozu nebo archivaci viz nákladová komponenta C8 Pořízení/Migrace dat. Obdobně i interní náklady na totéž v odhadu celkové ekonomické náročnosti. Model účelového členění nákladů pro ukazatel TCO: Ukazatel TCO pro ICT VS ČR Legenda: Jednorázové náklady Průběžné náklady A. Předběžné analýzy, zadání, výběr a nákup B. Pořízení Hardware/ Software (ne SaaS) C. Vývoj, imlementace / integrace a zk. provoz D. Provoz a podpora řešení (ne SaaS) E. Hardware/Software údržba a úpravy (ne SaaS) F. Projekty postupného zlepšování řešení (částečně pro SaaS) G. Projekty Upgrade (ne SaaS) H. Zvýšené náklady užívání řešení I. Konzervace a ukončení řešení (ne SaaS) X.Předplatné na služby (pouze SaaS) Z. Ostatní režijní náklady A1. Předběžné studie (proveditelnosti, ) A2. Náklady na proces zadání, výběru a nákupu B1. Technická infrastruktura (HW, sítě, ) B2. Stavební infrastruktura (budovy, chlazení ) B3. Systémové SW licence B4. Vývojové SW licence B5. Aplikační SW licence C1. Projektové řízení C2. Návrh změněných procesů C3. Řízení organizačních změn (OCM) C4. Technické nastavení řešení C5. Obsahové (aplikační) nastavení řešení C6. Vývoj aplikace nebo úprav na míru C7. Realizace rozhraní C8. Pořízení / Migrace dat C9. Testování C10.Školení C11.Předání do provozu a ověřovací provoz D1. Provoz budov a technologií dat. centra D2. Provoz a podpora IT tech. syst., OS a DB D3. Provoz a podpora aplikací E1. Údržba technologické infrastruktury E2. Údržba systémového SW a DB E3. Údržba aplikačního SW E4. Průběžné úpravy řešení /aplikačního SW F1. Funkční (procesní) zlepšování F2. Technické zlepšování F3. Roll-out projekty F4. Projekty (nákladové) optimalizace řešení G1. Aplikační upgrade G2. Upgrade systémového SW G3. Technologický upgrade G4. Infrastrukturní upgrade H1. Náklady ze ztráty produktivity H2. Náklady spojené s užíváním řešení I1. Útlum a archivace řešení I2. Příprava dat pro migraci I3. Likvidace zařízení X1. Nákup aplikačního SW jako služby (SaaS) Z1. Ostatní provozní režie Z2. Ostatní správní režie 10
Hrubý odhad hodnoty záměru nákupu služeb či investic (externích výdajů), souvisejících s informačními a komunikačními technologiemi (projektu) Zdroje, které projekt a jeho řešení použijí, ale úřad je již má a nemusí za ně tudíž vydávat nové externí výdaje, se do tohoto odhadu nezapočítají, například budova existujícího datového centra, pracovní stanice referentů. Do členění dle metodiky TCO vyplňte následující sloupce: 1 Výdaje na realizaci (výstavbu) projektu výdaje hrazené externím subjektům za realizaci projektu. Realizací projektu jsou myšleny veškeré činnosti prováděné před spuštěním ostrého provozu. Například se jedná o výdaje na vývoj informačních systémů, nákup licencí a hardware, tedy především o řádky A, B a C. V případě, že je projekt zaměřen na provozní stránku a realizační fázi neobsahuje, tak může být sloupec nulový. 2 Výdaje na provoz a rozvoj (do konce aktuální smlouvy) výdaje hrazené externím subjektům za dobu provozu projektu. Započítejte veškeré předpokládané výdaje, které umožňují chystané obchodní vztahy na období od spuštění ostrého provozu do ukončení účinnosti smluv či objednávek. Například se jedná o výdaje na maintenance a rozvoj informačních systémů nebo platby za licence s termínem vypršení, tedy především o řádky D, E, F a G. V případě, že je projekt zaměřen jen na výstavbu/realizaci a provozní podpora není požadována, tak může být sloupec nulový. 3 TCO 5 (1 plus 2 odhadnutý na 5 let) celkové externí výdaje projektu za dobu jeho realizace (výstavby) a přesně 5 let provozu ode dne spuštění do ostrého provozu. V případě, že je v rámci projektu plánováno zasmluvnění provozu a rozvoje na období 5 let, pak by TCO 5 mělo být rovno součtu sloupců 1 a 2. Pokud je projekt plánován včetně podpory na dobu delší než 5 let, tak se k výdajům na realizaci projektu připočítají provozní a rozvojové výdaje na prvních 5 let ostrého provozu. Pokud je plánován projekt včetně podpory na dobu kratší než 5 let od uvedení do ostrého provozu, tak se k výdajům na realizaci (výstavbu) připočítají odhadnuté výdaje na 5 let ostrého provozu. V tomto případě je nutné neopomenout připočítat i výdaje na očekávatelný rozvoj aplikací a obměnu technického vybavení. Do řádků tabulky ekonomické náročnosti uveďte následující údaje: Počet měsíců trvání fáze počet měsíců, které bude trvat příslušná fáze definovaná sloupcem. V sloupci 1 se tedy bude jednat o počet měsíců uplynulých od Termínu plánovaného zahájení realizace projektu (zahájení výstavby, je-li součástí dle údaje v kapitole 1.2) do Termínu plánovaného dokončení realizace projektu (uvedení do ostrého provozu dle údaje v kapitole 1.2). V sloupci 2 se tedy bude jednat o počet měsíců uplynulých od Termínu plánovaného zahájení provozu (spuštění ostrého provozu dle údaje v kapitole 1.2) do Termínu plánovaného ukončení provozu (konec smluvního vztahu s dodavatelem dle údaje v kapitole 1.2). V sloupci 3 se tedy bude jednat o počet měsíců vyplněný ve sloupci 1 plus 60 měsíců provozu. A. až Z. částky externích výdajů pro jednotlivé skupiny dle metodiky TCO. Celkem součet finančních částek uvedených v příslušném sloupci v řádcích A. až Z. Celkem žádáno součet celkové sumy částek sloupců 1 a 2, tedy celková hodnota smluv a objednávek, které zajistí naplnění předmětu projektu. Popis funkčního celku, který je projektem rozšiřován či upravován (pokud existuje) popište funkční celek, do kterého bude předmět projektu zasazen. Funkční celek je definován v následujícím odstavci. Cílem popisu je sdělit, je velký je funkční celek a co vše zahrnuje. V případě, že předmět projektu nebude součástí žádného většího funkčního celku, tak uveďte jen tuto skutečnost. Situace, kdy projekt není součástí většího funkčního celku, znamená, že projekt pokrývá funkční celek v celé jeho komplexitě a je tedy sám o sobě funkčním celkem. Funkční celek funkční celek znamená řešení v celé jeho komplexitě, jak je v prostředí organizace/státu nasazeno. Příkladem budiž informační systém, ke kterému je realizován projekt na vytvoření nového modulu systému. Pak je projektem pouze nový modul, ke kterému je vyplněna žádost. Funkčním celkem je ovšem celý informační systém zahrnující všechny jeho moduly a rozhraní. Pro definici funkčního celku není relevantní, kolik je k němu uzavřeno smluv na podporu nebo kolik dodavatelů vytvářelo jeho jednotlivé části. Rozhodující je technologická provázanost (např. SOA) anebo logická souvislost. Příklady funkčních celků je ADIS (daňový systém), IIS ČSSZ (integrovaný informační systém správy soc. zabezpečení), datové centrum (pro případ rozšiřování o nové technologie) apod. Plánované 5leté externí výdaje celého funkčního celku (mimo tento projekt) uveďte, kolik dalších Kč bez DPH předpokládáte vynaložit na provoz a rozvoj funkčního celku v následujících 5 letech. Do odhadu nezahrnujte výdaje, ke kterým se vztahuje tato žádost (tj. pokud tato žádost pokrývá celých následujících 5 let 11
provozu a veškerého rozvoje, bude zde nula). Do této částky nezapomeňte započítat i výdaje na úpravy spojené s novými právními předpisy, jež mohou v následujících 5 letech vstoupit v účinnost. Stejně tak započítejte hodnotu všech smluv na podporu jednotlivých částí funkčního celku. V případě, že projekt, k němuž je vztažená tato žádost není součástí žádného většího funkčního celku, bude uvedena hodnota ze sloupce 3 předchozí tabulky ponížená o hodnotu uvedenou tamtéž v řádku Celkem žádáno. Vysvětlení a komentář k souhrnu výdajů a ekonomické náročnosti projektu jakékoli potřebné vysvětlující komentáře k odhadu externích výdajů projektového záměru a k celkové ekonomické náročnosti projektu (TCO). 3.2.2. Personální náročnost projektu Odhady kapacitní náročnosti realizace projektu (korespondující s TCO) Interní zaměstnanci organizace pracovníci podílející se na realizaci projektu, kteří májí uzavřenu pracovní smlouvu, služební poměr či dohodu přímo s organizací žadatele o stanovisko. Ostatní zaměstnanci VS pracovníci podílející se na realizaci projektu, kteří májí uzavřenu pracovní smlouvu, služební poměr či dohodu s jinými orgány veřejné správy. Tuto položku vyplňujte, jen pokud je to pro projekt významné. Externí dodavatelé pracovníci dodavatelů, jejichž služby poskytují dodavatelé na zvláštní objednávku (požadavek) organizace. Tuto položku vyplňujte, jen pokud je v projektu požadováno dodání konkrétního objemu prací vyjádřených v množství hodin či dnů. Pro seznam odhadů uveďte následující údaje: Počet osob počet fyzických osob, bez ohledu na výši pracovního úvazku věnovaného projektu. Počet přepočtených úvazků počet přepočtených úvazků dle FTE (Full Time Equivalent), tedy počet plných pracovních úvazků složených ze všech dílčích úvazků jednotlivých fyzických osob. Vysvětlení rolí v projektu bližší objasnění jaké role a jaké práce budou jednotlivé druhy pracovníků zastávat. Odhady dopadů do změn počtu systemizovaných míst spojených s projektem Pro realizaci projektu počet nově vytvořených systemizovaných míst pro účely realizace projektu (od zahájení do spuštění ostrého provozu). Pro vlastní výkon podpořené externí veřejné služby počet nově vytvořených systemizovaných míst pro účely výkonu agendy anebo poskytování veřejné služby. V případě, že vlivem projektu dochází ke snížení počtu systemizovaných míst, uveďte zápornou hodnotu. Pro IT podporu provozu počet nově vytvořených systemizovaných míst IT specialistů pro účely podpory provozu projektu. V případě, že vlivem projektu dochází ke snížení počtu systemizovaných míst, uveďte zápornou hodnotu. Pro seznam odhadů uveďte následující údaje: Uvnitř úřadu změny týkající se organizace realizující projekt. Jinde ve VS změny týkající se jiných orgánů veřejné moci. Vysvětlení změny a umístění systemizovaných míst bližší objasnění kde a jakých pozic se změny budou týkat. Vysvětlení a komentář k personální náročnosti projektu další vysvětlení či komentář k personální náročnosti, který nebylo vhodné napsat k předcházejícím částem. 3.3. Plán zavedení, údržby, dlouhodobá udržitelnost výstupů projektu Zde popište Váš plán na dlouhodobou udržitelnost výstupů projektu a jejich údržbu. Hlavním cílem je zajistit, aby výstupy bylo možné udržovat po stanovenou dobu a aby byla zajištěna kontinuita výstupů i po stanovené udržitelnosti. Plánovaný ověřovací provoz jednotlivých výstupů projektu seznam výstupů projektu s plánovaným ověřovacím (pilotním) provozem a plánovaná doba trvání tohoto provozu. 12
Plánovaná životnost jednotlivých výstupů projektu seznam výstupu projektu s uvedením jejich plánované životnosti v letech a stručným popisem v budoucnu plánovaných změn a rozvoje. Bude podpora zahrnovat rovněž udržování řešení v souladu s novými právními předpisy (tzv. legislativní update)? Vysvětlete v jakém rozsahu a jakým způsobem pokud projekt zahrnuje i podporu informačního systému, vysvětlete v jaké šíři je do podpory zahrnut legislativní update a proč právě v této. Legislativní update je smluvní ustanovení, kterým se dodavatel zavazuje udržovat systém v souladu s platnou legislativou a při změně právních předpisů na své náklady provede příslušnou změnu systému, kterou předá k akceptaci. Jak je zajištěn další budoucí rozvoj předmětné oblasti a její ICT podpory stručný popis představy zajištění dalšího rozvoje předmětné oblasti a její ICT podpory. Jak je zajištěno řízené ukončení životnosti jednotlivých výstupů projektu a případný přechod na další řešení stručný popis zajištění ukončení životnosti jednotlivých výstupů projektu. Jakým způsobem bude zajištěno ukončení stávajícího řešení a přechod na případné nové řešení? Je ošetřena migrace z budovaného řešení na případné nové řešení? 4. V Y J Á D Ř E N Í K B E Z P E Č N O S T N Í M A S P E K T Ů M Předkladatel prohlašuje, že předkládaný projekt bude realizován plně v souladu s níže uvedeným prohlášením zde se případně uvede vyjádření k připomínkám bezpečnostních složek, které dostaly žádost k posouzení. Toto vyjádření se vyplňuje až na výzvu OHA, který dostal od příslušných bezpečnostních složek připomínky k žádosti. Tyto připomínky budou zpracovateli oficiálně poslány a bude se čekat na zpětnou reakci. Do doby než bude žádost doplněna o soulad s připomínkami, nemůže být vydáno souhlasné stanovisko. Praktický postup v tomto případě je následující: Zpracovatel pošle žádost o stanovisko OHA. V případě, že bezpečnostní složky nebudou mít připomínky, vydá OHA své stanovisko ve lhůtě do 30 dnů po obdržení (ve výjimečných situacích do 60 dní). V případě, že bezpečnostní složky budou mít připomínky, zašle OHA tyto připomínky zpět zpracovateli. Zpracovatel následně tyto připomínky nakopíruje do příslušného políčka, čímž s nimi vyjádří souhlas a takto aktualizovanou žádost o stanovisko zašle znovu oficiální cestou OHA. 5. U P O Z O R N Ě N Í A D O P O R U Č E N Í Upozornění a doporučení jakékoli další informace, které je třeba k žádosti doplnit a nebylo vhodné je uvést v žádné jiné části formuláře. 6. P Ř Í L O H Y Přílohy seznam všech příloh žádosti o stanovisko OHA. Nejčastěji se bude jednat o žádosti o výjimku. Pro seznam příloh uveďte následující údaje: Typ výběr zda se jedná o Žádost o výjimku, Dokumentaci nebo jiný typ přílohy. Číslo a název přílohy název nebo označení přílohy. Upřesnění výjimky/přílohy popis co je obsahem přílohy, v případě žádosti o výjimku upřesnění o výjimku z jakého nesouladu se jedná. 13