====== Řízení jednotlivých ICT řešení ====== Zákon č. 365/2000 Sb. předpokládá, že v rámci Informační koncepce ČR bude blíže řešena i problematika řízení informačních systémů veřejné správy. Doporučení MŘICT je vhodné použít v nezměněné podobě a tedy k uplatnění v plném rozsahu ICT portfolia (IT architektury) OVS. Přizpůsobení konkrétním situacím je však jako u jakékoliv jiné metodiky více než vhodné. Řízení jednotlivých IS je možné popsat a návody a akcelerátory k němu ve [[:znalostni_baze|Znalostní bázi]] poskytnout buď se zaměřením na detail fáze a aktivity v etapě životního cyklu IS nebo se zaměřením na typické činnosti a metody, které se sice obvykle vyskytují v určitých fázích, ale mohou se i opakovat a překrývat (např. výběr dodavatele, řízení projektu, zmírnění závislosti na dodavateli apod.). Tato kapitola přináší a kombinuje oba pohledy. Detailní informace a akcelerátory, zejména k výstupům a metodám podle životního cyklu IS přináší připravovaná [[:znalostni_baze|znalostní báze]]. Všechny činnosti při řízení jednotlivých IS musí být vykonávány v kontextu celého úřadu a eGovernmentu ČR a EU, v rámci činností a postupů popsaných dále v [[metody_dokument:rizeni_na_urovni_utvaru_ict|Řízení na úrovni útvaru ICT OVS]] a [[metody_dokument:spoluprace_s_ostatnimi_utvary_uradu_a_egovernmentu|Spolupráce s ostatními útvary úřadu a eGovernmentu]]. ===== Řízení informačních systémů podle etap a fází jejich životního cyklu ===== Bez respektování životních cyklů změn nelze efektivně zajišťovat schopnost ICT služeb (informačních systémů a ICT infrastruktury) pro účely bezpečného a kvalitního výkonu služeb veřejné správy. Toto konstatování platí jak z hlediska životnosti technických komponent, platnosti smluvní podpory poskytovatelů, tak zejména z pohledu změn potřeb jednotlivých interních útvarů úřadu a očekávání klientů veřejné správy. V posledních letech došlo postupně k zásadním změnám v počtu a rozsahu ICT služeb úřadů, tento nárůst vyžaduje kvalitnější nastavení správy a řízení ICT a zvyšuje nároky na jejich obsluhu. Mezi zásadní milníky patří práce v elektronické spisové službě, využití základních registrů, povinnosti při správě dat (bezpečnost), povinnosti při správě osobních údajů (GDPR), možnost přenesení vybraných částí mimo úřad ([[nap:egovernment_cloud|Cloud]]) či posilování zájmu o digitální služby veřejné správy. Nelze odhlédnout od nových trendů a inovací v technologické části ICT, kde je primární zátěž na lidské zdroje v různých formách inovačních upgradů a postupném zařazování zcela odlišných technologických přístupů než před deseti lety. Nové systémy v mnoha případech díky jisté zastaralosti musí brát v úvahu staré frameworky a technologie při architektonických návrzích, což zadavatele stojí zvýšené úsilí, a ve většině kdy není vyhnutí i vyšší finanční nároky. Každý informační systém prochází postupnými etapami svého rozvoje, jejichž zlomovým okamžikem je vždy uvedení do produktivního provozu nové (nebo výrazně obměněné) sady služeb, přinášejících pro zadavatele nové byznys hodnoty. Tento okamžik přináší dokončením díla (změny) tzv. přechodovou architekturu, resp. pro danou úroveň poznání a zadání v daném čase na nějaký čas cílovou architekturu systému a celého úřadu. Období, činnosti a stavy mezi každými dvěma takovými okamžiky spuštění služeb s přidanou hodnotou nazýváme jednou etapou života systému. Etapa se tak rovná jednomu průchodu všemi fázemi životního, nebo také vývojového (( Odpovídá angl. zkratce SDLC - Software Development Life Cycle)) cyklu informačního systému, respektive jeho celého funkčního celku. Vývoj života každého IS se tak pohybuje po jakési trvale vzestupné spirále, v případě poklesu zájmu o systém a postupného odebírání funkcí i po následné sestupné spirále, tvořené etapami. Stejně tak, jako ISVS mají oproti komerčním informačním systémům svá specifika, má je nutně i jejich životní cyklus, tzn. při řízení životního cyklu systémů / služeb ICT VS je nutné postupovat odlišně a respektovat jiné zákonné povinnosti a jiné časové termíny. Pro zajištění potřebné adresnosti (kdo odpovídá) lze při současném respektování logiky věcné podstaty činností v životním cyklu ICT služby / informačního / komunikačního systému veřejné správy můžeme průběh každé etapy rozlišovat do těchto fází ((Jiní autoři také užívají výrazů: kroků, stupňů nebo etap, ale tyto pojmy jsou ponechány pro jiné účely.)): - STRATEGIE - PLÁNOVÁNÍ A PŘÍPRAVA (včetně závěrečného návrhu realizace) - REALIZACE - PRODUKČNÍ PROVOZ (včetně řízených změn) - VYHODNOCENÍ - UKONČENÍ SLUŽBY Grafické vyjádření logické návaznosti těchto fází v etapě života IS znázorňuje následující Obrázek: Výsadní postavení mezi životními etapami informačního systému má první a poslední průchod jednotlivými fázemi etapy jeho životního cyklu. První etapa života IS konstituuje jeho existenci, dává mu smysl, účel a zmocnění, formuje dlouhodobě jeho architekturu a platformu. Proto jsou v tomto cyklu akcentovány vnější strategické impulsy a chybí vnitřní vyhodnocení. Poslední životní etapa IS začíná strategickým rozhodnutím o ukončení poskytování služby / existence systému, a končí fyzickou likvidací informačního systému, avšak to celé je také plánovaný a řízený implementační (archivační a likvidační) projekt, procházející fázemi plánování, přípravy a realizace. Všechny ostatní etapy rozvoje IS představují postupné doplňování funkcí informačního systému na základě zhodnocení jeho stavu a potřeb a/nebo na základě vnějšího impulsu - strategické a legislativní změny, nebo jeho technologické a platformové povýšení (upgrade). Etapám života a fázím životního cyklu IS odpovídá i struktura plánování a vyhodnocování nákladů na ně, viz metodika TCO. Pojem „fáze“ znamená určité období podobných nebo spolu úzce souvisejících činností, někdy i velmi dlouhé, neměnné - například fáze produkčního provozu. Vedle toho pojem „etapa“ znamená část cesty od počátku do konce, v tomto případě od jednoho rozsahu produktivních služeb k novému rozsahu a hodnotě produktivních služeb. Etapa se tedy skládá z fází. {{ :metody-dokument:image5.jpg?600 |Základní fáze životního cyklu ICT služby VS a jejich návaznosti}} Rozpad těchto jednotlivých životních etap do struktury: „etapa“ (cyklus) – „fáze“ – „krok“ – „činnost“ – „úkon“, potřebný pro konkretizaci jednotlivých aktivit řízení vychází z Metodické příručky pro potřeby projektového řízení v organizacích ústřední státní správy vydané MV ČR(( [[https://www.zakazky.mvcr.cz/document_audit_26145/MV_CEPR_-_Metodicka_prirucka.pdf]] )), je zpracován v tabulce: „Scénář aktivit životního cyklu ICT služby VS ČR“ a je součástí [[:znalostni_baze|Znalostní báze]]**.** Scénář aktivit životního cyklu ICT služby VS ČR (také jako „scénář“), kromě výše uvedené hierarchie aktivit, obsahuje i jednotlivé procesní kroky, konkrétní dokumenty (jak je definuje Pokyn ministra vnitra(( Pokyn ministra vnitra č. 5/2017 ze dne 25. ledna 2017, kterým se zřizuje projektová kancelář a upravuje řízení projektů v oboru působnosti Ministerstva vnitra ))), standardně nezbytné (inicializační) vstupy a výstupy, a dále i vzájemné návazností (podmíněnost zahájení) a klíčové na aktivitě zúčastněné role. Popisy jednotlivých výše uvedených fází každé životní etapy IS jsou pro snazší srozumitelnost všechny shodně členěny na tyto části: - Rámcová charakteristika fáze. - Principy fáze – hlavní rysy a požadavky, principy, jejichž dodržování je pro správné řízení aktivit této fáze určující. - Doporučené metody – metody, jejichž využití je pro danou fázi doporučeno. - Legislativní zakotvení – výběr legislativních dokumentů, které je při výkonu aktivit této fáze každé etapy nutné respektovat. - Dotčené role – výběr rolí, které by se měly na výkonu aktivit této fáze životní etapy aktivně podílet. - Vstupy, a zdroje, výstupy: * nutné vstupy – iniciátory fáze – přehled úkonů a rozhodnutí (dokumentů), které jsou nutným předpokladem = iniciují zahájení výkonu aktivit této fáze, * zdroje potřebné pro efektivnost aktivit v dané fázi – zdroje (informace, technické prostředky, organizační opatření, personální zdroje atd.), bez nichž nelze výkon aktivit této fáze realizovat efektivně, * výstupy jednotlivých fází slouží jednak k dokumentaci, že konkrétní úkon (např. rozhodnutí nebo jmenování) proběhl a jednak jako vstup následujícího úkonu / kroku / fáze. - Dílčí fáze a kroky – stručný popis konkrétních aktivit zařazených do této fáze životní etapy IS, plus doporučené metody, jejich hlavní milníky (výstupy a nejen termíny, ale i výstupy) a účastníci (role). - Postup a způsoby řízení - posloupnost dílčích fází, kroků a výstupů dané fáze, pokud je předepsána. Spolu s tím pravidla pro společné nebo jinak vzájemně související řízení v rámci fáze, projektové a liniové. V tomto úvodním vydání MŘICT jsou pro přehlednost a srozumitelnost uvedeny u každé fáze pouze podkapitoly Rámcová charakteristika, Principy fáze a případně Dílčí fáze a kroky. Zbylé části popisu a všechny rozšiřující přílohy, obsahující výše uvedené Scénáře a další potřebné akcelerátory k jednotlivým fázím budou postupně doplňovány do odpovídajících částí [[:znalostni_baze|Znalostní báze]]. Různé části každé fáze jedné etapy životního cyklu IS mají také různé formy řízení - liniové a programové/projektové. Zatímco podstatná část plánování, přípravy a realizace radikální změny IS, případně ukončení jeho služby, se řídí jako program a projekt, s využitím projektových rolí, tak část strategických příprav, veškerý provoz, vyhodnocování a průběžné zlepšování se dějí v běžném liniovém řízení útvarů a rolí věcného a technického správce systému. Fázím 1, 2 a 3 životního cyklu, vedoucím ke službám s novou hodnotou, odpovídá obvykle jeden rozvojový program, tvořený jedním nebo více dílčími projekty, jejichž sladěnou realizací vzniknou programem očekávané přínosy. Každý projekt realizace podstatné změny IS, tj. vývojový a implementační projekt, bez ohledu na obsah nebo velikost, obsahuje v různém rozsahu zastoupené, ale vždy přítomné následující „projektové fáze“: * **Identifikace, iniciace a koncepce projektu** - je naplánována budoucí existence projektu (již např. v architektonické Roadmapě IK OVS) a projekt je nahrubo definován, koncipován. Jsou stanoveny jeho cíle a základní podmínky. To se odehrává ve fázi ŽC IS č. 1-Strategie. * **Plánování a příprava projektu**, po jeho schválení a zahájení, včetně ustavení projektových struktur a jeho materiálního a personálního zajištění ve fázi č. 2-Plánování a příprava. * **Realizace projektu**, typicky po výběru dodavatele, zahrnující ustavení společných projektových struktur s dodavatelem, cílový koncept řešení a dodávku (vývoj, implementace) řešení v míře odpovídající zvolenému způsobu realizace (vodopád, agilní, kombinace, …), včetně testování. * **Příprava produktivního provozu**, zahrnující přípravu včetně školení, migrací dat, okamžik zahájení užívání a počáteční rozšířenou podporu dodavatele, oba body ve fázi č. 3-Realizace. * **Uzavření projektu**, zahrnující závěrečnou akceptaci výstupů a předání řešení do trvalé podpory, na počátku fáze č. 4-Provoz. * **Průběžné plánování, monitoring a řízení projektu**, ve všech fázích projektu a v odpovídajících fázích 1, 2, 3 a 4 etapy životního cyklu. ^Fáze životního cyklu IS ^Fáze realizačního projektu ^Klíčové výstupy a milníky ^ |\\ STRATEGIE |* Identifikace, iniciace a koncepce |* Strategické zadání.\\ * Informační koncepce OVS, obsahující projekt.\\ * Enterprise architektura projektu.\\ * Stanovisko OHA | |\\ PLÁN A PŘÍPRAVA |* Plánování a příprava projektu |* Definice projektu((Z angl. Project Charter)), Projektový záměr.\\ * Architektura řešení projektu.\\ * Funkční a ne-funkční specifikace.\\ * Rozhodnutí o (ne)realizaci projektu\\ * Investiční záměr\\ * Registrace projektu na MF.\\ * Rozpočtové opatření úřadu vč. určení příkazce\\ * Zadávací dokumentace VZ.\\ * Výběr dodavatele / Smlouva s dodavatelem.| |\\ REALIZACE |* Realizace projektu\\ * Příprava produktivního provozu|* Blueprint(( Z původního významu „modrotiskového plánu, výkresu konstrukce zařízení“, více: [[https://cs.wikipedia.org/wiki/Diazotypie|https:%%//%%cs.wikipedia.org/wiki/Diazotypie]], nyní detailní prováděcí návrh řešení.))\\ * Vývojové zadání\\ * Testovací scénáře a protokoly\\ * … a mnoho dalších. | |\\ PRODUKČNÍ PROVOZ|* Uzavření projektu |* Akceptační protokol.\\ * Dokumentace skutečného provedení.\\ * Vyhodnocení projektu = Zpráva o průběhu projektu. | |Průběžně -\\ \\ přes 1, 2, 3 a 4 |* Plánování, monitoring a řízení projektu. |* Plán řízení projektu, včetně\\ * Plán zdrojů\\ * Registr rizik a dalších | Vztah fází životního cyklu IS a fází typického realizačního projektu. Další výstupy a milníky fází realizačního projektu jsou popsány v detailních materiálech [[:znalostni_baze|Znalostní báze]] k jednotlivým fázím etapy životního cyklu a k metodice řízení projektů. **Překrývání etap životního cyklu.** Etapy životního cyklu jednoho IS se mohou vzájemně překrývat s fázovým posunem. Tedy současně jsou některé služby IS rutinně provozovány, některé služby z dřívějších etap již jsou utlumovány a likvidovány a nové služby z další etapy rozvoje systému jsou plánovány nebo realizovány. **Překrývání fází jedné etapy**. Stejně tak fáze jedné etapy se ve svých činnostech mohou překrývat či předbíhat. Například ještě nejsou provedeny všechny činnosti uzavření realizačního projektu a finální předání řešení do produktivního provozu, přesto již jsou služby jako výstupy projektu produktivně užívány. Manažeři věcného i technického správce, provozovatele i dodavatele se musí v jednotlivých etapách a fázích orientovat a jejich souběhy a překryvy vědomě zvládat. ==== Fáze 1 - STRATEGIE ==== === Rámcová charakteristika strategie === Fáze strategie obsahuje aktivity uskutečňované při formulování strategií rozvoje veřejné správy, OVS (jeho rezortu) a jeho IT útvaru a v odpovídajících změnách právních předpisů, z nichž vyplynou požadavky na nové nebo změněné služby ICT podpory výkonu veřejné správy. Do strategické fáze byly – vzhledem k životnímu cyklu jedné ICT služby / jednotlivého systému VS, zařazeny i kroky strategického plánování prováděné společně za všechny ICT služby a systémy úřadu, konkrétně vytvoření a aktualizace Informační koncepce OVS, se současnou aktualizací jeho architektury úřadu (EA). Fáze strategie zahrnuje aktivity související s formulováním strategií rozvoje veřejné správy, strategií OVS a jejich IT útvarů a v odpovídajících změnách právních předpisů, z nichž vyplynou požadavky na nové nebo změněné služby ICT podpory výkonu veřejné správy. To platí zejména v případě ústředních správních úřadů, v jejichž odborné gesci jsou jednotlivé právní předpisy a u nichž je možné a potřebné se na tvorbě celostátních strategií a právních předpisů z pozice informatiků podílet. U ostatních úřadů, zejména pak u úřadů územních samospráv je třeba přizpůsobovat vlastní strategie v závislosti na změnách právních předpisů a požadavcích na fungování veřejné správy ze strany občanů. Součástí fáze strategie jsou tyto činnosti: * Podíl na tvorbě strategických dokumentů vlády, nebo spolupráce formou poskytnutí vstupů a zpětné vazby. * Podíl na tvorbě nebo změně právních předpisů, a/nebo studium existujících a připravovaných právních norem a předpisů, včetně norem a nařízení EU a analýza jejich vlivu na ICT prostředí OVS. * Podíl na tvorbě vlastních strategických dokumentů OVS, včetně vypracování ICT strategie OVS, pokud ji OVS vytváří, ev. rezortu, je-li taková strategie vytvářena. * Analýza potřeb zainteresovaných stran, tj. zejména vedení úřadu a potřeb odborných oddělení na základě komunikace s věcnými garanty jednotlivých odborných agend. * Identifikace s cíli a plány OVS a rezortu, s cíli a plány na národní úrovni (IKČR a další), s cíli a plány na úrovni EU a vytvořit vlastní cíle ICT. * Vypracování a aktualizace dlouhodobé architektonické vize a celkové architektury úřadu (EA) OVS. * Vypracování analýzy obsahující stav nyní (As-Is) v následujících obdobích nebo při změnách pak **vždy** vytvořit analýzu rozdílovou s vyhodnocením rozdílu formou samostatného, manažerského shrnutí (toto shrnutí je možné připojit jako přílohu dané rozdílové analýzy). * Zajištění ostatních potřebných vstupů pro navazující fázi přípravy a strategické a projektové plánování * Vypracování a aktualizace Informační koncepce OVS, respektive dalších na ni navazujících střednědobých a dlouhodobých plánů rozvoje ICT prostředí OVS. * Prioritizace identifikovaných záměrů a příprava střednědobých výhledů a dlouhodobých finančních plánů pro naplnění plánů rozvoje ICT, umožňujících přesné plánovaní a čerpání rozpočtu, nejlépe formou ročních akčních plánů pro implementaci cílů a adaptaci na ně. **Fáze 1 – Strategie** je sice nedílnou součástí každé životní etapy jednotlivého IS, ale plnou měrou se u ní uplatní a převažují metody a prostředky strategického řízení a plánování ICT na úrovni celého útvaru a úřadu, v kontextu eGovernmentu ČR a EU, viz [[metody_dokument:rizeni_na_urovni_utvaru_ict|Řízení na úrovni útvaru ICT]]. Pro usnadnění a podporu procesů fáze řízení strategie budou do [[:znalostni_baze|Znalostní báze]] NA VS ČR postupně doplněny zejména: - Zásady, postupy a příklady na podporu tvorby tzv. Digitálně přívětivé legislativy. - Referenční model, architektonické vzory, tabulkové šablony a detailní pokyny pro tvorbu a údržbu architektury úřadu a její vize. - Kontrolní seznamy potřebných vstupů pro tvorbu architektury a plánování projektů. - Vzorová šablona a další pomůcky pro tvorbu Informační koncepce OVS, zejména kontrolní seznamy pro ověřování shody s IK ČR. - Pomůcky a postupy pro prioritizaci záměrů před a po schválení rozpočtu. - Pomůcky a postupy na podporu přípravy a vyjednávání o rozpočtu. - Pomůcky, návody a zdroje pro definici cílů. - Předlohy podob akčních plánů. === Principy a pravidla utváření strategie === * **Zásady strategického plánování ISVS v kontextu architektury úřadu.** Pro každý ISVS úřadu musí být ve společné Informační koncepci úřadu (také jako "IK" nebo "IK OVS") stanoveno, jaký je žádoucí cílový stav ISVS na konci plánovacího horizontu IK a proč a jakými projekty, případně programy budou potřebné změny IS realizovány a v jakém časovém horizontu. * **Návaznost na celkovou (věcnou, byznys) strategii a IT strategii úřadu, vycházející ze strategie eGovernmentu.** Dlouhodobé řízení informačních systémů veřejné správy se musí opírat o strategické cíle úřadu v oblasti výkonu veřejné správy a jeho informační podpory, v kontextu strategických cílů nadřazených struktur úřadu. Není přípustné vytvářet v IK úřadu dlouhodobý plán ISVS bez doložitelného a srozumitelného odkazu na plány rozvoje a změn agend, které ISVS podporuje, a bez kontextu plánovaných změn úřadu a eGovernmentu jako celku. Není možné vytvořit nebo aktualizovat IK OVS bez předchozí aktualizace jejích strategických vstupů (agendové strategie, strategie úřadu a IT strategie) a naopak, po každé změně těchto vstupů se musí zkontrolovat platnost IK OVS a případně ji aktualizovat. * **Architektura ISVS.** Každý věcný správce ISVS a věcný správce centrálního prvku eGovernmentu je povinen pro tento systém udržovat model stávající, cílové a případně přechodné architektury na úrovni architektury úřadu (EA) a architektury řešení (SA), souladu s metodikou Národního architektonického rámce. Pro potřebu žádosti o stanovisko OHA k programu, investičnímu záměru a projektu je dostatečný model požadovaného stavu architektury ISVS na úrovni podrobnosti architektury úřadu (PSA)(( Z angl. Project Start Architecture, model systému pro budoucí projekt na úrovni Enterprise Architecture.)). Po získání kladného stanoviska OHA, je-li toto z hlediska objemu projektu relevantní, je zapotřebí rozpracovat architekturu ISVS, nebo její změny, pro účely výběru řešení a dodavatele řešení do formy tzv. architektury řešení(( angl. Solution Architecture.)). Z té se následně sestavuje seznam požadavků funkční a tzv. ne-funkční (myšleno ostatní než funkční) specifikace(( Z angl. Functional & Non-functional Specification.)) pro účely zadávací dokumentace výběrového řízení dle ZoZVZ. * **Kombinace všech požadavků.** Součástí strategického naplánování každého ISVS na počátku nové etapy jeho rozvoje musí být kombinace strategických požadavků na změny s mandatorními požadavky například na bezpečnost (GDPR), na elektronickou identifikaci a dokumenty (eIDAS) nebo cíle a standardy eGovernmentu (IKČR). U již existujících IS musí být tyto externí požadavky kombinovány s interními požadavky, plynoucími z vyhodnocení stávajícího stavu IS (fáze 5). * **Periody řízení.** Činnosti a výstupy ve fázi 1 – Strategie jsou řízeny v průběžném, periodickém a Ad-Hoc režimu: * **Průběžně** je aktualizována celková (enterprise) architektura OVS, vždy po dokončení implementace jakékoli změny, ale také po změně strategie a v rámci realizace změnového řízení. * **Periodicky**, nejméně jedenkrát za 2 roky, ale také vždy při změně strategických vstupů, je aktualizována Informační koncepce OVS. * **Periodicky - každoročně**, v období před zahájením přípravy rozpočtu, je aktualizován plán projektů z IK OVS (Roadmapa). * **Ad-hoc**, když nastanou a jsou identifikovány nové požadavky a zásadní podněty (volby, změna vedení, nová legislativa apod.). ==== Fáze 2 - PLÁN A PŘÍPRAVA ==== === Rámcová charakteristika plánování a přípravy === Fáze obsahující kroky a aktivity navazující na v předchozí fázi stanovené strategické směrování jednotlivého informačního systému, toto směrování rozpracovává do návrhu jednotlivých potřebných změn, jejich vzájemných souvislostí a časového plánu. Součástí fáze jsou i všechna nezbytná připomínkování, posouzení a schvalování zvoleného způsobu řešení, tj. záměru rozvoje ICT úřadu, jako podmínky zahájení souvisejících výdajů ze státního rozpočtu Projekty změn služeb veřejné správy se stále více opírají o podporu informatiky. Všechny projekty v úřadu navíc sdílí omezené množství pro projekty vhodných lidských zdrojů. Z těchto důvodů musí být všechny projekty v oblasti informatiky prokazatelně koordinovány se všemi běžícími i plánovanými projekty celého úřadu, ať již společně tvoří těsně provázané rozvojové programy nebo budou řízeny jenom volněji jako portfolia projektů. Důležitá je komunikace s útvarem účetnictví o účetní povaze pořizovaných aktiv a dalších plnění. Ne vše, co se odborníkovi na ICT může jeví jako dlouhodobý majetek jím z účetního pohledu skutečně je. Při opomenutí mohou nastat závažná rizika porušení rozpočtové kázně a dalších sankcí. Metody a postupy fáze 2 – Plánování a příprava představují naplnění Zásad a postupů pro pořizování a vytváření informačních systémů veřejné správy - část I, a podklad pro aktualizaci a doplnění těchto zásad dle [[https://www.e-sbirka.cz/sb/2023/360|Vyhlášky č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy)]], o požadavcích na strukturu a obsah informační koncepce a provozní dokumentace a o požadavcích na řízení bezpečnosti a kvality informačních systémů veřejné správy (vyhláška o dlouhodobém řízení informačních systémů veřejné správy) v okruhu otázek: jak nalézt správné řešení pro naplnění byznys potřeb poskytování veřejných služeb (a jejich změn). Popis fáze uvádí, kromě jiného, základní povinnosti, jak postupovat z pozice útvaru ICT při hledání nejvhodnějších ICT řešení pro optimální naplnění byznys potřeb úřadu při dodávce jeho veřejných služeb. Ve fázi Plánování a přípravy v čase jdou vedle sebe, doplňují se a prolínají 3 pracovní proudy, podrobněji viz Tabulka 3: * věcný, obsahové plánování – co má být předmětem cílového řešení (architektura) * plánování zdrojů, zejména lidských a finančních (projektové plánování) * zajištění legitimity změn – legislativní příprava ^Míra poznání / Proud^Legislativa záměru ^Architektura záměru ^Zdroje záměru ^ |Úvodní představa |Návrh záměru zákona |Enterprise Architektura záměru|Nárok na rozpočet a pracovníky| |Zpřesněná představa |Schválený zákon ve finálním znění |Architektura řešení záměru |Alokované zdroje | |Proveditelné zadání |Vydány vyhlášky a Interní akty řízení|Design řešení |Vydané zdroje na řešení | Přehled vztahů souběžných pracovních proudů fáze Plánování a přípravy. Věcné plánování, tedy architektonická příprava, se odehrává v krocích postupně se zvyšujícího detailu poznání, vyjádřeného v grafických modelech a seznamech požadovaných komponent a jejich vlastností; ve shodě s tím, jak tyto úrovně definuje NAR, viz následující Obrázek: {{ :metody-dokument:image6.png?600 |Vrstvy architektury podle míry detailu.}} Na základní modely cílové architektury úřadu, vytvořené v rámci předchozí fáze 1-Strategie pro celý úřad a využité pro vydání Informační koncepce OVS, navazuje tzv. „architektura před startem projektu“ (PSA(( Z angl. Project Start Architecture ))). Tato architektura poskytuje model budoucího řešení a jeho nejbližšího kontextu na úrovni detailu EA a obsahuje spolu se základním projektovým záměrem dostatek údajů pro sestavení Žádosti o stanovisko OHA. Následuje nalezení tzv. architektury řešení, která se zaměřuje na otázku, jak má hledané řešení fungovat a je vedle grafických diagramů vyjádřena tzv. funkční a ne-funkční specifikací. Nezbytnou součástí je rozhodnutí o variantě řešení. Společně s upřesněným projektovým záměrem, obsahujícím rozhodnutí o strategii implementace, o způsobu zajištění vlastních, odsouhlasení CBA a rozhodnutí o pokračování procesu směrem k pořízení řešení (nákupem, vývojem nebo kombinací), je architektura řešení a specifikace základem zadávací dokumentace veřejné zakázky. Předpokladem pro věcné plánování a přípravu je podíl ICT specialistů na tvorbě věcného záměru příslušného právního předpisu spojeného se změnou, a to zejména a plnou měrou, pokud se jedná o OVS, v jehož gesci je předmětná právní úprava a jež bude správcem příslušného IS. Úlohou ICT v této oblasti je zejména: * poskytnout legislativnímu týmu potřebnou schopnost systémového myšlení a širokého kontextu celého úřadu a eGovernmentu ČR a EU, * přispět k DPL - digitální přívětivosti zákona znalostmi zejména aktuálních technologických možností a uživatelských zvyklostí a očekávání, * poskytnout logickou kontrolu a včasné ověření reálné proveditelnosti dopadů zákona do realizace v ICT, * včas získávat informace pro další plánovací činnosti v ICT Proto je úloha ICT nejvýraznější již ve fázi prvních idejí a formulování věcného záměru změny předpisu, ale přetrvává až do definitivního schválení předpisu a jeho prováděcích předpisů. V projektovém plánování zdrojů je nezbytné včas a s dobrou znalostí připravované legislativy, potřebného rozsahu změn a prací a jejich termínování žádat a zajišťovat všechny druhy zdrojů k tomu existujícími úkony a dokumenty (programové financování, projektový záměr, …). Důležitou součástí přípravy zdrojů je získání externích zdrojů, tj. výběr dodavatele úspěšným procesem veřejné zakázky a uzavřením smlouvy, finálně v sobě spojující výstupy všech tří souběžných plánovacích a přípravných proudů. Úspěch a efektivita fáze Plánování a přípravy závisí velkou měrou na tom, jak se podaří načasovat práce ve všech třech proudech a jak se podaří vzájemně využívat poznání a výstupů z jednotlivých činností a vyhnout se duplicitním pracím a dokumentům. Důležitým předpokladem úspěchu celého životního cyklu je již ve fázi Plánování a příprav zahrnout do rozsahu a záměru, zadání a smluv také: * Zohlednění všech mandatorních potřeb a pravidel, nesvázaných s příslušným agendovým nebo provozním předpisem (eIDAS, bezpečnost, GDPR, e-Identita, principy eGovernmentu z IKČR apod.). * Vytvoření předpokladů pro následné efektivní řízení kvality a výkonnosti služeb (SLA). * Vytvoření předpokladů pro převzetí znalostí od dodavatelů a zmírnění závislosti na nich. * Vytvoření předpokladů pro vybudování a zajištění schopnosti úřadu provozovat (nebo ovládat provoz) řešení a další předpoklady. * Vytvoření předpokladů pro vyhodnocení měřitelných parametrů projektů, řešení i dodavatelů ve fázi 6. Optimalizace tohoto souběhu plánovacích proudů, zajištění uvedených předpokladů a usnadnění všech činností bude předmětem dokumentů a pomůcek, které budou součástí dalšího vydání MŘICT a [[:znalostni_baze|Znalostní báze]]. === Principy a pravidla plánování === * Plánování a příprava jednotlivého programu či projektu se musí dít v souladu a s využitím metod a nástrojů plánování programů, projektů a portfolií na úrovni celého úřadu a v kontextu celého eGovernmentu. * Souběh a soulad tří plánovacích a přípravných proudů (legislativní, architektonický a zdrojový). * Podíl informatiků na tvorbě právních předpisů záměru (pokud je to pro OVS relevantní). * spolupráce při zadání a identifikaci potřeb, * konzultace a potvrzení z hlediska věcné správnosti, * revize a schválení výsledného znění z hlediska věcné správnosti. * Postupné plánování cílového stavu se záměrem spojeného funkčního celku přes všechny 4 vrstvy architektury. * Včasné plánování a alokování všech potřebných zdrojů (finančních, lidských, technických i znalostních). * Zohlednění všech mandatorních požadavků. * Komunikace s útvarem účetnictví o účetní povaze pořizovaných aktiv a dalších plnění * Vytvoření předpokladů pro následující fáze. * Využití principu ex-ante kontroly a nástrojů PoC (Proof of Concept), viz další kapitoly. * V EA modelech pomocí dekompozice služeb vytvářet předpoklady, motivátory a rozhraní pro měření KPI a následné vyhodnocování SLA a OLA a řízení (SLM). * Při dekompozici vždy uplatňovat a plánovat, co bude outsourcováno a co insourcováno, a provést analýzu dopadů na rozpočet OVS (v případě požadavků na UC) a na interní zdroje a jejich kapacitu (v případě požadavků na interní OLA). * V případě využití sdílených služeb brát při sestavování úrovně služby (% dostupnosti) všechny SLA včetně sdílených a až dle těchto ukazatelů navrhovat SLA s garanty a navrhnout monitoring. * Do definice SLA vždy zařadit požadavky všech aktérů a klíčových uživatelů. * Vždy pečlivě plánovat kapacity pro realizaci a následný provoz nejlépe formou dopadové analýzy, a to na zdroje: * Finanční * Technické (včetně nástrojů pro podporu projektů (PPM) a provozu (ServiceDesk) * Lidské (včetně operátorů HelpDesku a zdrojů potřebných na součinnosti) * Vždy vypracovat matici rizik změn jako přílohu pro dokumentaci v rámci realizace, o rizicích musí být informováno minimálně vedení útvaru ICT, věcný garant a sponzor projektu. * Určit mandatorní smluvní požadavky zejména pak: * autorská práva, * sankce a slevy, * katalogové SLA listy, * definice součinností, * exitové strategie a povinností, atd. ==== Fáze 3 – REALIZACE ==== === Rámcová charakteristika realizace === Fáze realizace plánovaných změn informačního systému představuje jádro vývojového a implementačního projektu, naplánovaného, spuštěného a koncepčně rozpracovaného v předchozí fázi této etapy životního cyklu řešení. Realizace uskutečňuje vlastní dodávku standardního aplikačního SW vybavení, jeho parametrizaci a programové přizpůsobení a/nebo vývoj SW na míru a/nebo pořízení SW jako služby. Pro obě formy pořízení SW tzv. „On-premise“ představuje realizace také dodávku platforem a infrastruktury, vybudování všech potřebných běhových prostředí ((Angl. také „Landscape“.)), a to minimálně třístupňového (vývojové, testovací a produkční), optimálně u rozsáhlých systémů čtyřstupňového (vývojové, testovací, preprodukční a produkční) ve výjimečných odůvodněných případech je přípustné dvoustupňové (nekritické systémy bez kritických dat a integrací např. BI) a ustavení schopnosti úřadu provozovat a podporovat řešení. Metody a postupy fáze realizace nahrazují a rozvíjejí tzv. Zásady a postupy pro pořizování a vytváření informačních systémů veřejné správy – část II (implementace nakoupeného řešení a pořízení řešení vývojem, nebo kombinace obou). Půjde o podstatné doplnění zásad dle [[https://www.e-sbirka.cz/sb/2023/360|Vyhlášky č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy)]] v okruhu otázek: jak vybrané řešení úspěšně zavést a uvést do produktivního provozu. Tedy podstatné a celostátně plošně platné standardy k požadavkům vyhlášky (po její předpokládané novele). Řízení projektů realizace jednotlivých IS musí být prováděno v kontextu řízení změn na úrovni celého útvaru ICT a změn celého úřadu, viz zejména [[metody_dokument:rizeni_na_urovni_utvaru_ict|Řízení na úrovni útvaru ICT]]. To znamená zejména: * společné řízení dílčích projektů v rámci celkového řízení portfolií a programů * společné řízení IT a ne-IT změn * společné řízení velkých (např. projektových) a malých (např. liniových, průběžných) změn – sdílenými postupy, nástroji a zdroji. Pro usnadnění a podporu procesů fáze řízení realizace budou do [[:znalostni_baze|Znalostní báze]] postupně doplněny zejména: - Doporučené postupy a metodiky pro tvorbu a záznam analytických modelů na úrovni architektury řešení (SA) a designu řešení (SD) - Datové modely - Procesní modely - Dekompoziční modely - Use-Case a stavové modely - Doporučené normy a metodiky pro projektové řízení realizačních projektů (včetně případného vývoje) - Interní vývojové normy === Principy a pravidla realizace === * Změny od určité velikosti, rozsahu či charakteru musí být řízeny jako projekt. * Akceptaci řešení provádí vždy klient (zadavatel, věcný správce) ve spolupráci s dalšími zúčastněnými stranami (integrované OVS, SZR, …). * Struktura kroků, výstupů a metod projektu musí odpovídat zvolenému typu zaváděného řešení (hotový SW, vlastní vývoj, SW jako služba), implementační strategii (Big-Beng, Pilot-Roll/out) a vývojové strategii (Waterfall/Agile) a jejich případným kombinacím. * Projekty s vyššími nároky na přizpůsobení uživatelů musí obsahovat adaptační aktivity dle metodiky OCM, které bude doplněno do [[:znalostni_baze|Znalostní báze]]. * Činnosti fáze realizace jednoho IS musí být vždy vykonávány v souladu s metodami řízení realizace na úrovni celého útvaru/úřadu a s využitím společných metod a nástrojů. * V případě realizace velkého projektu dodavatelem s globální osvědčenou metodikou řízení projektů a vývoje je možné použít tuto metodiku, pokud bude v souladu ustanoveními tohoto dokumentu a jeho příloh a pokud se ji podaří provázat s povinnými (minimálními) kroky a výstupy řízení projektů VS ČR, až budou vydány. === Dílčí etapy / kroky realizace === Realizace projektově řízené změny IS ve fázi 3. jeho životního cyklu, typicky po výběru dodavatele, představuje uskutečnění následujících projektových fází realizačního projektu dle metodiky projektového řízení: * **Ustavení projektových struktur**, společných týmů s dodavatelem, vyčlenění prostor, sjednání projektového kalendáře, zprovoznění platformy sdílení znalostí a dokumentů, apod. * **Prováděcí projekt** (alias Blueprint, cílový koncept, analýza a návrh řešení, apod.), a to nejméně: * Byznys koncept - jak se bude řešení používat (funkce, procesy, služby, role, výstupy-produkty, apod.) * IT koncept - jak bude řešení zhotoveno, parametrizováno či vyvinuto, aby naplnilo byznys koncept, včetně * Koncept bezpečnosti a ochrany osobních údajů - jak budou zapracovány mandatorní požadavky * Koncept zajištění všech IT prostředí, včetně provozní infrastruktury * Koncept testování a ověřování * Koncept rolí a oprávnění * Koncept migrace dat a uvedení do produktivního provozu * Aktualizace architektury řešení (přes všechny vrstvy), případně změna EA, pokud na ni vede změnové řízení. * **Vývoj a implementace řešení**, tj. vytvoření vývojového a testovacího IT prostředí včetně OS, platforem a databází, instalace, parametrizace a přizpůsobení hotových řešení a vývoj SW řešení na míru, včetně všech forem ověřování požadované funkčnosti - testování, ověření konceptu (PoC(( Z angl. Proof of Concept.))) a dokumentace vývoje a nastavení. * **Příprava produktivního provozu**, zahrnující vytvoření produkčního IT prostředí, včetně zajištění služeb třetích stran, přípravu uživatelů včetně školení, migrací dat, okamžik zahájení užívání, ustavení vlastní schopnosti úřadu provozovat a podporovat řešení (včetně monitorovacích nástrojů dostupnosti a odezvy služeb) a počáteční rozšířenou podporu dodavatele. * **Uzavření projektu**, závěrečnou akceptaci výstupů a předání řešení do trvalé podpory, včetně kompletní vývojové, provozní a uživatelské dokumentace skutečného provedení řešení. * **Průběžné plánování, monitoring a řízení projektu** - probíhá ve všech fázích projektu. Jednotlivým projektovým fázím je podřazena celá řada dílčích činností, milníků a výstupů, viz podrobné dílčí kapitoly ve [[:znalostni_baze|Znalostní bázi]]. Důležitou projektovou činností na počátku realizace je ustavení projektových struktur a mobilizace jeho interních lidských a materiálních zdrojů. Od okamžiku produktivního spuštění prvních služeb, zařazených do rozsahu realizačního projektu, začíná tento naplňovat současně i obsah fáze životního cyklu č. 4 - Provoz a osoby a týmy, zodpovědné na straně zákazníka a případně outsourcovaného provozovatele, se musí aktivně na těchto projektových fázích podílet, počínaje přípravou produkčního prostředí a produktivního provozu. ==== Fáze 4 - PRODUKČNÍ PROVOZ ==== === Rámcová charakteristika provozu === Fáze produktivního provozu je charakteristická potřebou zajistit dodávku služeb, uvedených do provozu k předchozímu milníku, při zachování parametrů kvantity, kvality i bezpečnosti služby a pokud možno při rostoucí hospodárnosti a efektivitě dodávky služby, umožněné prohlubování zkušeností i průběžným zlepšováním provozu beze změny služby. Stručně řečeno jde o zajištění dohodnutých úrovní služeb (SLA ev. OLA). Druhou klíčovou charakteristikou fáze produktivního provozu je, že se během ní realizují převážně průběžným, liniovým řízení útvaru ICT a/nebo smluvního partnera drobné změny rozsahu nebo kvality služeb, které pro své uskutečnění nevyžadují aktivity fází 2 - příprava a plánování a 3 - realizace změny. Stručně řečeno jde o nepřetržitou identifikaci, kvalifikaci, plánování a realizaci drobných změn, tedy sběr požadavků a změnové řízení. Je důležité identifikované změny klasifikovat z hlediska jejich velikosti, způsobu řízení jejich realizace a hlediska jejich priorit. Základní prioritou technického správce a provozovatele je předcházení nedostupnosti služeb systému a splnění termínu realizace změn služeb (zejména legislativních). Ostatní změny s nízkou prioritou je účelné sdružovat do balíků práce k termínům nových verzí předmětného řešení. Do této skupiny patří i změny zaměřené na měřitelná zlepšení efektivnosti, tedy změny přinášející významnou úsporu zdrojů (finančních, technických nebo organizačních). Na posledním místě z hlediska provozu jsou změny, které nenaplňují ani jednu z výše uvedených kategorií, ale například zvyšují kvalitu služby a komfort pro uživatele. Výše uvedené musí odrážet vztah mezi řídící osobou, zodpovědnou za dodávku služeb informačního systému, a interním útvarem nebo externím dodavatelem. Tento smluvní vztah a obecně schopnost úřadu (technického správce) zajistit efektivní provoz je nutno zahrnout již do fází přípravy, plánování a realizace vzniku nového systému nebo jeho zásadní změny. Zodpovědná osoba musí být oprávněná a kompetentní k rozhodování o správě a provozu systému a o čerpání zdrojů, včetně garantovaných tzv. mandatorních zdrojů (rozpočtu provozních nákladů, povinných interních rolí, materiálně-technického zabezpečení). Provozem se myslí i zajištění chodu infrastruktury nezbytné pro dodávku aplikačních služeb. Pořízení a obměna infrastruktury se řídí podle pravidel fází 2 a 3, případně 1 životního cyklu řešení. Důležitou podmínkou a součástí řízení provozu je udržování aktuální produktové (vývojové), provozní a uživatelské dokumentace informačních systémů, tj. funkčních celků ve všech vrstvách jejich architektury. Majetek je v této fázi již ve stavu způsobilém k užívání a může být tedy účetně zařazen do majetku a má mu být stanoven odpisového plánu (doby odpisování). Při opomenutí odpisového plánu je zde riziko neprůkaznosti účetnictví. Pro podporu obou aspektů provozu (kontinuální dodávky služeb i identifikace a realizace změn) je klíčové poskytování uživatelské i technické podpory. Více o klíčových metodách používaných při řízení provozu na úrovni každého IS se nachází v [[metody_dokument:rizeni_jednotlivych_ict_reseni|Řízení jednotlivých ICT řešení]]. Vedle činností pro zajištění provozu služeb jednotlivých informačních systémů je nutné vybudovat a užívat schopnosti provozního řízení centralizovaně, napříč jednotlivými IS, ať již je to například: * celková správa datových center a virtualizované infrastruktury * celková správa klíčových aplikačních platforem * celková péče o uživatele * celkové řízení konfigurace řešení * celkové plánování a řízení změna a verzí * celkové plánování a řízení zdrojů pro provoz Více v kapitolách o metodách provozního řízení na úrovni ICT útvaru, [[metody_dokument:rizeni_na_urovni_utvaru_ict|Řízení na úrovni útvaru ICT]]. Pro usnadnění a podporu procesů fáze řízení provozu budou do [[:znalostni_baze|Znalostní báze]] postupně doplněny zejména následující akcelerátory: - Obecné návrhy na monitoring dostupnosti a odezev - Vzorové procesy HelpDesku - Odpovědnost klíčových rolí a jejich kompetence (jako součást celkové matice RACI) - Odkazy na dokumenty, které jsou pro tuto fázi nezbytné / doporučené - Popis strategie a realizace zálohování, včetně ověření, zda procesy obnovy jsou funkční. === Principy a pravidla provozu === * Zajistit chod nezměněné služby * Zajistit realizaci změn pro udržení kvality služby a pro její průběžný rozvoj * Zajistit realizaci změn pro zvýšení efektivity služby * Realizovat pouze „malé“ změny, nepředstavující projekty ve fázích 2 a 3 životních etap informačního systému * Vytvořit a řídit Katalog ICT služeb (aktuálně provozovaných)(( Jak dokládají publikované zkušenosti např. z USA a Velké Británie, je katalog jedním z klíčových nástrojů řízení ICT ve veřejné správě. Navazuje na katalog služeb veřejné správy a eviduje veškeré ICT služby (SaaS, DaaS, PaaS, IaaS), které jsou aktuálně provozovány jak pro interní potřebu úřadů, tak nabízeny jako e-služby občanům a firmám.)). * K údržbě a rozvoji ICT služeb (systémů) VS, za jejichž flexibilní legislativní rozvoj jako věcný správce OVS odpovídá, mít vlastní útvar, nebo ovládané středisko kompetence (útvar podpory služeb, kompetenční centrum). * Všechny poskytované služby jsou monitorovány min. na úrovní End2End (business strojové scénáře a skripty) monitoringu. * Provoz jednotlivého IS se vždy řídí v kontextu a vykonává prostředky řízení provozu celého úřadu. * Všechny potřeby vzniklé samotným provozem dílčího celku se musí sdružovat jednom místě a u jedné odpovědné osoby. * Všechny služby musí být obsluhovány jednotně pomocí jednotlivých ITSM managementů. * Musí probíhat řízení kvality služeb za pomocí SLM, pravidelné SLA negociace, a to jak na úrovni pracovních týmů, tak řídících výborů. * Stanovení odpisového plánu (doby odpisování) pro majetek. * Nutnost reakce na bezpečnostní incidenty spojené s osobními údaji. === Dílčí etapy / kroky provozu === Kroky řízení provozu lze seskupit do čtyř oblastí: * Zajištění provozního (běhového) prostředí (typicky projektově již jako součást fáze realizace) a převzetí zodpovědnosti za dodávku služeb pořízených řešení. * Zajištění zachování požadované úrovně služeb * Úkony provozní bezpečnosti – dle Disaster Recovery plánu * Monitoring dosahované úrovně služeb včetně bezpečnostního monitoringu * Zajištění správy identit a přístupu privilegovaných uživatelů v oblasti bezpečnosti a provozu. * Prevence a profylaxe * Údržba HW a SW * Podpora uživatelů * HelpDesk / ServiceDesk s procesy obsluhy a správy incidentů, správy problémů a iniciace procesů správy změn * Průběžný rozvoj řešení – řízení realizace změn s kroky: * identifikace a klasifikace incidentů a požadavků na změnu * posouzení a prioritizace změnových požadavků * plánování změn a řízení verzí * realizace a dokumentace změn * Informování o změnách a rozdílová školení. ==== Fáze 5 - VYHODNOCENÍ provozu a služeb IS ==== === Rámcová charakteristika vyhodnocení === Součástí fáze Vyhodnocení provozu a služeb je několik podstatných typů vyhodnocení, zejména vyhodnocení: * zda realizační projekt dosáhl plánovaných hodnot (rozsahu, času, potřeby zdrojů) a očekávané kvality výstupů, * zda se daří dodávat ICT služby v očekávané úrovni (SLA) - interním nebo externím provozovatelem, * jaké problémy a požadavky na změny lze dovodit z nahlášených incidentů (neshod), * zda se s podporou těchto ICT služeb daří dosáhnout očekávaných byznys benefitů, tj. zda se naplnily parametry a přínosy ICT investice, * zda kombinace přetrvávající byznys potřeby ICT služeb a jejich udržitelné kvality dává i nadále důvod pro zachování nebo rozvoj řešení, resp. naopak pro ukončení poskytování služeb tohoto systému, * jaká rizika a opatření pro jejich zmírnění se pojí s projektem změny nebo s provozem ICT služeb systému. * zda dodavatelé naplňují smluvní očekávání kvalitní a vyvážené spolupráce nebo je třeba je z další spolupráce vyřadit. Důležitým významem vyhodnocení realizačního projektu je, pokud jeho závěry mohou být použity nejen pro lepší nastavení vnitřních pravidel řízení, ale také pro závěry směrem k dodavatelům. V tuto chvíli již je již taková konstrukce možná. Zákon o kybernetické bezpečnosti se v politice řízení dodavatelů zcela jasně vymezuje vzhledem ke kvalitě dodávaného řešení. Zákon o zadávání veřejných zakázek se zcela jasně vymezuje vzhledem k porušení bezpečnosti. Souladem těchto zcela již dnes identických podmínek jsme schopni definovat kvalitu uchazeče /dodavatele a v případě špatných zkušeností vyřadit uchazeče z výběrového řízení, pokud jsou neshody za definovanou hranicí. Pro vyhodnocení bude vytvořena samostatná část (sada údajů) v katalogu ICT, která se bude orientovat na kvalitu dodaného řešení. Především se bude hodnotit kvalita odevzdaného výsledku oproti zadání, ale také se bude hodnotit kvalita spokojenosti klienta s odevzdaným výsledkem. Jedná se zároveň o kvalitu dodavatele i útvaru ICT. === Principy a pravidla vyhodnocení === * Povinnou součástí všech předchozích fází etapy životního cyklu (a fází projektů) musí být vytváření a naplňování předpokladů (například měřitelných cílů) pro vyhodnocování projektů, provozu i dodavatelů. * Povinnou součástí změnových projektů i provozu musí být vyhodnocování splnění dosažených cílů a parametrů, nebo zmírnění identifikovaných rizik a jejich interpretace do požadavků a potřeb vůči malým změnám nebo velkým změnám a s nimi spojené nové etapě životního cyklu. * Vedle konkrétních (věcných, agendových) cílů a požadavků musí být předmětem vyhodnocení i naplňování mandatorních požadavků (jako je bezpečnost, ochrana osobních údajů, apod.). * Součástí vyhodnocování rizik a dopadů je i posuzování potřeby tzv. mandatorních (nepodkročitelných) zdrojů, nezbytných pro zachování stávajícího rozsahu a úrovně služeb informačního systému. === Dílčí etapy / kroky vyhodnocení === **Vyhodnocení projektu - (ne)dosažení cílů projektu** * Věcný gestor agendy spolu s Technickým správcem a Manažerem kybernetické bezpečnosti vyhodnotí míru naplnění: * dílčích cílů projektu * SLA klíčových parametrů ICT služby / systému, **Vyhodnocení investiční akce** * Věcný gestor agendy spolu s Technickým správcem vyhodnotí: * dosažení cílů a plánovaných přínosů * splnění harmonogramu * dodržení rozpočtu, **Analýza provozních dat / plnění znalostní databáze (Best Practice)** * Provozovatel na základě reportů dohledového centra (HelpDesk): * zpracuje a vedení OVS předloží výroční zprávu, * průběžně doplňuje / aktualizuje ICT znalostní databázi úřadu **Formulace doporučení od změn nastavení po další rozvoj / ukončení provozu** * Věcný gestor agendy spolu s Technickým správcem a Manažerem kybernetické bezpečnosti (průběžně) posuzují: * návrhy a doporučení změn (funkcionalit i SLA parametrů) zaslaná Uživateli i Provozovatelem (Dodavatelem) * možnosti optimalizace a * perspektivnost dalšího rozvoje, * Technický správce naformuluje a Věcnému správci předloží: * návrhy optimalizačních operativních opatření a rozvoje služby, * připomínky a požadavky změn **Rozhodnutí o ukončení poskytování služby / provozu systému** * Na základě výroční zprávy **Věcný gestor agendy** rozhodne, zda poskytování ICT služby / provoz informačního či komunikačního systému ukončit nebo ne. ==== Fáze 6 - UKONČENÍ ICT SLUŽBY ==== === Rámcová charakteristika ukončení služby === Ukončení života systému a jeho případná náhrada jiným je strategickým rozhodnutím, které musí být podpořeno architektonickými a ekonomickými podklady a musí být dlouhodobě připravováno v IK OVS. Součástí ukončení služby je plnění exit plánu dohodnutého s dodavatelem či provozovatelem. S ukončením provozu je tedy nutno počítat již při formulaci zadání na výběr dodavatele, uzavření smlouvy(( Smlouva by se měla vyvarovat nevýhodných ustanovení (Vendor-Lock-In), viz: . [[https://www.mvcr.cz/soubor/hlavni-architekt-egovernmentu-dokumenty-typicka-nevyhodna-ujednani-ve-smlouvach-na-dodavku-ict-produktu-metodika-anti-vendorlock-in.aspx|https://archi.gov.cz/znalostni_baze:vendorlock]]. )) a při průběhu implementace(( Také se používá pojem „exit plán“ nebo „exit strategie“. )). Pro potřebu ukončení provozu ISVS a přechodu na jiný ISVS musí mít úřad zasmluvněnu povinnost stávajícího dodavatele ISVS poskytnout veškerou potřebnou součinnost, práva, data, dokumentaci a informace, účastnit se jednání s úřadem a popřípadě s třetími stranami za účelem plynulého a řádného převedení všech činností spojených s poskytováním služeb na úřad a/nebo nového poskytovatele, exporty veškerých dat s vyčerpávajícími popisy, včetně vytvoření základních datových zdrojů jednotlivých agend a modulů, které umožní na základě požadavků úřadu vytvořit dostatečně strukturovaná data, které bude moci importovat jiný ISVS bez hluboké znalosti databázové struktury stávajícího ISVS. Na základě datových zdrojů bude možné naplnit exitový plán pro přechod na jiný systém. Stejně tak musí být ukončení zohledňováno v architektuře, tzn., architekturu řešení je třeba navrhovat již s vědomím nutnosti podpory efektivního ukončení životního cyklu ISVS. Je žádoucí, aby věcně zodpovědné osoby za koncová informační a komunikační zařízení zvážily v souladu s principy 3E a dalšími právními předpisy v závěru životního cyklu ICT zařízení jejich vyřazení z účetní evidence bez provedení fyzické likvidace pro následné efektivní využívání koncových zařízení v rámci úřadu, až do doby úplného opotřebování. === Principy ukončení služby === * Na fakt, že služba bude ukončována, je třeba myslet již v prvních fázích návrhu služby a to: * Technicky. * Smluvně. * Provozně. * Datově/migračně. * Ukončení služby může mít důvody: * Finanční náročnosti údržby a rozvoje služby (nástroje TCO). * Morální zastaralost a nedostatečnost. * Smluvní. * Agenda již není vykonávána, nebo byla novelizována natolik, že změna znamená porušení 3E principu === Dílčí etapy / kroky === **Plán náhrady ukončovaného řešení novým (novou generací, jiným systémem)** **Ověření využitelnosti komponent:** * Technický správce zpracuje a Věcnému správci agendy předloží ke schválení: * analýzu využitelnosti komponent ve vlastnictví OVS (včetně SW licencí) s návrhem na majetková opatření (převod na jinou ICT službu / útvar, resp. odprodej / likvidace nevyužitelných), * analýzu možných rizik a dopadů, * kvalifikovaný odhad nákladů na likvidaci, * reálný harmonogram likvidace, * Věcný gestor agendy: * posoudí návrh Technického správce, který buď schválí, nebo vrátí s požadavkem konkrétních požadavků jeho změn, * určí, která data (včetně provozní dokumentace) a jak archivovat, a která a jak zlikvidovat. **Administrativní opatření:** * Technický správce zpracuje a Provozovateli předá k realizaci: * projekt ukončení poskytování ICT služby / provozu ICT systému, **Technická opatření:** * Provozovatel ve spolupráci s Dodavatelem: * odinstaluje zařízení a určená odveze je k likvidaci, * migruje / archivuje / likviduje data, * zpracuje kompletní dokumentaci likvidace ===== Zásady strategického plánování ISVS v kontextu architektury úřadu ===== ==== Přístup ex-ante k plánování a řízení změn a jejich přínosů ==== Způsoby promítání realizace strategických cílů do změn struktury a chování úřadu, tj. do změn jeho architektury, a naplánování vzájemně souvisejících proveditelných balíčků práce (programů, projektů) pro realizaci těchto změn a jejich IT podpory jsou úlohou manažerské metody EA-architektura úřadu, která je základním prostředkem tvorby Informační koncepce orgánu veřejné správy. Řešení v ICT mají mít dlouhodobý charakter, a to lze pouze při plánování. Plánování znamená znalost závazků vzniklých potřeb před jejich zavedením, tedy tzv. **ex-ante kontrola** vynaložených zdrojů na změnu prostředí. Je velice neefektivní realizovat zadání povrchně a nekoncepčně (např. vylepšovat nasazení po akceptaci a nasazení na produkci). Tento přístup je dlouhodobě neudržitelný, a především velmi nákladný a obtížně spravovatelný. V případě přístupu ex-ante, kdy programově hodnotíme dopady změny na začátku při návrhu, můžete zavedení změny podle jednotlivých dopadů pozitivně ovlivnit, primárně v oblasti nákladů (investičních i provozních, kvality a architektury). Nejefektivnějším možným a zároveň nejprůkaznějším nástrojem potvrzení či ověření vhodnosti vybraného způsobu řešení v rámci ex-ante kontroly je realizace ověřovacího projektu (PoC – Proof of Concept) na podmnožině funkcionalit a případů užití dostatečně reprezentujících koncept řešení předmětné problematiky. Za účelem minimalizace nákladů na realizaci PoC je vhodné využít dostupné otevřené (Open source) technologie. Tyto pak lze v případě potřeby v rámci produkčního implementačního projektu zaměnit za technologie komerční s garantovanou komerční podporou. Nemalým přínosem takového postupu je dále ověření a upřesnění požadavků na jednotlivé produkty na otevřených technologiích a následné přesnější cílení na produkční funkcionality vyžadované od komerčních produktů. Dalším důvodem pro realizaci PoC projektů je komunikace připravovaných služeb, funkcionalit a jejich podoby a formy směrem ke koncovým uživatelům. Jedním z hlavních architektonických principů na úrovni eGovernmentu ČR je princip „Použitelnosti“ budovaných aplikací. Dle tohoto principu musí být služby veřejné správy navrhovány vždy s ohledem na potřeby klienta – občana tak, aby mohl za všech okolností vyřídit svoji životní situaci v úplnosti elektronickou službou. Zároveň by měli být klienti – občané dle principu „Transparentnosti“ pořízení, provozu a rozvoje služeb veřejné správy informováni o záměrech a cílech budování on-line veřejných služeb tak, aby byli schopni využít všech dostupných prostředků k ovlivnění jejich směřování na základě jejich zákonných práv a demokratických principů. Pro naplnění výše uvedených principů se jako vhodný postup implementace nových služeb veřejné správy jeví právě ověření konceptů, technologií a jejich funkcionalit v takzvaném ověřovacím PoC projektu (Proof of Concept) před samotným návrhem a výstavbou cílových řešení. Tento postup poskytne uživatelům možnost otestovat služby a funkcionality již v době jejich návrhu, a tedy i možnost vyjadřovat se k podobě návrhu, případně zasílat náměty na změnu, rozšíření, či optimalizace navrhovaných služeb. Tak lze zajistit, že služby budou navrženy s ohledem na očekávání klientů – občanů a všechny případné nesrovnalosti, rozpory či dodatečné požadavky/očekávání klientů – občanů podchytit již v začátku a zapracovat do koncepce řešení nově připravované služby. U informačních systémů je ex-ante kontrola spojená nejčastěji s vypršením smlouvy na dobu určitou, kde další veřejná soutěž sebou nese např. změnové požadavky, které nebylo možné ze smlouvy plnit. V takovém okamžiku je zcela nezbytné zahrnout do ex-ante kontroly komplexní revizi výhradních a nevýhradních licencí daného řešení ve vztahu k vendor-lock efektům, možnosti využití [[nap:egovernment_cloud|cloudu]] a další možnosti sdílení. Ex-ante přístup se tedy může v nejbližším období stát jednoduchým nástrojem pro zmírnění rizik pro všechny ISVS. Pro každý jednotlivý a souhrnně pro všechny ISVS úřadu pak bude v Informační koncepci OVS stanoveno, jaký je žádoucí cílový stav ISVS na konci plánovacího horizontu IS včetně důvodu proč tomu tak je. Tedy z jakých důvodů vyplývajících z vlastních vlastností ISVS, z požadavků jím podporovaných procesů a služeb veřejné správy úřadu ev. z jakých externích příčin, dále jakými činnostmi budou potřebné změny IS realizovány a do kdy. ==== Návaznost na byznys a IT strategii úřadu, korporace a eGovernmentu ==== Dlouhodobé řízení informačních systémů veřejné správy musí být opřeno o strategické cíle úřadu v oblasti výkonu veřejné správy a jeho informační podpory, v kontextu strategických cílů nadřazených struktur úřadu, tj. veřejnoprávní korporace svého zřizovatele (má-li takovou a takového), eGovernmentu ČR a EU. Není přípustné vytvářet v IK úřadu dlouhodobý plán ISVS bez doložitelného a srozumitelného odkazu na plány rozvoje a změn agend, které ISVS podporuje, a bez kontextu plánovaných změn úřadu a eGovernmentu jako celku. Bez zvláštního zdůvodnění (flexibilní reakce na neočekávané změny vnějšího nebo vnitřního prostředí) není přípustné plánovat, připravovat a realizovat záměry, které nebyly předem identifikovány v IK OVS. Řádným způsobem vyřešení nenadálé potřeby zásadní změny IS je provést nejprve aktualizaci IK OVS, a tak zachytit do plánování veškerý potřebný kontext úřadu a eGovernmentu, teprve poté zahájit plánování a přípravu projektového záměru. ==== Enterprise architektura ISVS a jeho architektura řešení ==== Každý věcný správce ISVS a věcný správce centrálního prvku eGovernmentu povinen pro tento systém udržovat model stávající, cílové a případně přechodné architektury na úrovni podrobnosti architektury úřadu (EA) a model architektury jeho řešení v souladu s metodikou Národního architektonického rámce. Modely cílové architektury ISVS, na všech jejich vrstvách a doménách, vycházejí z celkové architektury úřadu, kterou všechny společně tvoří. Model určitého požadovaného stavu architektury ISVS na úrovni podrobnosti architektury úřadu se označuje mezinárodní zkratkou PSA(( Z angl. Project Start Architecture, (raději než české PAS - projektová architektura systému nebo SAP - systémová architektura projektu) )) a odpovídá souboru změn, které mají být na ISVS realizovány rozvojovým programem nebo projektem. Tato úroveň modelu je odpovídající pro potřeby IK úřadu a pro potřebu žádosti o stanovisko OHA k programu, investičnímu záměru a projektu. Po získání kladného stanoviska OHA, je-li toto z hlediska objemu projektu relevantní, je vhodné přikročit k rozpracování podrobnější architektury ISVS, nebo jeho změn, pro účely výběru řešení a dodavatele řešení, tzv. architektury řešení(( Z angl. Solution Architecture. )). Z té se následně sestavuje seznam požadavků funkční a tzv. ne-funkční (myšleno ostatní než funkční) specifikace(( Z angl. Functional & Non-functional Specification. )) pro účely zadávací dokumentace výběrového řízení dle ZVZ. Jak je uvedeno na jiném místě tohoto dokumentu, architektura řešení a její modely musí být nedílnou součástí návrhu provozních parametrů a její vizuální model dopomáhá k dekompozici (stávající i nové systémy) a přesnému návrhu rozhraní pro měření a řízení kvality služeb (SLA/SLM). ==== ISVS v Informační koncepci orgánu veřejné správy ==== Pro každý a pro všechny ISVS úřadu musí být ve společné Informační koncepci úřadu stanoveno, jaký je žádoucí cílový stav ISVS na konci plánovacího horizontu IK a proč, tedy z jakých důvodů vyplývajících z vlastních vlastností ISVS, z požadavků jím podporovaných procesů a služeb veřejné správy úřadu a z externích příčin, dále jakými proveditelnými balíčky práce (programy a projekty) budou potřebné změny IS realizovány a do kdy. V IK OVS se kombinují dva „kolmé“ pohledy na ISVS: * Jednotlivý pohled na logický ISVS (funkční celek) ve všech čtyřech vrstvách a čtyřech vertikálních doménách jeho architektury * Celkový pohled na každou horizontální a vertikální architektonickou doménu tak, že zřetelně ukazuje kontext každého jednotlivého ISVS. ==== Řízení služeb informačního systému ==== Základním pravidlem a doporučením MŘICT pro ICT útvary OVS je přejít na řízení vztahu poskytovatelů a odběratelů funkcí podpory informačních systémů pomocí služeb, pokud se tak u nich již nestalo dříve Příští vydání dokumentu MŘICT a průběžné přírůstky [[:znalostni_baze|Znalostní báze]] rozvinou informace, doporučení a pomůcky v této oblasti řízení ICT, například o: * správě Servisního katalogu resortní a jednotlivé organizace, eventuálně Servisního katalog na úrovni eGovernment * převodu funkcí jednoho IS do podoby služeb a jak tyto služby plánovat, řídit a měřit na úrovni jednoho IS a jak je zapojit do centrálního řízení služeb. ==== Pravidla plánování rozvoje ISVS ==== V této kapitole budou vydána praktická doporučení, jak při řízení rozvoje jednoho IS účelně zkombinovat vstupy ze strategického plánování, mandatorních požadavků a výstupů ze správy byznys a uživatelských požadavků. Doplněny budou také odkazy na odpovídající kapitoly mezinárodních standardů, například ITIL. Nedílnou součástí budou doporučení a praktické návody pomůcky pro plánování požadavků na pro rozvoj IS nezbytné dodatečné zdroje, tedy finanční a personální plánování na úrovni jednoho IS v kontextu útvaru a úřadu. Podstatné je, že řízení rozvoje jednoho IS musí vždy a plně využívat metody a nástroje řízení rozvoje IT aktiv celého úřadu, tj. portfolií aktiv po jednotlivých vrstvách, například plány rozvoje klíčových platforem, více v [[metody_dokument:rizeni_na_urovni_utvaru_ict|Řízení na úrovni útvaru ICT]]. ==== Pravidla ukončení provozu ISVS a přechodu na jiný ==== Ukončení života systému a jeho případná náhrada jiným je dalším strategickým rozhodnutím, které musí být podpořeno architektonickými a ekonomickými podklady a musí být dlouhodobě připravováno v IK OVS. S ukončením provozu je nutno počítat již od jeho spuštění, architekturu PSA a architekturu řešení je třeba navrhovat s vědomím nutnosti podpory efektivního ukončení životního cyklu ISVS. Ukončení provozu se věnují i další kapitoly tohoto dokumentu. Další věcná a odborná doplnění budou obsažena v následujících vydáních po projednání s odbornou veřejností.  ===== Zásady pro výběr a pořízení informačních systémů veřejné správy ===== Tato kapitola je první částí rozpracování požadavků: „Zásady a postupy pro pořizování a vytváření informačních systémů veřejné správy“ dle [[https://www.e-sbirka.cz/sb/2023/360|Vyhlášky č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy)]] v okruhu otázek: jak nalézt správné řešení pro naplnění byznys potřeb poskytování veřejných služeb (a jejich změn). ==== Pravidla pro financování pořízení IT řešení ==== === Pravidla jednoty programového řízení rozvoje informatizace === MŘICT stanovuje, že využití tzv. programů pro potřeby programového financování a současně pro řízení zavedení změn musí být sladěné, tj. jedná se v obou pohledech stále o jedny a tytéž programy změn. Je možné žádat o programové financování rozvoje informatiky úřadu pouze ve shodě s tím, jak byly programy změn pro jednotlivé ISVS identifikovány v cestovní mapě (Roadmap) architektury úřadu a v jeho informační koncepci. Z toho plyne, že není správné a možné používat prostředky a nástroje programového financování pro potřeby provozu a údržby ICT řešení, přestože přitom půjde o investiční prostředky a zhodnocení majetku, pokud se nejedná o změny realizované jako projekty v rámci rozvojových programů, viz dále. Naopak to možné je, tj. i v případě, že některá provozní úloha (provozně financovaná) přesahuje možnosti liniového útvaru, využije pro koordinaci interních a externích zdrojů metody projektového řízení a pro koordinaci změn nástroje programového řízení. Tj. i tyto úlohy mohou být přiřazeny do rozvojových programů a věcně společně řízeny. Bude stanoveno jaké je nejlepší praxe programového financování vzhledem k jednomu ISVS tak, aby současně vázala financování na očekávané benefity, ale současně ponechávala dostatečnou manažerskou flexibilitu, zejména u malých ISVS. === Pravidla pro ekonomiku a financování změn IT řešení === Ministerstvo vnitra s případnou revizí Ministerstva financí stanoví závazná pravidla průběžného udržitelného a řiditelného financování provozu ICT ve střednědobém horizontu, založeném na povinném vyhodnocování pětiletých Celkových nákladů na vlastnictví (angl. Total Cost of Ownership). To mimo jiné předpokládá přinejmenším v oblasti řízení ekonomiky informatizace zavedení druhého okruhu účetnictví a evidenci spotřeby zdrojů úřadu (lidí, majetku, energií, znalostí, …) v peněžním vyjádření jako tzv. náklady podle jednotlivých nositelů nákladů. Tj. zejména dynamických nositelů nákladů, kterými jsou programy, projekty a zakázky a statických nositelů nákladů, kterými jsou střediska útvaru ICT, jednotlivé součásti ICT řešení, fáze životního cyklu tohoto řešení a jednotlivé poskytované služby. Dále to předpokládá aktualizaci skladby rozpočtové struktury a rozpočtových pravidel. Tím se přejde od řízení finančních výdajů k řízení efektivity ICT prostřednictvím porovnávání a řízení spotřeby zdrojů, viz také {{:dokumenty:benchmark_jp_mt_final_s_dostaznikem.pdf|ICT Benchmarking}}. === Pravidla pro řízení financování sdílených ICT služeb === Aktuálně jediným zákonným postupem pro financování zřízení, provozování a poskytování sdílené ICT služby je právním předpisem pověřit konkrétní OVS takovým úkolem při současném přidělení odpovídající rozpočtové položky. Výsledná sdílená služba je následně poskytována ostatním, v předpisu uvedeným OVS (nebo i OVM) zdarma, jako například služby ISDS, ISZR apod. Návrhy, aby sdílené ICT služby byly hrazeny z kapitoly Všeobecná pokladní správa nebyly zatím akceptovány, namísto toho došlo k dohodě, že v závazných ukazatelích jednotlivých kapitol státního rozpočtu budou stanoveny specifické výdajové ukazatele, které budou zahrnovat výdaje spojené se správou, provozem a rozvojem klíčových informačních systémů veřejné správy, tj. [[nap:zakladni_registry|základních registrů]], [[nap:iszr|informačního systému základních registrů]], [[nap:egsb|informačního systému sdílené služby]], [[nap:komunikacni_infrastruktura_verejne_spravy|centrálního místa služeb]], [[nap:portaly_verejne_spravy_a_soukromopravnich_uzivatelu_udaju|portálu veřejné správy]], [[nap:czechpoint|informačního systému, jehož prostřednictvím je zajišťován výkon působnosti kontaktních míst veřejné správy]], a [[nap:nia|národního bodu pro identifikaci a autentizaci]]. ==== Pravidla rozhodování o způsobu realizace řešení ICT ==== Každý nový IS úřadu a jeho služby je možné pořídit několika způsoby. A to z pohledu způsobu technické realizace aplikačního SW vybavení, tedy jako: * ASW pořízené vývojem na míru * Typové ASW (TASW(( Angl. zkratka je COTS (Commercial off-the-shelf).))) * jako aplikační službu (SaaS(( Z angl. Software-as-a-Service))) * nebo kombinací všech tří přístupů Řešení může být také realizováno v různé granularitě aplikačních komponent zahrnutých do logického ISVS**, a to jako:** * **velké monolitické řešení,** * **procesně orientované komponentové řešení (jednotky komponent)** * **orchestrace mikroslužeb (App-Store)** * **kombinací všech třech způsobů v různých částech řešení.** Každá dílčí část z celkového **řešení informačního** systému **může být pořízena v různém modelu zajištění zodpovědnosti za jeho dodávku, provoz a správu, a to:** * **vlastními kmenovými zaměstnanci** * insourcingem **(doplněním chybějících kapacit od externího dodavatele při zachování interní zodpovědnosti za službu**, * outsourcingem **nebo tzv. [[nap:egovernment_cloud|cloudem]] (smluvním přenesením zodpovědnosti za službu dodavateli)** * nebo hybridním řešením**.** Pokud není způsob pořízení a realizace ((Z angl. deployment - nasazení, rozvinutí)) ICT služeb předepsán OVS zákonem nebo jiným právním předpisem, musí tento o způsobu pořízení (například nákupem řešení do vlastní správy, vývojem řešení vlastními silami nebo pořízením jako sdílené služby) rozhodovat se zodpovědností dobrého hospodáře, tzn. na základě komplexního posouzení reálně možných variant s přihlédnutím k hlediskům ekonomickým – zejména k již vlastněným existujícím podpůrným aktivům včetně etapy jejich životnosti, tak i k celkovým nákladům na vlastnictví ((Viz metodika TCO: [[https://archi.gov.cz/znalostni_baze:metodika_tco#metodika_vypoctu_tco_ict_sluzeb_verejne_spravy|Metodika TCO ICT služeb VS]])) a dalším, pro danou ICT službu relevantním požadavkům, např. bezpečnostním, termínovým atd. Při tomto rozhodování musí správce ISVS a vedení úřadu vzít v úvahu nejenom dosavadní možnosti realizace, ale i možnosti veřejnou správou připravované. Těmi jsou zejména strategicky podporované formy sdílených služeb a služeb [[nap:egovernment_cloud|eGovernment cloudu]]. [[nap:egovernment_cloud|G-cloud]] jsou sdílené ICT služby nabízené a provozované pro subjekty veřejné správy buď modelem //vládního cloudu// nebo modelem //komerčního cloudu//. Vládní cloud tvoří sdílené služby provozované státními datovými centry na jejich infrastruktuře. Komerční cloud jsou sdílené služby provozované komerčními subjekty na komerční infrastruktuře. Oba modely mají své katalogy nabízených služeb a související e-shop. Katalog sdílitelných certifikovaných služeb publikuje formou veřejného portálu ty nabízené ICT služby, které mohou organizace veřejné správy využívat jako sdílitelnou službu, a publikuje také finanční a další podmínky jejich využití. Jedná se o obdobu amerického (**[[http://cloud.cio.gov]]**) nebo britského ([[http://govstore.service.gov.uk/cloudstore|http://govstore.service.gov.uk/cloudstore]]) katalogu. === Kritéria využití služeb eGovernment cloudu === Rozhodnutí, zda využít [[nap:egovernment_cloud|cloud]] či nikoli, přichází buď ve chvíli návrhu nového ISVS, nebo jeho obměně, upgrade apod. Znamená to, že technický správce musí znát a do plánu rozvoje každého ISVS vždy zvážit využití sdílených [[nap:egovernment_cloud|služeb eGC]] – infrastrukturních, platformových, softwarových i procesních, tak jak budou věcně i legálně dostupné a pro správce ISVS povinné nebo ekonomicky výhodné. V podmínkách daného OVS a jeho rezortu je v rámci přípravy ISVS pro eventuální využití [[nap:egovernment_cloud|služeb eGC]] nutné provést zejména následující procesní kroky: * Věcní správci ISVS s pomocí [[nap:egovernment_cloud|metodik eGC]] zhodnotí pro svůj ISVS závažnost bezpečnostních dopadů, a pro celý ISVS nebo pro jeho jednotlivé funkční části stanoví úroveň bezpečnostních dopadů 1-4 (Nízká, Střední, Vysoká, Kritická), * Věcní správci identifikují další služby (datové centra, monitoring, ServiceDesk, penetrační testy, dočasné datové úložiště, služby mobilního sdílení dat, služby osobní produktivity, služby správy koncových uživatelských zařízení, služby portálu jako end user interface, provozní personál, konzultační služby atd.…), které k provozu a rozvoji ISVS potřebují, * Techničtí správci stanoví odpovídající architekturu implementace ISVS s využitím [[nap:egovernment_cloud|služeb eGC]] * Věcní správci s pomocí technických správců a [[nap:egovernment_cloud|TCO metodik eGC]] určí části ISVS, pro jejichž provoz by bylo ekonomické využít [[nap:egovernment_cloud|služeb eGC]], * Věcní správci uloží do IS o ISVS (tj. do katalogu aktuálně provozovaných ISVS) informace o svém ISVS v požadované struktuře, včetně případného požadavku na využití [[nap:egovernment_cloud|služeb eGC]]. Kritéria pro využití služeb [[nap:egovernment_cloud|eGovernment Cloudu]], představující kombinaci rozhodování podle hodnocení bezpečnostních dopadů a určení požadované bezpečnostní úrovně a na základě ekonomické výhodnosti budou aktualizována příslušnými právními předpisy a publikována s podrobnými návody a pomůckami jako součást [[:znalostni_baze|Znalostní báze]]. ==== Pravidla pro lepší nákup ICT řešení ==== Obstarávání ICT nákupem podle povahy konkrétního záměru se ve veřejné správě řídí požadavky právních předpisu upravujících nakládaní s veřejnými prostředky, zejména předpisy upravujícími zadávání veřejných zakázek. Všem zástupcům veřejné správy, účastnícím se v různých rolích procesu nákupu ICT, ukládá MŘICT povinnost vyhodnocovat, zda a jaké překážky při naplňování této koncepce způsobuje regulace nakládání s veřejnými prostředky a navrhovat MMR podněty k legislativním úpravám tak, aby byly naplno zachovány principy této regulace, přitom však, aby bylo umožněno jednotlivými nákupy naplňovat koncepční řízení informatiky VS ČR podle IKČR a podle informačních koncepcí jednotlivých orgánů veřejné správy. Základními problémy dobrého nákupu ICT řešení jsou zejména: * rozpor mezi přehnaně striktními opatřeními ZoZVZ, spojenými s nediskriminační soutěží jednoho ISVS nebo jeho dílčí komponenty a potřebou OVS jako dobrého hospodáře využít sdílené platformy eGovernmentu, úřadu nebo sdílené platformy společné pro více komponent jednoho ISVS * rozpor mezi běžným právním výkladem ZoZVZ ve smyslu nutnosti každé 4 roky „přesoutěžit“ dodavatele ISVS a mezi reálnou morální a technologickou udržitelnosti přinejmenším ASW/TASW v trvání 10-15 let. * rozpor mezi až „panickou“ obavou ze závislosti na dodavateli na jedné straně, a naopak přehlížením potenciálu dodavatele na druhé straně, aniž by se dařilo dosáhnout výhodného vyváženého dlouhodobého partnerství s dodavateli ISVS nebo jejich komponent. Jako dobrou praxi lze doporučit základní přístupy pro OVS a jejich rezorty. Do budoucna měly zejména využívat následující nástroje pro zvýšení transparentnosti přípravy a realizace zakázek na dodávky informačních systémů: * **Marketingový průzkum trhu** – představuje veřejnosti záměry organizace a umožňuje se vyjádřit k požadavkům a poptávanému konceptu řešení. * **Předběžná (individuální) tržní konzultace** – z historické zkušenosti vyplývá, že vhodným způsobem realizace tržní konzultace je individuální komunikace s podnikatelskými subjekty či veřejností. V průběhu v minulosti realizovaných tržních konzultací se totiž mnohdy ukázalo, že konzultace realizované za účasti více účastníků a zejména podnikatelských subjektů brání otevřenému dialogu. Každá ze stran v případě takové tržní konzultace intenzivně brání své know-how před potenciální konkurencí. Doporučenou formou jsou tedy individuální tržní konzultace spolu s řádnou dokumentací jejich průběhu a výstupů. * **Ověřovací projekt (PoC)** – bylo popsáno v rámci přístupu ex-ante kontroly v předcházejících kapitolách. Další věcná a odborná doplnění budou obsažena v následujících vydáních po projednání s odbornou veřejností.  === Základní opatření proti závislosti na dodavatelích v návrhu a nákupu === Základní podstata jevu závislosti na dodavateli (také Vendor-Lock-In) vyplývá zejména ze čtyř faktorů, a to: * z neschopnosti úřadu rozvíjet ISVS, protože sám při jeho implementaci a následné údržbě nevybudoval takovou kompetenci, tj. dostatek kvalifikovaných lidských zdrojů a dostatek znalostí, informací a dovedností; * z nemožnosti si takové zdroje obstarat, protože na zpravidla základě pro úřad nevhodného nastavení práv a povinností vůči dodavateli k tomu úřad není původním dodavatelem smluvně oprávněn; * z nemožnosti vysoutěžit z více dodavatelů služeb k produktu z důvodu unikátnosti vývojového či provozního prostředí, nebo neexistence více dodavatelů služeb k produktu na trhu; * z vlastností produktu, který je dodán bez vývojového prostředí (pouze zkompilovaný, spustitelný), bez zdrojových kódů, modelu a dokumentace, takže jej ani při nejlepší vůli nelze měnit. Z toho pro přípravu, implementaci a rozvoj ISVS vyplývají následující pravidla: - Úřad nesmí uzavřít takovou smlouvu, spojenou s informačním systémem, která by neobsahovala licenční ujednání, opravňující úřad poskytnout veškeré, v rámci smluvního plnění získané výstupy (zdrojový kód, vývojové prostředí, datový model, dokumentaci díla, školící podklady, uživatelské příručky apod.) libovolnému subjektu třetí strany dle své vlastní volby k podpoře, údržbě rozvoji nebo ukončení provozu a náhradě informačního systému. - Úřad není oprávněn uzavírat smlouvy, které by byly jednostranně nevýhodné, ať již pro něj nebo pro dodavatele. I podstatná nevýhodnost smluv vůči dodavateli se nakonec obrátí proti zadavateli, například zvýšenými riziky, zejména spojenými s neschopností dodavatele dostát neúměrným závazkům. - Úřad nesmí uzavřít smlouvu, spojenou s informačním systémem, který je natolik unikátní, že neexistuje více dodavatelů/poskytovatelů služeb, kteří jsou schopni takový systém rozvíjet, upravovat či provozovat. - V případě aplikačního SW těch řešení IS, která nepředpokládají a neumožňují žádné modifikace (datového modelu, programového kódu) ani přidávání Ad-on modulů, tj. dodávají se pouze ve spustitelném, zkompilovaném tvaru, bez zdrojových kódů a bez vývojového prostředí (například Antivirus nebo části Office) také musí platit, že veškeré výstupy spojené s dílem, dodané s ním nebo vzniklé v projektu musí být smluvně dostupné pro libovolné třetí strany, resp. veřejné, vyjma vlastního práva užívat řešení. Ostatní standardní (krabicový, COTS, TASW) aplikační SW pro řešení, u kterých OVS naopak předpokládá, že je bude potřebovat upravit na míru, a to nejen v rozsahu parametrických změn (např. uživatelské číselníky), ale i změn datového modelu a programových funkcí a veškerý SW vyvinutý na míru: * musí být smluvně i fyzicky dodán v podobě, umožňující úřadu dílo libovolně vlastními silami nebo s pomocí třetích stran udržovat a dále rozvíjet, * nikdy nesmějí být dodána pouze již zkompilovaná do spustitelného prostředí (Run-Time), ale musí obsahovat i plnou podporu fáze změn (Design-Time), tj. vývojové prostředí se všemi modely, knihovnami, zdrojovým kódem, vývojovou dokumentací apod. **Dále veškerý aplikační i provozní SW, vyvinutý na požadavek a za prostředky úřadu veřejné správy ČR, nebo EU, musí být dodán s otevřenou licencí, umožňující jeho využití, nebo využití jeho částí, kterýmkoli orgánem veřejné moci ČR – Open Source a licence EUPL.** Další detailní informace o Anti Vendor-Lock-In jsou uvedeny [[http://www.mvcr.cz/clanek/agenda-odboru-hlavniho-architekta-egovernmentu.aspx?q=Y2hudW09NQ%3d%3d|zde]], a budou dále doplňovány a průběžně aktualizovány ve [[:znalostni_baze|Znalostní bázi]]. Dlouhodobě se jedná o zajištění přidané hodnoty v oblasti provozu informačních systémů a aplikací prostřednictvím optimalizace uspořádání vazeb mezi jednotlivými systémy či aplikacemi a využití sdílených aplikačních funkcí. V užším technickém pojetí se jedná o integraci různých technických částí informačního systému (i různé vyzrálosti a morální zastaralosti), tedy systémů či aplikací do jednoho celku převážně pomocí integračních a orchestračních nástrojů. Cílem je výstavba takové architektury informačních systémů, která efektivně podporuje procesy a agendy v rámci OVS a jeho rezortu. Dále tento přístup umožňuje razantní zvýšení interoperability, flexibility a zároveň snižuje riziko závislosti na konkrétním dodavateli (tzv. vendor lock-in). Toho bude dosaženo zejména vytvářením aplikačních komponent, které poskytují služby, sdílené více aplikacemi. Naplněním tohoto cíle dojde k výraznému zjednodušení stávající architektury a snížení nákladů na modifikaci stávajících systémů a aplikací. Vedle snížení nákladů na implementaci a integraci nových systémů a aplikací dojde k větší automatizaci procesů, což přinese snížení nákladů a větší rychlost zpracování dat. V neposlední řadě bude umožněna snadnější integrace se systémy externích subjektů. Pro úspěšné dosažení představeného přístupu by měla být realizována následující opatření: * Přechod na servisně orientovanou a orchestrovanou architekturu – výstavba ESB/BPM platformy * Postupný přechod jednotlivých aplikací (systémů) na servisně orientovanou architekturu * Vedení dokumentace IS a služeb ICT v modelech, které jsou v souladu se standardy TOGAF a ArchiMate. Další věcná a odborná doplnění budou po projednání s odbornou veřejností obsažena v následujících vydáních a ve [[:znalostni_baze|Znalostní bázi]]. == Dosahování dlouhodobého vyváženého partnerství s dodavateli (zabránění Vendor-Lock-In) == MŘICT a [[:znalostni_baze|Znalostní báze]] budou napomáhat vzniku a udržení dlouhodobého vyváženého partnerství útvarů ICT s jejich dodavateli publikováním řady návodů a pomůcek, například vzorů smluv a zadávacích dokumentací či standardů a návodů (how-to). Zvážen bude také model, kdy se budou dílčí smlouvy jednotlivých OVS odkazovat na všeobecné obchodní podmínky veřejné správy, vydané po dohodě MV nebo MMR. Každému OVS by stále zůstávala volba nebo modifikace, ale v obchodních podmínkách již by byla vyvážená práva obou stran. Může se jednat o samostatnou přílohu, která bude reflektovat jak směrnici o majetku státu, tak zajištění znalostí k informačním systémům. Další věcná a odborná doplnění budou obsažena v následujících vydáních po projednání s odbornou veřejností. === Zásady pořizování programového vybavení jako Open Source === Open Source software a free software (OSS&FS) je nedílnou součástí ICT již mnoho let. Z bezpečnostního hlediska je již dávno prokázáno, že jsou tyto produkty bezpečné. Bohužel již mnoho produktů se historicky změnilo z OSS na placenou verzi. Dále se mnoho produktů přestalo podporovat a téměř u všech OSS projektů platí, že změny si musíme zařídit sami. Pořízení OSS je tedy rozhodně rizikové, pokud nezvážíme všechny dopady. V každém případě použitím OSS nám nevzniká řízení a správa bezúplatně. Dlouhodobá udržitelnost informačních celků není závislá na krátkodobém řešení. Primárním pohledem musí být život informačního celku během 5 a více let jeho životnosti, s jasnou strategií, jak k s ním i po základních 5 letech (relevantních pro TCO) dále pracovat. Pro užití a vhodnost integrace jednotlivých OSS produktů vznikne samostatná metodika. Bude zaměřena nejen na integraci OSS prvků do informačních celků, ale i na možnost sdílení úspěšných produktů jako je spisovka nebo anonymizér. Více o tématu bude publikováno ve [[:znalostni_baze|Znalostní bázi]]. === Pravidla pro oceňování vývoje nebo úprav IS === Pro lepší stanovení maximální ceny díla nebo pro porovnatelnost variant řešení s různou mírou programového přizpůsobení je nutné v ICT VS ČR používat jednotnou metodiku oceňování vývoje (nebo úprav) programového vybavení pro OVS, založenou např. na metodě funkčních bodů podle ČSN ISO/IEC 20926. Tato metodika by měla být vypracována a vydána jako další ze standardů útvaru OŘI MV, viz [[metody_dokument:uvod|Úvod]], a publikována ve [[:znalostni_baze|Znalostní bázi]]. === Smluvní zabezpečení === Vedoucí pracovníci útvarů ICT se musí v praxi potýkat s celou řadou typů smluvních vztahů (vývoj, provoz, podpora, licence,…), aniž by při tom měli k dispozici adekvátní podporu. Důležitým krokem je sjednotit typy smluv podle obsahu, délky, rozsahu apod., tj. přinést jednotu a řád do smluvního systému v řízení vztahů ICT s dodavateli. Dále je potřebné sebrat zkušenosti a přeměnit je na vyjádření nejlepší praxe v podobě garantovaných šablon smluv, včetně jejich případné kombinace s všeobecnými obchodními podmínkami, viz výše. Jedním z cílů dalšího vydání MŘICT a průběžné aktualizace [[:znalostni_baze|Znalostní báze]] je přinést další informace, dokumenty a pomůcky na podporu bezpečného a efektivního uzavíraní smluvních vztahů v ICT veřejné správy. ==== Koncepce řízení úspěšné realizace projektů navržených ICT změn ==== Tato kapitola je druhou částí rozpracování požadavků: „Zásady a postupy pro pořizování a vytváření informačních systémů veřejné správy“ dle [[https://www.e-sbirka.cz/sb/2023/360|Vyhlášky č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy)]] v okruhu otázek: jak vybrané řešení úspěšně zavést a uvést do produktivního provozu. Obsahuje podstatné a celostátně plošně platné standardy k požadavkům vyhlášky (po její předpokládané novele). === Pravidla řízení programů a projektů jednotlivých ISVS === Informatika v úřadu slouží svým interním klientům, informatické projekty mají přispívat k naplnění cílů celého úřadu, projekty změn veřejných služeb se stále více opírají o podporu informatiky. Všechny projekty v úřadu navíc sdílí omezené množství pro projekty vhodných lidských zdrojů. Proto musí být všechny jednotlivé projekty ISVS vzájemně koordinovány v rámci útvaru ICT, potom šířeji v rámci všech projektů celého úřadu a do budoucna i eGovernmentu ČR. Koordinace projektů, jejich provazování do programů a správa portfolií projektů je službou Projektové kanceláře úřadu (také jako "PK"(( V angl. Project Management Office - PMO.))). Navazuje na práci strategických útvarů a je znalostně podpořena službami útvaru celkové architektury úřadu, architektonické kanceláře (také jako "AK"). Více o společném řízení projektů a programů na úrovni úřadu v [[metody_dokument:rizeni_na_urovni_utvaru_ict|Řízení na úrovni útvaru ICT]]. == Řízení programu rozvoje ISVS == Všechny projekty, které vzájemně spolu souvisí v časové věcné či jiné návaznosti musí být řízeny jako program, aby bylo zajištěno, že společně dodají větší hodnotu a s větší jistotou, než kdyby byly řízeny každý samostatně. Zatímco řízení projektů je zaměřeno primárně na dosažení plánovaných výstupů při dodržení spotřeby plánovaných zdrojů, je řízení programu zaměřeno zejména na splnění strategických cílů a dosažení očekávaných přínosů. Z tohoto pohledu je doporučeno, aby i každý samostatný projekt byl řízen nejenom s využitím projektových, ale i programových principů. Více o řízení programů [[metody_dokument:rizeni_na_urovni_utvaru_ict|Řízení na úrovni útvaru ICT]]. == Řízení projektů ISVS jako součást portfolia == Velmi často je v útvaru ICT a v celém úřadu současně řízeno velké množství projektů. Zodpovědnost za jejich řízení je rozdělena mezi několik projektových ředitelů s podporou projektových manažerů. Skupině projektů se společnou zodpovědností jednoho ředitele nebo projektového manažera, nebo naopak skupině projektů, podobných si obsahem, funkčním celkem, dodavatelem, sdílenými zdroji či jiným kritériem, se říká portfolio. Základním rysem portfolia je, že za něj někdo konkrétní zodpovídá a vývoj všech projektů ve svém portfoliu někomu reportuje. Pro každý jednotlivý projekt ISVS z toho plyne, že musí být jednoznačně přidělen jednomu řediteli nebo manažeru a stát se tak součástí jeho portfolia, jeho zodpovědnosti a jeho výkaznictví vůči PK a vedení úřadu. Více o technikách řízení portfolia projektů v [[metody_dokument:rizeni_na_urovni_utvaru_ict|Řízení na úrovni útvaru ICT]]. === Pravidla řízení jednotlivých realizačních projektů ISVS === Pro každou činnost v oblasti informatiky, která splňuje definici projektu či podle rozsahu jejích důsledků, je IKČR stanoveno, aby od samého začátku byla důsledně řízena jako projekt, tj. s využitím metod, zodpovědností a nástrojů projektového řízení. Několik definic projektu, které se vzájemně mírně liší, ale všechny vyjadřují tutéž podstatu: * Projektem je časově, nákladově a zdrojově omezený soubor aktivit vedoucí k prosazení rozvojových strategických cílů, změn a inovací (kromě provozu, ale včetně rozsáhlých případů údržby, oprav, obnovy a nákupu služeb nebo hmotného i nehmotného majetku). * Projekt je časově omezené úsilí podniknuté za účelem vytvoření jedinečného produktu, služby nebo výsledku. To znamená, že projekt má definovaný začátek a konec. Jeho výsledkem je vytvořený jedinečný produkt či schopnost poskytovat službu, což je rozdíl od provozních činností, které jsou opakující se a bez definovaného konce. * Podle jiné definice je projektem „//jedinečný časově, nákladově a zdrojově omezený proces realizovaný za účelem vytvoření definovaných výstupů co do kvality, standardů a požadavků“//. * Projekt přináší jednorázovou (skokovou) změnu kvality svého předmětu, v tomto případě primárně změnu vlastností ISVS, kvalitativní změnu ICT infrastruktury, nebo změnu schopností útvaru informatiky, má pevný cíl, tj. rozsah změny, která musí být uskutečněna ve stanoveném čase a s využitím naplánovaného rozsahu zdrojů (finančních, lidských, materiálních,…). Povinnost uplatnit projektové řízení je stanovena pro projekty (alespoň jedno z toho): * jejichž hodnota výdajů je větší než 10% rozvojové a inovativní části ročního IT rozpočtu úřadu (nikoli provozní části rozpočtu), * u kterých míra zapojení lidských zdrojů (interních a externích, IT a odborných dohromady) přesahuje 10% vlastní roční interní kapacity IT útvaru úřadu - kritérium kapacit, * příprava a realizace změny trvá více než 3 měsíce - kritérium času, při kterých změny ICT řešení či infrastruktury mohou mít dopady na její odolnost proti kybernetickým rizikům nebo na schopnost dodávat služby veřejné správy - kritérium rizik. Po zkušenosti z praktické aplikace těchto pravidel je možné v dalším vydání dokumentu hranice projektového řízení ještě nějak omezit a vyjít tak vstříc malým úřadům, zejména samosprávám. Pro každý projekt, splňující výše uvedené podmínky, je úřad povinen zařadit do týmu projektu již před zahájením projektu odpovídající množství interních zaměstnanců tak, aby zajistil, že v projektu uplatněné či vytvořené Know-how zůstane jako znalost a dovednost (nikoli jenom dokumentace) nadále k dispozici v úřadu. Toto je jedním z několika nezbytných předpokladů obrany proti nežádoucí míře závislosti na dodavatelích (Vendor Lock-In). V této souvislosti je třeba zajistit, aby: * zaměstnanci úřadu, jejichž zařazení do projektu přesahuje 10% pracovní doby (4 hodiny týdně), byli pro projekt uvolněni(( Je třeba umožnit, aby zaměstnanec byl pro projekt uvolněn i bez svého souhlasu a bez souhlasu svého přímého představeného, například s využitím §47 Služebního zákona, č. 234/2014 Sb. o přeložení. Bylo by užitečné prosadit legislativní úpravu nejdelší doby přeložení bez souhlasu zaměstnance na 120 dnů v kalendářním roce a se souhlasem zaměstnance až na dobu trvání projektu.)) a odpovídající část jejich běžné práce a zodpovědnosti byla (formálně i fakticky) převedena na ostatní zaměstnance úřadu. * zaměstnanci v rozsahu svého začlenění do projektu podléhali personálně vedení projektu, tzn., že jejich přímým nadřízeným je vedoucí řešitelského týmu, který mj. schvaluje výkazy práce zaměstnance a přiznává mu odměny za práci na projektu. Eskalačními úrovněmi jsou projektový manažer a řídící výbor. To je možné řešit formou pověřovacích dekretů, viz níže. * v případě účasti externího dodavatele byly v zadávací dokumentaci a smlouvě jako nedílné součástí plnění požadovány činnosti, výstupy a způsob práce (přístup), vedoucí k efektivnímu předání znalostí a aktivních dovedností (například: nastavení systému nebo naplňování číselníků v systému neprovádí externí poradce, nýbrž interní zaměstnanec pod vedením poradce, …). V části MŘICT o přístupu k řízení útvarů informatiky je popsáno, jakými rolemi a pozicemi musí úřad a útvar IT minimálně disponovat (In/Out), aby mohl plnit výše uvedené požadavky. Pro kvalitní a bezpečné řízení projektů ICT změn je nutné přinejmenším přiřadit konkrétní lidské zdroje (jmenovitě) k následujícím rolím: * Sponzor projektu – statutární člen vedení úřadu(( pokud jím není Ředitel projektu nebo Věcný gestor změny (agendy))) * Ředitel projektu – příkazce operace, (u nadresortních projektů je nezbytné jmenování vládou) * Projektový manažer – odborník na projektové řízení * Architekt řešení (doménový i platformový) * Analytik – interní konzultant, schopný parametrizovat a rozvíjet řešení * Manažer skupiny IT služeb („obchodník“ s IT službami pro interní klienty – odborné útvary) * Manažer provozu ICT * Nákupčí externích služeb * Ekonom IT (správce rozpočtu projektu) - schopný controllingu útvaru, projektů i komponent * Auditor IT – poskytujícího vedení ICT i ostatním složkám úřadu funkce IT governance * a další Ve [[:znalostni_baze|Znalostní bázi]] bude připravena tabulka očekávaných pracovních a služebních pozic pro jednotlivé projektové role. Jmenování musí proběhnout písemně, prostřednictvím pověřovacího dekretu s podpisem jmenovaného a představeného / vedoucího pracovníka. Přitom je zjevné, že úřad může pro realizaci těchto rolí využít externích dodavatelů služeb, tím se ale nezbavuje povinnosti mít rolím přiděleny interní zaměstnance, „stínující“ - kontrolující externisty, s jasně definovanými zodpovědnostmi. Role sponzor projektu, ředitel projektu a ekonom IT (správce rozpočtu projektu) není možné zajistit externě. Každý projekt musí mít uvedené role uspořádány v organizační struktuře, obsahující v hierarchii pravomocí a zodpovědností: * Řídící výbor projektu (také jako "ŘVP"), vedený jeho předsedou a zahrnující přinejmenším sponzora projektu a ředitele projektu a statutárního zástupce úřadu, pokud jím není sponzor ani ředitel projektu. * Hlavní tým projektu (také jako "HTP"), vedený ředitelem projektu, zahrnující přinejmenším projektového manažera, manažera projektu za dodavatele, projektového administrátora, Hlavního architekta projektu a vedoucí řešitelských týmů. Součástí hlavního týmu projektu jsou dle potřeby podpůrné role pro ředitele projektu, jako například technický a věcný gestor projektu, právník, ekonom (správce rozpočtu projektu), manažer kvality a manažer publicity projektu. * Řešitelské týmy projektu (také jako "TP"), vedené vedoucími řešitelských týmů a zahrnující přinejmenším členy týmu ze strany úřadu, případně členy týmu za dodavatele. U velmi malých projektů(( Definice malého projektu a velmi malého projektu budou ještě hledány.)) je možné role a zodpovědnosti v plánu řízení projektu odpovídajícím způsobem redukovat, například tak, že část role a zodpovědností řídícího výboru přebírá samostatný ředitel projektu (který nesmí nikdy chybět), zbylou část zodpovědností ŘVP přebírá vedení úřadu jako celek, část rolí a zodpovědností hlavního týmu přebírá projektový manažer a zbylou část rolí HTP a všechny role řešitelských týmů přebírá jeden společný tým projektu. Redukce je na rozhodnutí projektové kanceláře nebo vedení úřadu, tam, kde ještě PK není. Každý ICT projekt bez ohledu na obsah nebo velikost obsahuje metodikou stanovenou minimální sadu fází svého životního cyklu s pevně stanovenými termíny. Bez ohledu na použitou metodiku projektového řízení (Prince2, PMI, atd.) musí projekt projít nejméně povinnou, metodikou stanovenou minimální sadou kontrolních milníků či průběžných aktivit, sladěných jak s potřebou dodávky kvalitních ICT řešení, tak s požadavky procesů finanční kontroly a veřejných zakázek. Z povinné a rozšířené sady milníků, průběžných činností a výstupů projektu se zdůvodněným způsobem při iniciálním plánování projektu vyberou milníky, činnosti a výstupy relevantní pro konkrétní projekt. Ne výběr, vynechání povinného milníku, činnosti nebo výstupu je nutné v projektové dokumentaci zřetelně zdůvodnit. Projekt, řízený ve shodě s těmito pravidly IKČR musí vytvořit a užívat přinejmenším metodikou stanovenou minimální sadu výstupů / pracovních dokumentů. Každý projekt musí mít v rámci projektové přípravy zpracován minimálně projektový záměr, v průběhu realizace plán řízení projektu a při ukončení zprávu o průběhu projektu. Součástí mechanismu řízení projektu musí být povinný reporting vedení úřadu, například prostřednictvím projektové kanceláře, či řídícího výboru projektu jedenkrát měsíčně, obsahující metodikou stanovenou minimální sadu údajů. Součástí řízení projektu musí být aktivní práce s klíčovými zainteresovanými stranami, jejich oprávněnými potřebami a očekáváními. Součástí řízení projektu musí být průběžné a závěrečné vyhodnocení dosažených výsledků a přínosů, řízené poučení se z nabytých zkušeností(( Z angl. Lessons Learned)). Více informací a pravidel k řízení ICT projektů a jejich portfolií, včetně vazeb na řízení lidských zdrojů vydá MV ČR ve formě aktualizace Metodiky řízení IT projektů, kterou bude publikovat také jako součást [[:znalostni_baze|Znalostní báze]]. == Řízení rizik a bezpečnosti v realizačních projektech == Důležitou a neopominutelnou součástí řízení projektu je, vedle řízení rozsahu, času a zdrojů projektu (rozpočet, lidé a technika/aktiva), také řízení rizik a přijímání přiměřených opatření pro jejich snížení. Součástí řízení rizik a bezpečnosti projektu je řízení kybernetických rizik a bezpečnosti v souladu s metodami jejich řízení a pomocí nástrojů na úrovni celého ICT útvaru a úřadu, [[metody_dokument:rizeni_na_urovni_utvaru_ict|Řízení na úrovni útvaru ICT]].. Jako optimální metoda řízení rizik slouží kombinace postupů ze standardních metod projektového řízení, z rámce TOGAF a z vydaných doporučení NÚKIB. Je plánováno vydat ve [[:znalostni_baze|Znalostní bázi]] sadu akcelerátorů na podporu nejlepší praxe v této oblasti. V projektu se musí uplatnit i další principy jako „Security by design“ a metody jako bezpečný vývoj SW. === Schvalování projektů Odborem HA MV ČR === Proces je řízen v souladu průběžně vydávanými Metodickými pokyny OHA a jim odpovídajícími formuláři, viz web OHA, které společně s dalšími návody a pomůckami budou průběžně aktualizovány ve [[:znalostni_baze|Znalostní bázi.]] === Zásady dokumentace skutečného provedení IT řešení === Znalost aktuálního stavu konfiguračních položek ICT aplikační a technologické architektury je nezbytným předpokladem jejího efektivního řízení. Součástí této znalosti ale často není aktuální dokumentace ICT systémů, resp. akceptovaná dokumentace skutečného provedení požadované změny (např. nastavení přístupových práv jednotlivých uživatelských rolí) nebo nové ICT služby, a to včetně znalosti o aktuální smluvní podpoře (maintenance), resp. o smluvních SLA (jaká jsou, do kdy trvají, …). Odpovědnost za promítnutí akceptovaných změn do aktuální dokumentace by vždy měla být pro jednotlivé ICT systémy jednoznačně určena. Optimální je tuto činnost zařadit jako nedílnou součást do akceptačních procesů a odpovědností za ně pověřit organizačně příslušného Technického správce. Standardy, vzory a typové příklady takové dokumentace budou postupně aktualizovány ve [[:znalostni_baze|Znalostní bázi]]. == Dokumentace programových modifikací == V posledních dvou letech se významně posunula správa programového vybavení díky možnosti vlastního nasazení portálu Gitlab, který nejen spravuje všechny verze programového vybavení, ale především je možné nastavit u tohoto způsobu nasazování i strojové kontroly. Dále je možné se vracet mezi verzemi a také kontrolovat popsaný zdrojový kód. V komerčním světě velice rychle došlo ke změně nasazování systémů přes Gitlab, protože takové nasazení nevyžaduje lidskou součinnost a zároveň je zde úplná auditní stopa provedených změn. == Aktualizace architektury řešení a architektury úřadu == Aktualizace architektury by měla mít nastavený milník jednou ročně nebo maximálně dvouletý cyklus v případě malých v liniovém řízení realizovaných změn. V případě projektově realizovaných změn musí být v rámci akceptace výstupů projektu, s dokumentací skutečného provedení společně dokončena a předána i aktualizace modelů architektury předmětného řešení na všech úrovních podrobnosti (EA-PSA, SA i SD(( Enterprise architektura, architektura řešení i návrh (design) řešení.))). Katalogové listy musí mít v sobě i záznam o všech změnách a následně v daném milníku dojde k propagaci všech změn z katalogových listů do modelů architektury. === Zásady akceptace výstupů projektu a přechodu do produktivního provozu === Pečlivá akceptace výsledků realizace změn a ověření úspěšného přechodu nových služeb IS do produktivního provozu je jedním z klíčových okamžiků projektu i milníkem životního cyklu informačního systému. Řádná akceptace výstupů souvisí přímo také s tzv. Ex-ante přístupem k plánování a řízení změn (viz [[metody_dokument:rizeni_jednotlivych_ict_reseni|Řízení jednolitých ICT řešení]]), neboť umožňuje ověřit dosažení plánovaných ukazatelů vybraného způsobu řešení. Záměrem MŘICT je v návaznosti na typy uzavřených smluv ([[metody_dokument:rizeni_jednotlivych_ict_reseni|Řízení jednolitých ICT řešení]]), různé způsoby realizace řešení realizovaných změny ([[metody_dokument:rizeni_jednotlivych_ict_reseni|Řízení jednolitých ICT řešení]]), Metodiku řízení IT projektů ([[metody_dokument:rizeni_jednotlivych_ict_reseni|Řízení jednolitých ICT řešení]]) a další aspekty pořizovaného řešení, připravit a ve [[:znalostni_baze|Znalostní bázi]] aktualizovat sadu návodů a akcelerátorů pro snazší a důslednější provedení řádné akceptace dodávky realizovaných změn. ===== Pravidla efektivního řízení provozu a dodávky služeb, nákupu služeb a průběžného zlepšování ===== Odpovídá procesům dle ITIL: částečně Service Design, částečně Service Transition, plně Service Operation a Continual Service Improvement a dále procesům dle COBIT 5: Deliver, Service and Support Budeme diskutovat s dalšími partnery a výsledek bude doplněn. ==== Budování a údržba kompetencí k provozu a rozvoji IT řešení ==== Budování monitoringu, definice monitoringu a budování oddělení pro podporu a rozvoj ICT služeb, včetně mechanismů návazností na katalogové listy a SLA. Budeme diskutovat s dalšími partnery a výsledek bude doplněn. Příklad pravidla: Úřad je povinen již v průběhu implementace nového řešení nebo po účinnosti této IKČR k řešením, u nichž tak v minulosti neučinil, vybudovat vlastní středisko kompetence (kompetenční centrum) k údržbě a rozvoji IS, za jejichž flexibilní legislativní rozvoj jako věcný správce odpovídá. Vlastní kompetenční středisko může nahradit zajištěním takové kompetence od jiného subjektu veřejné správy nebo státem vlastněného subjektu, smluvně nebo ze zákona, musí se však jednak o kompetentní kapacity, nezávislé na původním dodavateli, s nimiž může úřad disponovat, jakoby šlo o vlastní zaměstnance. Kompetenční středisko je nutné udržovat pro řešení a platformy těchto řešení. ==== Zásady a postupy pro provozování informačních systémů veřejné správy ==== Budeme diskutovat s dalšími partnery a výsledek bude doplněn. ==== Zásady péče o klienty a uživatele služeb informačních systémů ==== Dílčí doporučení vážící se ke znalostní bázi ServiceDesku: Vypořádání každé životní situace ve světě ICT musí být měřitelné, protože 90 % všech životních situací se opakuje a díky znalostní bázi se ve všech případech zrychluje systém řízení obsluhy. Každý incident se poprvé řeší dny, na podruhé hodiny a při dalším stejném případu se vyřeší ve stejný den. Pokud používáte informační systém, centralizujete všechny požadavky do jednoho místa a máte na jejich vypořádání zodpovědný tým, potom následná klasifikace těchto požadavků zrychlí zcela přirozeně jejich vypořádání. Další metody péče o klienty ISVS budou po projednání s odbornou veřejnosti obsaženy v následujících vydáních MŘICT a aktualizovány ve [[:znalostni_baze|Znalostní bázi]]. ===== Pravidla nepřímého řízení (governance) ISVS ===== Metody nepřímého řízení (governance) ISVS budou po projednání s odbornou veřejnosti obsaženy v následujících vydáních MŘICT a aktualizovány ve [[:znalostni_baze|Znalostní bázi]].