Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

Odkaz na výstup diff

Obě strany předchozí revize Předchozí verze
Následující verze
Předchozí verze
metody-dokument:rizeni_na_urovni_utvaru_ict [2020/04/28 15:16] – [Řízení projektů a programů úřadu] Tomáš Šedivecmetody_dokument:rizeni_na_urovni_utvaru_ict [2023/07/27 13:14] (aktuální) Tomáš Šedivec
Řádek 5: Řádek 5:
 Tato kapitola pokrývá obojí, ale zejména shrnuje vybrané klíčové úlohy, postupy a metody pro řízení ICT OVS jako jednotného celku a současně vyzdvihuje opakující se metody a postupy z životních cyklů jednotlivých IS, které vyžadují jednotný a centrální přístup (z pohledu OVS i státu). Tato kapitola pokrývá obojí, ale zejména shrnuje vybrané klíčové úlohy, postupy a metody pro řízení ICT OVS jako jednotného celku a současně vyzdvihuje opakující se metody a postupy z životních cyklů jednotlivých IS, které vyžadují jednotný a centrální přístup (z pohledu OVS i státu).
  
-Tyto centrální činnosti na úrovni úřadu a státu odpovídají i identifikovaným fázím životního cyklu jednotlivých ICT aktiv (IS, řešení, funkčních celků), více v [[metody-dokument:rizeni_jednotlivych_ict_reseni|Řízení jednotlivých ICT řešení]] a jsou předpokladem toho, aby se individuální činnosti správy jednotlivých aktiv odehrávaly koordinovaně, v souvislostech a s respektem k celkovým zájmům OVS a VS ČR.+Tyto centrální činnosti na úrovni úřadu a státu odpovídají i identifikovaným fázím životního cyklu jednotlivých ICT aktiv (IS, řešení, funkčních celků), více v [[metody_dokument:rizeni_jednotlivych_ict_reseni|Řízení jednotlivých ICT řešení]] a jsou předpokladem toho, aby se individuální činnosti správy jednotlivých aktiv odehrávaly koordinovaně, v souvislostech a s respektem k celkovým zájmům OVS a VS ČR.
  
 ===== Klíčové principy řízení ICT v úřadu ===== ===== Klíčové principy řízení ICT v úřadu =====
Řádek 61: Řádek 61:
 Útvar ICT má mít udržovanou i relevantní část motivační architektury ve všech čtyřech vertikálních doménách, aby mohl sdílet v týmu i se zbytkem úřadu porozumění své motivaci a poslání, své výkonnosti, bezpečnosti i svým regulacím a omezením. Útvar ICT má mít udržovanou i relevantní část motivační architektury ve všech čtyřech vertikálních doménách, aby mohl sdílet v týmu i se zbytkem úřadu porozumění své motivaci a poslání, své výkonnosti, bezpečnosti i svým regulacím a omezením.
  
-Lze předpokládat, že aktivitou pilotních úřadů při adopci těchto Metod řízení vzniknou a budou zobecněny ověřené modely jednotlivých domén architektury ICT schopnosti a budou publikovány v [[nap-dokument:nap|NAP]] a ve [[:start|Znalostní bázi]] jako referenční modely a akcelerátory modelování OVS.+Lze předpokládat, že aktivitou pilotních úřadů při adopci těchto Metod řízení vzniknou a budou zobecněny ověřené modely jednotlivých domén architektury ICT schopnosti a budou publikovány v [[:nap_dokument|NAP]] a ve [[:znalostni_baze|Znalostní bázi]] jako referenční modely a akcelerátory modelování OVS.
  
  
Řádek 72: Řádek 72:
 Přesto i nadále zůstává plná zodpovědnost za plánování a řízení získání, udržení a rozvoje kvalifikovaných IT kapacit na vedení jednotlivých orgánů veřejné správy. Přesto i nadále zůstává plná zodpovědnost za plánování a řízení získání, udržení a rozvoje kvalifikovaných IT kapacit na vedení jednotlivých orgánů veřejné správy.
  
-MV ČR vydá pro tuto oblast řízení ICT Metodiku (nebo koncepci) řízení lidských zdrojů a bude publikovat další informace a pomůcky ve Znalostní bázi.+MV ČR vydá pro tuto oblast řízení ICT Metodiku (nebo koncepci) řízení lidských zdrojů a bude publikovat další informace a pomůcky ve [[:znalostni_baze|Znalostní bázi]].
  
 ==== Přístup k rozvoji lidských zdrojů informatizace ==== ==== Přístup k rozvoji lidských zdrojů informatizace ====
Řádek 90: Řádek 90:
 ==== Rozvoj a udržení znalostí a kompetencí  ==== ==== Rozvoj a udržení znalostí a kompetencí  ====
  
-Informatika je znalostní disciplínou, závislou na udržování aktuálních přehledových i detailních znalostech v oboru. Provedený ICT Benchmark (Digitální Česko, 2018) zjistil, že některé OVS mají pro každého zaměstnance ICT útvaru v rozpočtu na vzdělávání vyhrazenu mizivou částku, odpovídající 1 hodině až 1 dni komerčního školení ročně.+Informatika je znalostní disciplínou, závislou na udržování aktuálních přehledových i detailních znalostech v oboru. Provedený {{:dokumenty:benchmark_jp_mt_final_s_dostaznikem.pdf|ICT Benchmark}} zjistil, že některé OVS mají pro každého zaměstnance ICT útvaru v rozpočtu na vzdělávání vyhrazenu mizivou částku, odpovídající 1 hodině až 1 dni komerčního školení ročně.
  
 Aktivní zapojení ICT do digitální transformace a dobře napsaná IK úřadu musí argumentačně podpořit vyjednávání informatiků o rozpočtu. Vedle toho je ale úlohou útvaru Řízení ICT na MV (OŘI) zajistit dostupnější školení pracovníků VS podílejících se na řízení a provozu ICT služeb, ať využitím výše uvedených kompetenčních center VS nebo pro tento účel úzce spolupracovat s univerzitními pracovišti. Aktivní zapojení ICT do digitální transformace a dobře napsaná IK úřadu musí argumentačně podpořit vyjednávání informatiků o rozpočtu. Vedle toho je ale úlohou útvaru Řízení ICT na MV (OŘI) zajistit dostupnější školení pracovníků VS podílejících se na řízení a provozu ICT služeb, ať využitím výše uvedených kompetenčních center VS nebo pro tento účel úzce spolupracovat s univerzitními pracovišti.
Řádek 158: Řádek 158:
 ==== Koncepce řízení ekonomiky ICT ve veřejné správě  ==== ==== Koncepce řízení ekonomiky ICT ve veřejné správě  ====
  
-Bude doplněno po projednání s odbornou veřejností a publikováno  v následujících vydáních MŘICT a ve Znalostní bázi.+Bude doplněno po projednání s odbornou veřejností a publikováno  v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].
  
 ====  Řízení smluv a závazků vůči dodavatelům ==== ====  Řízení smluv a závazků vůči dodavatelům ====
Řádek 178: Řádek 178:
   * Součástí řízení smluv je i vazba na řízení rizik, spojených s výpadkem smluv a na řízení rozpočtů, pro zajištění závazků ze smluv.   * Součástí řízení smluv je i vazba na řízení rizik, spojených s výpadkem smluv a na řízení rozpočtů, pro zajištění závazků ze smluv.
  
-Více praktických doporučení a pomůcek k řízení smluv s dodavateli bude postupně vydáno ve Znalostní bázi.+Více praktických doporučení a pomůcek k řízení smluv s dodavateli bude postupně vydáno ve [[:znalostni_baze|Znalostní bázi]].
  
 ==== Komplexní správa licencí  ==== ==== Komplexní správa licencí  ====
Řádek 192: Řádek 192:
 Evidence licencí v ICT musí být na jedné straně provázána na majetkovou evidenci v ekonomickém útvaru, dále na správu portfolií aktiv (Katalogy), na správu uživatelů a oprávnění, správu znalostí a kompetencí (Anti-Vendor-Lock-In opatření) apod. Evidence licencí v ICT musí být na jedné straně provázána na majetkovou evidenci v ekonomickém útvaru, dále na správu portfolií aktiv (Katalogy), na správu uživatelů a oprávnění, správu znalostí a kompetencí (Anti-Vendor-Lock-In opatření) apod.
  
-Součástí místní nebo korporátní správy licencí musí být vazba na centrální nákupy licencí státu a maximální využití nabízených centrálních licencí, viz [[metody-dokument:spoluprace_s_ostatnimi_utvary_uradu_a_egovernmentu|SPolupráce s ostatními útvary úřadu a eGovernmentu]].+Součástí místní nebo korporátní správy licencí musí být vazba na centrální nákupy licencí státu a maximální využití nabízených centrálních licencí, viz [[metody_dokument:spoluprace_s_ostatnimi_utvary_uradu_a_egovernmentu|SPolupráce s ostatními útvary úřadu a eGovernmentu]].
  
 === OpenSource Software a Free Software === === OpenSource Software a Free Software ===
  
-Součástí zodpovědnosti role Licenčního manažera OVS je i koordinovat a podporovat rozhodování o použití OpenSource Software a Free Software (dále jen OSS/FS) jako způsobu realizace jednotlivých IS, viz kapitola [[metody-dokument:rizeni_jednotlivych_ict_reseni|Řízení jednolitých ICT řešení]].+Součástí zodpovědnosti role Licenčního manažera OVS je i koordinovat a podporovat rozhodování o použití OpenSource Software a Free Software (také jako "OSS/FS") jako způsobu realizace jednotlivých IS, viz kapitola [[metody_dokument:rizeni_jednotlivych_ict_reseni|Řízení jednolitých ICT řešení]].
  
 Na úrovni útvaru ICT, případně korporace a státu, je potřeba přijmout politiky a opatření, která umožní na jedné straně převzít zodpovědnost a vybudovat kapacity pro podporu a údržbu OSS/FS, zejména pokud bude mít podobu sdíleného programového kódu veřejné správy a na druhé straně budou představovat exit strategii odchodu od OSS/FS v případě ztráty jeho podpory. Na úrovni útvaru ICT, případně korporace a státu, je potřeba přijmout politiky a opatření, která umožní na jedné straně převzít zodpovědnost a vybudovat kapacity pro podporu a údržbu OSS/FS, zejména pokud bude mít podobu sdíleného programového kódu veřejné správy a na druhé straně budou představovat exit strategii odchodu od OSS/FS v případě ztráty jeho podpory.
Řádek 202: Řádek 202:
 Součástí kompetence licenčního manažera je také disponovat nezbytnými znalostmi, podklady a pomůckami pro úspěšné zacházení s OSS/FS v průběhu životního cyklu IS (návrh řešení, zadávací dokumentace, smluvní ustanovení, správa kódu, dokumentace, sdílení apod.). Součástí kompetence licenčního manažera je také disponovat nezbytnými znalostmi, podklady a pomůckami pro úspěšné zacházení s OSS/FS v průběhu životního cyklu IS (návrh řešení, zadávací dokumentace, smluvní ustanovení, správa kódu, dokumentace, sdílení apod.).
  
-Další věcná a odborná doplnění budou po projednání s odbornou veřejnosti obsažena v následujících vydáních MŘICT a aktualizována ve Znalostní bázi. +Další věcná a odborná doplnění budou po projednání s odbornou veřejnosti obsažena v následujících vydáních MŘICT a aktualizována ve [[:znalostni_baze|Znalostní bázi]]
  
 ===== Správa vlastních informačních systémů ICT  ===== ===== Správa vlastních informačních systémů ICT  =====
Řádek 211: Řádek 211:
   * pro celkové řízení portfolií a služeb postupoval stejně, jako při správě aplikací pro všechny ostatní věcné správce.   * pro celkové řízení portfolií a služeb postupoval stejně, jako při správě aplikací pro všechny ostatní věcné správce.
  
-V důsledku toho musí být i aplikace potřebné pro řízení ICT a dodávku ICT služeb plnohodnotně viditelné v celkových modelech architektury úřadu, viz také [[metody-dokument:predpoklady_a_vychodiska_rizeni_ict|Předpoklady a východiska řízení ICT]].+V důsledku toho musí být i aplikace potřebné pro řízení ICT a dodávku ICT služeb plnohodnotně viditelné v celkových modelech architektury úřadu, viz také [[metody_dokument:predpoklady_a_vychodiska_rizeni_ict|Předpoklady a východiska řízení ICT]].
  
 Další věcná a odborná doplnění, týkající se jednotlivých klíčových typů informačních systémů, užívaných útvarem ICT pro vnitřní řízení a poskytování svých služeb (CMDB(( databáze konfigurací, z angl.. Configuration Management DataBase Další věcná a odborná doplnění, týkající se jednotlivých klíčových typů informačních systémů, užívaných útvarem ICT pro vnitřní řízení a poskytování svých služeb (CMDB(( databáze konfigurací, z angl.. Configuration Management DataBase
-)), ServiceDesk, apod.), budou po projednání s odbornou veřejnosti obsažena v následujících vydáních MŘICT a aktualizována ve Znalostní bázi. +)), ServiceDesk, apod.), budou po projednání s odbornou veřejnosti obsažena v následujících vydáních MŘICT a aktualizována ve [[:znalostni_baze|Znalostní bázi]]
  
 =====  Strategické plánování a řízení ICT OVS ===== =====  Strategické plánování a řízení ICT OVS =====
Řádek 229: Řádek 229:
 V běžném managementu transformujících se organizací, a pro veřejnou správu to platí obzvláště, je velká mezera mezi kreativním stanovením strategických směrů a cílů a nalezením proveditelných zadání realizačních projektů akčního plánu. Většina strategických změn musí současně obsahovat podstatnou změnu ICT podpory a vede na ICT projekty výstavby nebo zásadní změny ICT řešení. V běžném managementu transformujících se organizací, a pro veřejnou správu to platí obzvláště, je velká mezera mezi kreativním stanovením strategických směrů a cílů a nalezením proveditelných zadání realizačních projektů akčního plánu. Většina strategických změn musí současně obsahovat podstatnou změnu ICT podpory a vede na ICT projekty výstavby nebo zásadní změny ICT řešení.
  
-Zcela oprávněnou potřebou útvaru ICT v roli technického správce je dostávat od strategických a odborných útvarů (věcný správce) smysluplné, správné, srozumitelné a proveditelné zadání, viz také přístup ex-ante [[metody-dokument:rizeni_jednotlivych_ict_reseni|Řízení jednolitých ICT řešení]].+Zcela oprávněnou potřebou útvaru ICT v roli technického správce je dostávat od strategických a odborných útvarů (věcný správce) smysluplné, správné, srozumitelné a proveditelné zadání, viz také přístup ex-ante [[metody_dokument:rizeni_jednotlivych_ict_reseni|Řízení jednolitých ICT řešení]].
  
 Prostředkem, jak překlenout propast mezi zvoleným strategickým směrováním a proveditelným zadáním projektu je právě využití architektury úřadu, zejména vypracování architektonické vize a kompletní individuální architektury úřadu a jejich uplatnění při tvorbě Informační koncepce OVS a při návrhu řešení jednotlivých změnových záměrů. Prostředkem, jak překlenout propast mezi zvoleným strategickým směrováním a proveditelným zadáním projektu je právě využití architektury úřadu, zejména vypracování architektonické vize a kompletní individuální architektury úřadu a jejich uplatnění při tvorbě Informační koncepce OVS a při návrhu řešení jednotlivých změnových záměrů.
Řádek 250: Řádek 250:
 Každé architektonické angažmá úspěšně končí schválením jeho výstupů architektonickou radou úřadu a jejich akceptací zadavatelem (sponzorem). Každé architektonické angažmá úspěšně končí schválením jeho výstupů architektonickou radou úřadu a jejich akceptací zadavatelem (sponzorem).
  
-Kompletní pravidla pro tvorbu architektonické vize a kompletní individuální architektury OVS přináší dokument Národní architektonický rámec (NAR). Další detaily a pomůcky, zejména k jednotlivým typům architektonických angažmá jsou průběžně aktualizovány ve Znalostní bázi.+Kompletní pravidla pro tvorbu architektonické vize a kompletní individuální architektury OVS přináší dokument Národní architektonický rámec (NAR). Další detaily a pomůcky, zejména k jednotlivým typům architektonických angažmá jsou průběžně aktualizovány ve [[:znalostni_baze|Znalostní bázi]].
  
 === Role, procesy a obory v rámci architektonických změn úřadu === === Role, procesy a obory v rámci architektonických změn úřadu ===
Řádek 281: Řádek 281:
   * průřezové architektury - celková Enterprise architektura a její vize.   * průřezové architektury - celková Enterprise architektura a její vize.
  
-Obor architektury jako takový představuje podmnožinu architektury, vyžadující od odpovědných architektů podobnou specifickou kvalifikaci a znalosti. Za návrh, správu a rozvoj architektur v jednotlivých oborech je odpovědná role hlavního architekta pro daný obor. Odpovědnosti a úkoly těchto rolí budou detailně dopracovány v dalších přílohách MŘICT ve Znalostní bázi.+Obor architektury jako takový představuje podmnožinu architektury, vyžadující od odpovědných architektů podobnou specifickou kvalifikaci a znalosti. Za návrh, správu a rozvoj architektur v jednotlivých oborech je odpovědná role hlavního architekta pro daný obor. Odpovědnosti a úkoly těchto rolí budou detailně dopracovány v dalších přílohách MŘICT ve [[:znalostni_baze|Znalostní bázi]].
  
 === Principy, vzory a referenční architektury – standardy pro architektonické změny === === Principy, vzory a referenční architektury – standardy pro architektonické změny ===
Řádek 297: Řádek 297:
 Je žádoucí, aby se oboje (státní i vlastní) principy, vzory a referenční modely plně uplatnily v celém životním cyklu jednotlivých ISVS a promítly se do standardizace a sjednocování architektur celého úřadu, včetně například prosazování jednotlivých standardizovaných platforem v zadávacích dokumentacích pro výběr dodavatele dle ZoZVZ. Je žádoucí, aby se oboje (státní i vlastní) principy, vzory a referenční modely plně uplatnily v celém životním cyklu jednotlivých ISVS a promítly se do standardizace a sjednocování architektur celého úřadu, včetně například prosazování jednotlivých standardizovaných platforem v zadávacích dokumentacích pro výběr dodavatele dle ZoZVZ.
  
-Další věcná a odborná doplnění, týkající se architektonických principů, vzorů a referenčních modelů, budou po projednání s odbornou veřejnosti obsažena v následujících vydáních NAR a NAP a aktualizována ve Znalostní bázi.+Další věcná a odborná doplnění, týkající se architektonických principů, vzorů a referenčních modelů, budou po projednání s odbornou veřejnosti obsažena v následujících vydáních NAR a NAP a aktualizována ve [[:znalostni_baze|Znalostní bázi]].
  
 === Návrh ICT služeb souborem nástrojů architektur řešení a řízení služeb  === === Návrh ICT služeb souborem nástrojů architektur řešení a řízení služeb  ===
  
-Pro návrh a následnou podporu služeb ICT a vlastně služeb jako takových lze využít kombinací systematických pohledů ITIL v. 3 a NAR (resp. TOGAF(( Národní architektonický rámec (NAR) byl vytvořen na základě kombinace TOGAF 9.2 a ArchiMate 3.0.1.))), respektive kombinaci jejich metod.+Pro návrh a následnou podporu služeb ICT a vlastně služeb jako takových lze využít kombinací systematických pohledů ITIL v5 a NAR (resp. TOGAF(( Národní architektonický rámec (NAR) byl vytvořen na základě kombinace TOGAF 9.2 a ArchiMate 3.1.))), respektive kombinaci jejich metod.
  
 ITIL je dnes faktickým standardem pro implementaci řízení IT služeb a sbírka nejlepších zkušeností („best practice“) z oblasti řízení služeb IT a z nich vyplývajících doporučení. Za pomoci jednotlivých managementů nabízí systematický přístup k nalézání, plánování, dodávce a podpoře IT služeb (klient VS, interní zadavatel/klíčový uživatel). Svými oblastmi pokrývá celý životní cyklus služeb v částech Service Strategy, Service Design, Service Transition, Service Operation a Continual Service Improvement. Řídit služby dle ITIL tedy znamená zejména nastavit procesy a připravit systémovou podporu. Efektivní řízení ICT služeb dle ITIL (SLM) a vyhodnocování jejich SLA vyžaduje existenci tzv. runtime model služby neboli servisní strom služby. ITIL je dnes faktickým standardem pro implementaci řízení IT služeb a sbírka nejlepších zkušeností („best practice“) z oblasti řízení služeb IT a z nich vyplývajících doporučení. Za pomoci jednotlivých managementů nabízí systematický přístup k nalézání, plánování, dodávce a podpoře IT služeb (klient VS, interní zadavatel/klíčový uživatel). Svými oblastmi pokrývá celý životní cyklus služeb v částech Service Strategy, Service Design, Service Transition, Service Operation a Continual Service Improvement. Řídit služby dle ITIL tedy znamená zejména nastavit procesy a připravit systémovou podporu. Efektivní řízení ICT služeb dle ITIL (SLM) a vyhodnocování jejich SLA vyžaduje existenci tzv. runtime model služby neboli servisní strom služby.
Řádek 338: Řádek 338:
 Metodickým a znalostním základem IK OVS je individuální model stávající a cílové architektury úřadu. Informační koncepce OVS je oficiálním (tzv. dodatelným) dokumentem pro výsledky práce architektura úřadu. Metodickým a znalostním základem IK OVS je individuální model stávající a cílové architektury úřadu. Informační koncepce OVS je oficiálním (tzv. dodatelným) dokumentem pro výsledky práce architektura úřadu.
  
-Další věcná a odborná doplnění, týkající se tvorby Informační koncepce OVS, budou po projednání s odbornou veřejnosti obsažena v následujících vydáních NAR a NAP, vydána jako metodické pokyny OHA a aktualizována ve Znalostní bázi.+Další věcná a odborná doplnění, týkající se tvorby Informační koncepce OVS, budou po projednání s odbornou veřejnosti obsažena v následujících vydáních NAR a NAP, vydána jako metodické pokyny OHA a aktualizována ve [[:znalostni_baze|Znalostní bázi]].
  
 ==== Další metody strategického řízení ICT ==== ==== Další metody strategického řízení ICT ====
  
-Další metody strategického plánování a řízení ICT útvaru, vedle architektury úřadu a IK OVS, budou po projednání s odbornou veřejnosti obsaženy v následujících vydáních MŘICT a aktualizovány ve Znalostní bázi. +Další metody strategického plánování a řízení ICT útvaru, vedle architektury úřadu a IK OVS, 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]]
  
 ==== Plán realizace změn (Roadmapa) ==== ==== Plán realizace změn (Roadmapa) ====
Řádek 354: Řádek 354:
 Pro správný chod služeb ICT a útvaru ICT je řízení změn klíčové. Změna je velkým hybatelem, který ovlivňuje celé ICT prostředí a organizaci samotnou. Základem je řízení očekávání resp. požadavků. Ve velké většině mohou být právě požadavky realizovány formou změny. Jak již bylo výše naznačeno, změna sjednocuje metodiku ITIL, který řídí spíše provoz a rozvoj stávajících služeb a TOGAF, který se soustřeďuje na nové služby, resp. je i vhodné ho využívat v kombinaci s ITIL přístupem na velké změny v rámci stávajících služeb. Pro správný chod služeb ICT a útvaru ICT je řízení změn klíčové. Změna je velkým hybatelem, který ovlivňuje celé ICT prostředí a organizaci samotnou. Základem je řízení očekávání resp. požadavků. Ve velké většině mohou být právě požadavky realizovány formou změny. Jak již bylo výše naznačeno, změna sjednocuje metodiku ITIL, který řídí spíše provoz a rozvoj stávajících služeb a TOGAF, který se soustřeďuje na nové služby, resp. je i vhodné ho využívat v kombinaci s ITIL přístupem na velké změny v rámci stávajících služeb.
  
-Všechny výše uvedené postupy je třeba jednotně definovat, včetně rolí a odpovědností. Dobré praxe a rozpracované metody přístupu kombinace ITIL a TOGAF budou součástí detailní metodiky, která toto téma rozpracuje detailněji včetně předloh a schémat ve [[:start|Znalostní bázi]]. +Všechny výše uvedené postupy je třeba jednotně definovat, včetně rolí a odpovědností. Dobré praxe a rozpracované metody přístupu kombinace ITIL a TOGAF budou součástí detailní metodiky, která toto téma rozpracuje detailněji včetně předloh a schémat ve [[:znalostni_baze|Znalostní bázi]]. 
  
 Dále třeba uvést definičně a ideově do kontextu RFC a IT architekturu. Zkratka RFC, pocházející z anglického názvu „Request for change“, reprezentuje v prostředí úřadu požadavek na změnu. RFC v kontextu řízení architektury je požadavek na změnu mající dopad do jednoho nebo více architektonických oborů. Dále třeba uvést definičně a ideově do kontextu RFC a IT architekturu. Zkratka RFC, pocházející z anglického názvu „Request for change“, reprezentuje v prostředí úřadu požadavek na změnu. RFC v kontextu řízení architektury je požadavek na změnu mající dopad do jednoho nebo více architektonických oborů.
Řádek 381: Řádek 381:
 Nejběžnější variantou obsluhy požadavků je ServiceDesk. Snahou ICT útvaru by mělo být všemi dostupnými nástroji donutit aktéry a procesy zadávat své požadavky právě zde. Organizačně a zdrojově je to nejméně náročný způsob obsluhy požadavků. Jak již bylo uvedeno výše, je dobrá úroveň obsluhy požadavků základem vzrůstající kvality ICT služeb a spokojenosti jejich klientů a uživatelů. Nejběžnější variantou obsluhy požadavků je ServiceDesk. Snahou ICT útvaru by mělo být všemi dostupnými nástroji donutit aktéry a procesy zadávat své požadavky právě zde. Organizačně a zdrojově je to nejméně náročný způsob obsluhy požadavků. Jak již bylo uvedeno výše, je dobrá úroveň obsluhy požadavků základem vzrůstající kvality ICT služeb a spokojenosti jejich klientů a uživatelů.
  
-Další logickou částí je obsluha požadavku. Obecně se dá konstatovat, že obsluhu a koordinaci většiny požadavků zvládá, ze své podstaty, ServiceDesk (dále jen „SD“) resp. funkce HelpDesk a obsluhující role SD. V rámci těchto aktivit lze plně využít jak technické nástroje SD tak best-practices ITILu. Pro požadavky projektové může sloužit nástroj PPM (Project Portfolio Management) a metodicky pak best-practices oboru jako PRINCE 2 apod.+Další logickou částí je obsluha požadavku. Obecně se dá konstatovat, že obsluhu a koordinaci většiny požadavků zvládá, ze své podstaty, ServiceDesk (také jako „SD“) resp. funkce HelpDesk a obsluhující role SD. V rámci těchto aktivit lze plně využít jak technické nástroje SD tak best-practices ITILu. Pro požadavky projektové může sloužit nástroj PPM (Project Portfolio Management) a metodicky pak best-practices oboru jako PRINCE 2 apod.
  
 Pro zvýšení transparentnosti přípravy nových služeb OVS a jeho rezortu a za účelem zefektivnění výsledných řešení je vhodné pří budování nových služeb využívat pilotních projektů s možností zapojení odborné veřejnosti do návrhu a testování konceptů řešení, a tak ověřovat potřebnost, vhodnost, funkcionality a další aspekty navrhovaných řešení. Tento postup poskytuje uživatelům možnost otestovat služby a funkcionality již v době jejich návrhu, a zároveň 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ů VS podchytit již v počátku a zapracovat do koncepce řešení nově připravované služby. Další nesporným přínosem realizace ověřovacích projektů je upřesnění požadavků na cílové řešení a očekávané funkcionality. V rámci případných veřejných zakázek na dodávku celých anebo částí služeb již lze poptávat přesnou množinu jasně definovaných funkcionalit. Minimalizuje se tak riziko, že budou neefektivně požadovány v budoucnu nevyužívané funkcionality a riziko vznesení velkého počtu změnových požadavků na optimalizace či přizpůsobení využívaných služeb. Pro zvýšení transparentnosti přípravy nových služeb OVS a jeho rezortu a za účelem zefektivnění výsledných řešení je vhodné pří budování nových služeb využívat pilotních projektů s možností zapojení odborné veřejnosti do návrhu a testování konceptů řešení, a tak ověřovat potřebnost, vhodnost, funkcionality a další aspekty navrhovaných řešení. Tento postup poskytuje uživatelům možnost otestovat služby a funkcionality již v době jejich návrhu, a zároveň 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ů VS podchytit již v počátku a zapracovat do koncepce řešení nově připravované služby. Další nesporným přínosem realizace ověřovacích projektů je upřesnění požadavků na cílové řešení a očekávané funkcionality. V rámci případných veřejných zakázek na dodávku celých anebo částí služeb již lze poptávat přesnou množinu jasně definovaných funkcionalit. Minimalizuje se tak riziko, že budou neefektivně požadovány v budoucnu nevyužívané funkcionality a riziko vznesení velkého počtu změnových požadavků na optimalizace či přizpůsobení využívaných služeb.
  
-Podrobnější informace, návody, postupy a pomůcky budou po projednání s odbornou veřejností vydány jako samostatný metodický dokument a jako průběžně aktualizovaná součást Znalostní báze.+Podrobnější informace, návody, postupy a pomůcky budou po projednání s odbornou veřejností vydány jako samostatný metodický dokument a jako průběžně aktualizovaná součást [[:znalostni_baze|Znalostní báze]].
  
 ==== Řízení projektů a programů úřadu ==== ==== Řízení projektů a programů úřadu ====
Řádek 400: Řádek 400:
   * koordinované využití ostatních materiálních a majetkových zdrojů úřadu, jako jsou společné prostory, výpočetní kapacity, dostupný čas pro odstávky a výpadky apod.   * koordinované využití ostatních materiálních a majetkových zdrojů úřadu, jako jsou společné prostory, výpočetní kapacity, dostupný čas pro odstávky a výpadky apod.
  
-Koordinace projektů, jejich provazování do programů a správa portfolií projektů je službou Projektové kanceláře úřadu (dále také jen PK(( V angličtině Project Management Office - PMO. +Koordinace projektů, jejich provazování do programů a správa portfolií projektů je službou Projektové kanceláře úřadu (také jako "PK"(( V angličtině 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 (dále jen AK). Oba tvary společně by měly být přednostně součástí tzv. „štábu“ vedení úřadu.+))). Navazuje na práci strategických útvarů a je znalostně podpořena službami útvaru celkové architektury úřadu, architektonické kanceláře (také jako "AK"). Oba tvary společně by měly být přednostně součástí tzv. „štábu“ vedení úřadu.
  
 V druhé, nižší úrovni, již výhradně pro ICT projekty probíhá tato koordinace a řízení v útvarech řízení projektů, strategie a IT architektury uvnitř útvaru ICT úřadu. V druhé, nižší úrovni, již výhradně pro ICT projekty probíhá tato koordinace a řízení v útvarech řízení projektů, strategie a IT architektury uvnitř útvaru ICT úřadu.
  
-Další věcná a odborná doplnění k celé problematice řízení projektů a programů budou po projednání s odbornou veřejnosti obsažena v následujících vydáních MŘICT a aktualizována ve Znalostní bázi.+Další věcná a odborná doplnění k celé problematice řízení projektů a programů budou po projednání s odbornou veřejnosti obsažena v následujících vydáních MŘICT a aktualizována ve [[:znalostni_baze|Znalostní bázi]].
  
 === Kategorizace programů a projektů === === Kategorizace programů a projektů ===
Řádek 467: Řádek 467:
 V situaci, kdy plánované změny v úřadu a v jeho ICT vedou na více programů a projektů, než jaké jsou dostupné finanční, lidské a materiální zdroje úřadu, musí být prokazatelně uplatněn proces tzv. prioritizace projektů. A to nejméně jednou ročně, v souvislosti s plánováním rozpočtu, nebo kdykoli, kdy souběžně spuštěné nebo plánované projekty narazí na limity zdrojů úřadu. Proces prioritizace spočívá v rozdělení dostupných zdrojů a jejich přidělení pouze projektům, představujícím nejvyšší příspěvek k naplnění cílů úřadu nebo nezbytným dle legislativních změn. Projekty, které díky své aktuálně nižší prioritě nedosáhnou na zdroje úřadu, nebudou spuštěny nebo budou zastaveny do doby, dokud se nezvýší jejich priority nebo se nezvýší dostupné projektové zdroje úřadu. Popsaný proces je v gesci projektové kanceláře úřadu. Projektová kancelář musí být informována o všech projektech od okamžiku zahájení předprojektové přípravy. V situaci, kdy plánované změny v úřadu a v jeho ICT vedou na více programů a projektů, než jaké jsou dostupné finanční, lidské a materiální zdroje úřadu, musí být prokazatelně uplatněn proces tzv. prioritizace projektů. A to nejméně jednou ročně, v souvislosti s plánováním rozpočtu, nebo kdykoli, kdy souběžně spuštěné nebo plánované projekty narazí na limity zdrojů úřadu. Proces prioritizace spočívá v rozdělení dostupných zdrojů a jejich přidělení pouze projektům, představujícím nejvyšší příspěvek k naplnění cílů úřadu nebo nezbytným dle legislativních změn. Projekty, které díky své aktuálně nižší prioritě nedosáhnou na zdroje úřadu, nebudou spuštěny nebo budou zastaveny do doby, dokud se nezvýší jejich priority nebo se nezvýší dostupné projektové zdroje úřadu. Popsaný proces je v gesci projektové kanceláře úřadu. Projektová kancelář musí být informována o všech projektech od okamžiku zahájení předprojektové přípravy.
  
-Více informací a pravidel k řízení portfolií IT projektů, včetně vazeb na řízení lidských zdrojů, vydá MV ČR ve formě aktualizace Metodiky řízení IT projektů a rozmanitých akcelerátorů ve Znalostní bázi.+Více informací a pravidel k řízení portfolií IT projektů, včetně vazeb na řízení lidských zdrojů, vydá MV ČR ve formě aktualizace Metodiky řízení IT projektů a rozmanitých akcelerátorů ve [[:znalostni_baze|Znalostní bázi]].
  
 === Řízení jednotlivých IT projektů === === Řízení jednotlivých IT projektů ===
  
-Řízení jednotlivých projektů ICT, podrobněji viz [[metody-dokument:rizeni_jednotlivych_ict_reseni|Řízení jednolitých ICT řešení]], musí být centrálně koordinováno jak z pohledu „malé“ projektové kanceláře útvaru ICT, tak PK úřadu a nakonec i z pohledu budoucí centrální PK státu, resp. eGovernmentu, jakmile bude zřízena.+Řízení jednotlivých projektů ICT, podrobněji viz [[metody_dokument:rizeni_jednotlivych_ict_reseni|Řízení jednolitých ICT řešení]], musí být centrálně koordinováno jak z pohledu „malé“ projektové kanceláře útvaru ICT, tak PK úřadu a nakonec i z pohledu budoucí centrální PK státu, resp. eGovernmentu, jakmile bude zřízena.
  
 ==== Realizace malých změn - průběžné zlepšování ==== ==== Realizace malých změn - průběžné zlepšování ====
Řádek 477: Řádek 477:
 V mnohých případech se to děje, ale není doporučeno, aby realizaci drobných, resp. malých změn řídil Change Manager. V případě malých změn je vhodnější tzv. koordinace, kdy exekuci provádí Koordinátor změny. V případě prosté koordinace nemá daná řídící role změny tolik formálních povinností v oblasti dokumentace a řízení jako role projektového vedoucího, a ve většině koordinuje i více změn a reportuje ve většině stručněji na úrovni operačního řízení provozu v jistých případech to bývá i úroveň projektově-rozvojová. V mnohých případech se to děje, ale není doporučeno, aby realizaci drobných, resp. malých změn řídil Change Manager. V případě malých změn je vhodnější tzv. koordinace, kdy exekuci provádí Koordinátor změny. V případě prosté koordinace nemá daná řídící role změny tolik formálních povinností v oblasti dokumentace a řízení jako role projektového vedoucího, a ve většině koordinuje i více změn a reportuje ve většině stručněji na úrovni operačního řízení provozu v jistých případech to bývá i úroveň projektově-rozvojová.
  
-Řízení změn bude doplněno po projednání s odbornou veřejností a publikováno  v následujících vydáních MŘICT a ve Znalostní bázi.+Řízení změn bude doplněno po projednání s odbornou veřejností a publikováno  v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].
  
 ===== Řízení provozu IS a dodávky služeb ===== ===== Řízení provozu IS a dodávky služeb =====
Řádek 483: Řádek 483:
 ==== Řízení podpory klientů a uživatelů ICT služeb ==== ==== Řízení podpory klientů a uživatelů ICT služeb ====
  
-Řízení podpory klientů a uživatelů ICT služeb bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve Znalostní bázi.+Řízení podpory klientů a uživatelů ICT služeb bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].
  
 ==== Řízení provozu výpočetních a komunikačních technologií ==== ==== Řízení provozu výpočetních a komunikačních technologií ====
Řádek 491: Řádek 491:
 V prostředí OVS a jeho rezortu by měl být postupně zaveden přístup k definici smluvních parametrů služeb v tzv. katalogových listech služeb. Základní myšlenkou přístupu je, že služby jsou poskytovány prostřednictvím jednoho či více rozhraní a každé rozhraní je klasifikováno významem dle kategorií „Gold“, „Silver“ a „Bronz“. Pro jednotlivé kategorie služeb pak lze vytvořit sdílené katalogové listy a aplikačně specifické služby řešit v případě potřeby v rámci stručných specializovaných katalogových listů. Tento přístup lze aplikovat při přípravě libovolných zakázek s charakterem dodávek služeb provozu a podpory. V prostředí OVS a jeho rezortu by měl být postupně zaveden přístup k definici smluvních parametrů služeb v tzv. katalogových listech služeb. Základní myšlenkou přístupu je, že služby jsou poskytovány prostřednictvím jednoho či více rozhraní a každé rozhraní je klasifikováno významem dle kategorií „Gold“, „Silver“ a „Bronz“. Pro jednotlivé kategorie služeb pak lze vytvořit sdílené katalogové listy a aplikačně specifické služby řešit v případě potřeby v rámci stručných specializovaných katalogových listů. Tento přístup lze aplikovat při přípravě libovolných zakázek s charakterem dodávek služeb provozu a podpory.
  
-Řízení provozu výpočetních a komunikačních technologií na úrovni celého úřadu bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve Znalostní bázi.+Řízení provozu výpočetních a komunikačních technologií na úrovni celého úřadu bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].
  
 ==== Monitoring provozu a služeb ICT  ==== ==== Monitoring provozu a služeb ICT  ====
Řádek 497: Řádek 497:
 Každý systém, aplikace či služby musí být navrženy a implementovány tak, aby je bylo možné začlenit do dohledového systému OVS a dané rezortní organizace. Monitoring systém musí pokrývat metriky, jež jsou v provozních smlouvách (SLA) označeny jako automaticky monitorované a monitorovat tyto metriky v souladu s postupy a parametry v provozních smlouvách definovanými. Mimo takto označených metrik musí monitoring sledovat a vyhodnocovat další metriky obvyklé pro daný typ systému či aplikace. Každý systém, aplikace či služby musí být navrženy a implementovány tak, aby je bylo možné začlenit do dohledového systému OVS a dané rezortní organizace. Monitoring systém musí pokrývat metriky, jež jsou v provozních smlouvách (SLA) označeny jako automaticky monitorované a monitorovat tyto metriky v souladu s postupy a parametry v provozních smlouvách definovanými. Mimo takto označených metrik musí monitoring sledovat a vyhodnocovat další metriky obvyklé pro daný typ systému či aplikace.
  
-Detailní metodiky a technický návrh týkající se nástrojů monitoringu budou doplněny po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve Znalostní bázi.+Detailní metodiky a technický návrh týkající se nástrojů monitoringu budou doplněny po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].
  
 ===== Řízení rizik a bezpečnosti v ICT útvaru ===== ===== Řízení rizik a bezpečnosti v ICT útvaru =====
Řádek 507: Řádek 507:
 ==== Řízení rizik v ICT útvaru ==== ==== Řízení rizik v ICT útvaru ====
  
-Jakmile útvar ICT dostane úkol přesahující čerpání stávajících zdrojů, měl by alespoň před zahájením úkolu projít mapu rizik, která když je správně vyplněnáslouží pro řízení jako kontrolní prvek. V mapě rizik musí být nejen oblasti působnosti, ale především skutečný elementární rozpad rizik, která mohou ohrozit pozastavení nebo zrušení úkolu. Mezi hlavní neopomíjená rizika patří finanční, organizační, politická, legislativní a provozní. Každé riziko má svého vlastníka a své vlastní opatření eskalace pro jeho zmírnění nebo úplné zrušení. Dále je nutné riziko pojmenovat, vysvětlit a určit jeho významnost určující dopady. Z rizik musí vzniknout zároveň samostatný soupis, který se stává nedílnou součástí dokumentace.+Jakmile útvar ICT dostane úkol přesahující čerpání stávajících zdrojů, měl by alespoň před zahájením jeho plnění provést analýzu rizik a vytvořit mapu rizik, která – když je správně vyplněná – slouží pro celé řízení jako kontrolní prvek.
  
-Vedle řízení rizik na úrovni jednotlivých IS, jejich návrhu, vývoje a provozu, viz také kapitola 4.3.4.2.1, spočívá těžtě řízení rizik a bezpečnosti činnostech na úrovni celého úřadu, realizovaných útvarem informatiky ve spolupráci s dalšími bezpečnostními strukturami úřadu, jako jsou fyzická bezpečnost, Pověřenec pro GDPR, BOZP apod., viz kapitola 6.3.+Mapa rizik by měla mimo oblast působnosti zohledňovat rizika z jiných oblastí, která mohou způsobit pozastavení nebo zrušení úkolu. Mezi hlavní rizikové oblasti lze řadit: 
 +  * oblast kybernetické bezpečnosti 
 +  * oblast finanční 
 +  * oblast organizační  
 +  * oblast politickou (zohlednění případných politických rozhodnutí ovlivňujících splnění úkolu) 
 +  * oblast legislativní (zohlednění případné změny právních předpisů a jejich výkladu ovlivňujících splnění úkolu) 
  
-Pro hodnocení rizik lze využít metodiku vydanou NÚKIB, tvořenou hlavními aktivitami:+Jednotlivá rizika je nutné pojmenovat a odůvodnit jejich relevanci k danému úkolu. Následně musí být provedeno jejich zhodnocení za účelem stanovení způsobu jejich mitigace v rámci procesu řízení rizik.  
 + 
 +Každé riziko má svého vlastníka, tedy osobu nebo entitu s odpovědností a pravomocí riziko řídit a opatření, která lze přijmout za účelem jeho zmírnění či úplného zrušení. Úroveň opatření přijatých za účelem mitigace rizik by měla být v souladu s výsledkem hodnocení rizik. V tomto ohledu je nutné si však uvědomit, že dosažení 100% eliminace veškerých rizik není možné ani při neomezených zdrojích. Je tak věcí vedení organizace, aby stanovilo přijatelnou úroveň rizika a zajistilo prostředky (nejen finanční, ale i personální, kompetenční atd.) nutné pro její dosažení.  
 + 
 +Pro optimální účinnost potlačování rizik je vhodná kombinace technických a organizačních opatření. Na většinu rizik je přitom nutné pamatovat již před samotnou realizací daného úkolu či v rámci přípravy smluvní dokumentace s dodavateli.  
 + 
 +Vedle řízení rizik na úrovni jednotlivých IS, jejich návrhu, vývoje a provozu, viz také [[metody_dokument:rizeni_jednotlivych_ict_reseni|Řízení jednolitých ICT řešení]], spočívá těžiště řízení rizik a bezpečnosti v činnostech na úrovni celého úřadu, realizovaných útvarem informatiky ve spolupráci s dalšími bezpečnostními strukturami úřadu, jako jsou fyzická bezpečnost, Pověřenec pro GDPR, BOZP apod., viz [[metody_dokument:spoluprace_s_ostatnimi_utvary_uradu_a_egovernmentu|Spolupráce s ostatními útvary úřadu a eGovernmentu]]. 
 + 
 +Pro hodnocení rizik z oblasti kybernetické bezpečnosti lze využít [[https://www.nbu.cz/download/bezpecnost-informacnich-systemu/DokumentaceIS-vzor.pdf|metodiku vydanou NÚKIB]], tvořenou hlavními aktivitami:
  
   * Mapování a evidence aktiv   * Mapování a evidence aktiv
Řádek 520: Řádek 533:
   * Kontroly a audity   * Kontroly a audity
  
-Tuto metodiku bude dobré provázat s metodami řízení rizik z projektových standardů (PMI, Prince2) a rámce TOGAF, společně s řízení finančních rizik apod. tak, aby mohly všechny společně přispívat do jednotného registru a procesů řízení všech rizik na úrovni úřadu.+Tuto metodiku bude dobré provázat s metodami řízení rizik z projektových standardů (PMI, Prince2) a rámce TOGAF, společně s řízení finančních rizik apod. tak, aby mohly všechny společně přispívat do jednotného registru a procesů řízení všech rizik na úrovni úřadu. MŘICT podporuje při snížení či eliminaci rizik [[https://www.nukib.cz/cs/kyberneticka-bezpecnost/regulace-a-kontrola/podpurne-materialy/|doporučení a metodické materiály tvořené NÚKIB]]: 
 +  * {{https://nukib.cz/download/publikace/podpurne_materialy/minimalni-bezpecnostni-standard_v1.2.pdf|Minimální bezpečnostní standard}}  
 +  * {{https://nukib.cz/download/publikace/podpurne_materialy/Standard%20pro%20VTC_1.1.pdf|Bezpečnostní standard pro videokonference}} 
 +  * {{https://nukib.cz/download/publikace/podpurne_materialy/Metodika_k_voditkum_pro_hodnoceni_dopadu_NUKIB_v.1.2_s_prilohou.pdf|Vodítka pro hodnocení dopadů}}
  
-Ilustrativní příloha mapy rizik včetně legendy, podpůrných otázek a měření dopadů a další věcná a odborná doplnění budou publikována po projednání s odbornou veřejností v následujících vydáních MŘICT a ve Znalostní bázi.+Přílohy typu mapy rizik včetně legendy, podpůrných otázek a měření dopadů a další věcná a odborná doplnění budou publikována po projednání s odbornou veřejností v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].
  
 ==== Řízení ICT bezpečnosti ==== ==== Řízení ICT bezpečnosti ====
  
-Nezbytnou součástí dlouhodobě udržitelného provozu a rozvoje ICT daného OVS je prosazení kybernetické (informační) bezpečnosti. Za tímto účelem musí každý OVS implementovat stabilizovaný systém řízení bezpečnosti informací dle ZoKB a standardu ČSN ISO/IEC 27001:2006. V rámci tohoto systému nadále pokračuje zajištění bezpečnosti IS zařazených do ISVS prostřednictvím provozu a zlepšování systému řízení bezpečnosti informací. Dále by měl být kladen důraz na vyšší zapojení organizačních celků OVS do bezpečnostních činností, zefektivnění dohledových a monitorovacích činností a prohloubení zajištění bezpečnosti IS daného OVS.+Nezbytnou součástí dlouhodobě udržitelného provozu a rozvoje ICT daného OVS je prosazení kybernetické (informační) bezpečnosti. Za tímto účelem musí každý OVS implementovat stabilizovaný systém řízení bezpečnosti informací dle ZoKB a standardu ČSN ISO/IEC 27001:2013. V rámci tohoto systému nadále pokračuje zajištění bezpečnosti IS zařazených do ISVS prostřednictvím provozu a zlepšování systému řízení bezpečnosti informací. Dále by měl být kladen důraz na vyšší zapojení organizačních celků OVS do bezpečnostních činností, zefektivnění dohledových a monitorovacích činností a prohloubení zajištění bezpečnosti IS daného OVS.
  
 Provoz a bezpečnost jsou propojeny díky několika aspektům. Je to primárně dostupnost, kdy bezpečnost stejně jako provoz zajímá dostupnost systému. V mnoha ohledech lze vzájemně využívat informace z monitoringových nástrojů. Provoz a bezpečnost jsou propojeny díky několika aspektům. Je to primárně dostupnost, kdy bezpečnost stejně jako provoz zajímá dostupnost systému. V mnoha ohledech lze vzájemně využívat informace z monitoringových nástrojů.
Řádek 552: Řádek 568:
 ==== Správa celkového portfolia služeb  ==== ==== Správa celkového portfolia služeb  ====
  
-Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve Znalostní bázi.+Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].
  
 ==== Správa aplikačního portfolia  ==== ==== Správa aplikačního portfolia  ====
  
-Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve Znalostní bázi.+Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].
  
 ==== Správa technologického portfolia ==== ==== Správa technologického portfolia ====
  
-Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve Znalostní bázi.+Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].
  
 ==== Správa datových fondů OVS ==== ==== Správa datových fondů OVS ====
  
-Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve Znalostní bázi.+Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].
  
 ==== Odlišný přístup k pořizování a správě ICT komodit ==== ==== Odlišný přístup k pořizování a správě ICT komodit ====
  
-Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve Znalostní bázi.+Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].
  
 ===== Přístup k nepřímému řízení a dohledu na informatizaci (governance) ===== ===== Přístup k nepřímému řízení a dohledu na informatizaci (governance) =====
  
-Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve Znalostní bázi.+Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].
  
 ==== Zavedení řízení kvality služeb ==== ==== Zavedení řízení kvality služeb ====
  
-Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve Znalostní bázi.+Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].
  
 ==== Reporting pro management a governance ICT  ==== ==== Reporting pro management a governance ICT  ====
  
-Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve Znalostní bázi.+Bude doplněno po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].
  
 ==== ICT Controlling a benchmarking ==== ==== ICT Controlling a benchmarking ====
Řádek 596: Řádek 612:
   -Rozvoj **controllingu** ICT služeb veřejné správy.   -Rozvoj **controllingu** ICT služeb veřejné správy.
  
-Další informace o controllingu a benchmarkingu ICT budou po projednání s odbornou veřejností a publikovány v následujících vydáních MŘICT a ve Znalostní bázi.+Další informace o controllingu a benchmarkingu ICT budou po projednání s odbornou veřejností a publikovány v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].
  
 ===== Standardizace v řízení ICT  ===== ===== Standardizace v řízení ICT  =====
  
-Rozsáhlá a náročná kapitola o standardizaci v ICT bude doplněna po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve Znalostní bázi.+Rozsáhlá a náročná kapitola o standardizaci v ICT bude doplněna po projednání s odbornou veřejností a publikováno v následujících vydáních MŘICT a ve [[:znalostni_baze|Znalostní bázi]].