Funkční a nefunkční požadavky ISVS

Toto je metodické doporučení obsahující návody ke správě funkčních a nefunkčních požadavků na ISVS požadavků na informační systémy veřejné správy (dále „ISVS“), dalších informačních systémů (dále „IS“) a služeb, které jsou jimi poskytovány, včetně možnosti pořízení cloudových služeb (SaaS, PaaS, IaaS). Dokument dále obsahuje vzorový seznam funkčních a nefunkčních požadavků a základní kategorizace systému.

Dokument a přílohy byly zpracovány v rámci úkolů z dílčího cíle č. 2.8 uvedeném v Informační koncepci České republiky (dále jen IKČR) a navazuje jak na metodiky k veřejným zakázkám, tak na další dokumenty týkající se informačních systémů veřejné správy.

Pro účely tohoto dokumenty se následujícími pojmy dále myslí:

Správa informačního systému je jeho vytvoření, nákup, zavedení, provozování, rozšíření, obnova, rozvoj, podpora, údržba, ukončení, tj. celý životní cyklus systému.

ICT řešení je souhrn prostředků z pohledu informačních a komunikačních technologií (z čehož plyne zkratka ICT), které poskytují podporu běhu úřadu. Těmito prostředky jsou ISVS, provozní IS, další IS, služby, cloudové služby a jejich případná kombinace.

Úřadem se rozumí orgán veřejné správy ve smyslu zákona č. 365/2000 Sb., o informačních systémech veřejné správy.

Uživatel ICT řešení je ten, kdo dané ICT řešení používá pro svoji práci, za účelem přímé, či nepřímého poskytování služby klientovi, kde klientem může být i on sám. Příkladem je pracovník veřejné správy, který pracuje s daným ICT řešením v asistovaném přepážkovém styku na Czech POINTu.

Klient ICT řešení nebo zákazník, je koncovým konzumentem služby. Příkladem je občan, jenž využívá portál Občana pro elektronické podání daňového přiznání.

Ve veřejné správě je naprostá většina činností vykonávána s podporou ICT řešení. Ať už se jedná o informační systémy veřejné správy, nebo takzvané provozní informační systémy, je jejich pořizování, rozvoj, provozování, správa a vyhodnocování regulováno příslušnou legislativou. Jedná se zejména o zákon č. 365/2000 Sb., o informačních systémech veřejné správy a na něj navazující prováděcí právní předpisy. Pro oblast pořizování a rozvoj informačních systémů ve veřejné správě je klíčová také legislativa k zadávání veřejných zakázek, neboť v naprosté většině případů se pořízení, rozvoj a provozování informačního systému realizuje formou veřejné zakázky.

Tento materiál a související přílohy mají sloužit jako návod pro správce ICT řešení- informačních systémů a odborné útvary v úřadech zabývající se rozvojem ICT řešení. Prostřednictvím zde předložených metodických doporučení, návodů, postupů a vzorových seznamů požadavků by měly být tyto útvary schopny ve spolupráci s dalšími odbornými útvary příslušného veřejného zadavatele kvalifikovaným způsobem připravit správně koncipovanou zadávací dokumentaci pro veřejnou zakázku na pořízení či rozvoji příslušného ICT Řešení (informačního systému, ať už se jedná o nový informační systém pro podporu výkonu konkrétních agend veřejné správy, nebo provozní informační systém úřadu). Dále by měl, poskytnou návod, jak v dnešním více propojeném prostředí spravovat ICT řešení a zajistit jejich integraci. A to i v podmínkách rozvíjející se kontejnerizace a cloudového prostředí kdy systémy nejde rozvíjet izolovaně.

Dále tento dokument poskytuje návody pro realizaci komplexní schopnosti správy požadavků na ICT řešení. To se týká samotného pořizování, sběru a projednávání, schvalování a verifikace jednotlivých funkčních a nefunkčních požadavků, ale také obecných procesů správy těchto požadavků a jednotné evidence požadavků. S využitím jednotné správy funkčních a nefunkčních požadavků na informační systémy (nebo služby), které vycházejí z věcného zadání, například tzv. procesních požadavků a dalších prvků byznys architektury úřadu, bude pak možno naplnit jeden z nových principů stanovených v Informační koncepci České republiky, a to tvorba procesně orientovaných informačních systémů ve veřejné správě.

Tento dokument a jeho související materiály jsou určeny zejména těm, kteří mají u veřejných zadavatelů na starosti definici procesu na přípravu a realizaci veřejných zakázek týkajících se zejména ICT řešení (informačních systémů, informačních technologií a jejich společných komponent). Jedná se o metodický dokument a soubor návodných seznamů pro to, aby zejména u veřejných zadavatelů, kteří jsou správci informačních systémů veřejné správy, bylo možno zavést standardizovaný a jednoduchý proces sběru, porovnávání, projednávání a schvalování, evidence a vyhodnocování a následné realizace požadavků na jednotlivé IS a komponenty. Ať už tyto požadavky budou realizovány formou veřejné zakázky (dodavatelské dílo), nebo formou vlastního vývoje (z vlastní činnosti), čí kombinací, je vhodné vzít zde uvedené principy a požadavky jako základ při vytváření funkčních a nefunkčních požadavků a jejich správu.

Tato metodika by měla též posloužit jako součást přípravy variantních řešení pro pořízení nebo obnovu informačních systémů, služeb a ICT řešení. Dále by měla metodika sloužit jako podklad pro ekonomickou analýzu úpravy zadávacích podmínek, například i v oblasti nastavení stropové ceny.

Tato metodika s přihlédnutím k současným smluvně technickým a dalším podmínkám je použitelná na obměnu nebo rozvoj současných systémů či ICT řešení. V mnohých případech nebyly realizovány kroky (analytické části této metodiky aj.), které jsou vyžadovány touto metodikou.

Vlastníci ICT řešení mají k dispozici následující základní varianty, jak se po byznys analýze rozhodnout:

1. ICT řešení bude ukončeno a nemá cenu provádět analýzu v plném rozsahu, protože samotné náklady na analýzu jsou větší než zbytkové užití ICT řešení. (V tomto případě pak aplikovat část této metodiky na ukončování provozu informačního systému či ICT řešení). Takovéto případy se vyskytují jen zřídka.
2. ICT řešení bude provozován nadále, pak se provedou analytické kroky, které jsou zde popsány. A následně se aplikuje metodika na obnovu ICT řešení. Rozhodne se dle analýzy (jejíž součástí je tato metodika) k Provozování ICT řešení, v současné podobě, tj. beze změny poskytovaných služeb. Samotná změna se však týká zefektivnění poskytování těchto služeb, zejména modernizace provozních prostředků, tj. obměny a obnovy.
3. Rozvoj stávajícího ICT řešení podle požadavků
   1. eGovernmentu,
   2. věcného správce agendy,
   3. zákonných požadavků,
4. Pořízení nového ICT řešení. Řešení dosavadní bude ukončeno.
5. Žádné požadavky na změnu nevznikly (tato varianta se vyskytuje téže zřídka)

Oprava/y těchto nedostatků, co se týče analytických části prací, sebou přinese přidanou hodnotu v podobě rozdílů stavů „as is“ a „to be“ které měly být implementovány a nejsou. Při zvolení varianty bodu 2), v některých případech, bude díky neoptimálnímu a nevýhodnému stavu technologicko-dodavatelských vztahů možno řešit navrhované požadavky v plné míře. V případě migrace ze současného ICT řešení, v případě varianty bodu 3), též požadavky na současné ICT řešení, ze kterého bude prováděna migrace, nebude možno uplatnit navrhované požadavky v plné míře. Ovšem úkolem řádného hospodáře je se k tomuto stavu přiblížit v co nejbližší míře. V případě nových ICT řešení je už možno plně navrhované požadavky dodržet.

Tento dokument jako celek souvisí pochopitelně s dalšími dokumenty, a to zejména s těmi to:

• Metodiky k veřejným zakázkám publikované na Portálu veřejných zakázek¹⁾
• Informační koncepce ČR: Realizuje dílčí cíl DC 2.8; napomáhá správcům informačních systémů veřejné správy realizovat některé zásady řízení ICT ve veřejné správě a principy architektury a rozvoje ISVS.
• Národní architektonický plán: Respektuje principy NAP a napomáhá k jejich realizaci, pokud jsou realizovány pořízením či rozvojem ISVS nebo jeho komponent.
• Národní architektonický rámec: představuje výchozí znalost jazyka pro řízení organizace pro modelování architektury úřadu
• Metody řízení ICT veřejné správy: V rámci metod a řízení informačních technologií ve veřejné správě jsou definovány principy a procesy pro jednotnou správu a evidenci požadavků na informační systémy a jejich komponenty. Tento dokument tyto principy a procesy rozpracovává a dále definuje vzorové sady požadavků na informační systémy, ať už budou pořízeny formou veřejné zakázky, nebo vlastním vývojem.
• Slovník e-Governmentu který zde používané pojmy standardizuje a sám do něj pojmy přesouvá

Při ukončení činnosti ICT řešení bez jeho náhrady je nutno zanalyzovat, zda opravdu neexistuje žádný požadavek na funkci, kterou bude správce dále potřebovat. Pokud ne, lze systém ukončit. Pak nastupují zejména požadavky na EXIT strategii a na ukončení činnosti IS a na řešení problematiky archivace údajů ISVS a následné jejich smazání. Pokud ano, správce zajistí, aby potřebná funkcionalita byla realizována jiným IS nebo jinou komponentou.

Obměna (změna po zhodnocení) IS je ve skutečnosti jednou z následujících:

1. Nahrazení stávajícího IS jiným řešením, nebo
2. Změny ve funkcích a rozvoj stávajícího IS

Při první variantě je nutno provést kompletní analýzy a sběr a zhodnocení požadavků na příslušný informační systém podle tohoto dokumentu a zajistit tak soulad zadávací dokumentace se zákonem, s povinnostmi eGovernmentu a s potřebami zadavatele. Při druhé variantě se před zadáním změnových požadavků provede analýza změny a provede se i úprava požadavků a jejich vazeb v procesu správy požadavků, jak jej popisuje tento dokument.

Zcela klíčovým okamžikem z pohledu správnosti požadavků je analýza před zadáním požadavků na nový informační systém anebo na zadání nových komponent. Mimochodem, nahrazuje-li se celé stávající ICT řešení novým řešením, jedná se ve skutečnosti o tvorbu zcela nového ICT řešení a pouze se využijí použitelné předchozí požadavky.

Pouze pokud se správně nadefinují požadavky hned na začátku (tedy v okamžiku přípravy a sběru požadavků na ICT řešení, bude možno ICT řešení dále rozvíjet s vysokou efektivitou.

V organizacích jež provozují ICT systémy, je nezbytné vést systém správy požadavků za účelem hospodárnosti a optimálního řízení kapacit ICT. Tento dokument poskytne návod jak systém správy požadavků v organizaci zavést.

Požadavky jsou nástrojem, jak podle standardizovaných inženýrských principů vydefinovat nutné a možné vlastnosti ICT řešení ve dvou základních rovinách:

1. Jaké služby má ICT řešení poskytovat (co má systém vykonávat), plnění funkce/funkcí – funkční požadavek.
2. V jaké kvalitě májí být služby poskytovány, tedy jak je konkrétní funkcionalita naplňována (v jakých podmínkách a s jakými parametry) – nefunkční požadavek.

Důležitost požadavků a smysl, proč se jimi aktivně zabývat (tj. organizace má definovanou kompetenční matici, kdy jsou vedena konkrétní zmocnění a odpovědnosti) je od expertního porozumění toho, čeho se chce dosáhnout pomocí nynějšího i budoucího, až po konečný podklad pro veřejnou zakázku pro dané ICT řešení.

Není pravdou, že čas věnovaný na sběr požadavků prodlužuje projekt, naopak je to nezbytně vynaložený čas, který povede ke zkrácení nutného času na úspěšnou realizaci.

Sběr požadavků je ustálená dobrá praxe. Co kvalitní a řádný sběr požadavků od začátku projektu přináší (Wiegers, 2013 p. xxvii):

• Redukuje náklady na vývoj, údržbu, zlepšování a podporu.
• Redukuje předělávky a maximalizuje produktivitu.
• Umožňuje dodání vysoce kvalitních produktů, které naplňují Business cíle.
• Umožňuje zamezovat a řídit rozšiřování obsahu a rozsahu projektu, tak aby byl dobře zacílen a pod kontrolou.
• Umožňuje dosáhnout vyššího uspokojení interních uživatelů a zákazníků veřejné správy, tedy občanů.

Špatné požadavky jsou v drtivé většině příčinou selhání očekávání při zavádění ICT řešení. Dále způsobují vysoce neudržitelný stav provozu ICT řešení, jak z pohledu ekonomického, tak i z pohledu uživatelského. Při zavádění nových ICT řešení může dojít k řadě chyb, které mají široké dopady.

Hlavním dopadem špatných požadavků jsou předělávky, velice často již ve fázi vývoje nebo po finální verzi. Díky tomuto předělávky často dosahují 30 % až 50 % vývojových nákladů, chyby v požadavcích často dělají 70 % až 85 % cen předělávek (oprava a vícepráce). Nedostatky, jež se stanou ve fázi sběru požadavků, způsobí 40 až 50 % chyb. Oprava chyb je mnohem levnější v raných etapách projektu, tedy ve strategii, plánu a přípravy (průřezově ve všech dílčích fází). V relativní škále, pakliže oprava chyby ve fázi formalizace požadavků stála 1000 Kč, při tvorbě designu oprava stojí již 1000 Kč a dále 2000 Kč až 3000 Kč na opravu již odvedené práce. Pakliže by si chyby všiml až uživatel, oprava chyby by stála 100 000 Kč. (Wiegers, 2013 p. 19)

Základní přehled etap pro řízení ICT

Legislativa klade nároky na odbornost a náležitou péči při definování požadavků na ICT řešení. S těmito nároky jsou spojené související právní dopady ve formě objektivní či subjektivní odpovědnosti za (způsobený) nežádoucí výsledný stav věci. Nežádoucí výsledný stav je obvykle způsoben protiprávním stavem, který muže vzniknout i nedbalostně např. opomenutím. Dopady jsou obvykle ve formě majetkové újmy obvyklé spojené s trestněprávními, správními či disciplinárními sankcemi.

Je nutno připomenout, že veškeré stanovování požadavků může být předmětem kontroly nadřízených, tak i věcně příslušných dozorových úřadů pro dané oblasti kontroly (např. NÚKIB pro soulad s kybernetickou bezpečností, ÚOOÚ v rámci ochrany osobních údajů, ÚOHS z hlediska zadávání veřejných zakázek a ochrany hospodářské soutěže atd.).

Špatným výběrem požadavků na ICT řešení je možno se dopustit chování, jež je v rozporu s právním řádem, tj. legislativním omezením (zákonem o zadávání veřejných zakázek, zákonem o finanční kontrole aj.). Veřejná správa a veřejní zadavatelé (Orgán veřejné moci) se mají chovat tak, aby stanovené požadavky představovaly vyvážení principu péče řádného hospodáře, resp. odborné péče, které ukládají maximálně hospodárné využití peněžních prostředků, na straně jedné, a požadavků na funkčnost, bezpečnost, způsobilost k zamýšlenému účelu a podobné vlastnosti poptávaného plnění na straně druhé.

Zákon o zadávání veřejných zakázek (zákon č. 134/2016 Sb.) svém § 6 stanovuje základní zásady, které je zadavatel povinen dodržet při zadávání veřejných zakázek. Těmito zásadami je zásada transparentnosti, přiměřenosti, rovného zacházení a zákazu diskriminace.

Nedodržení těchto zásad může vést k sankcím ze strany dozorového orgánu, kterým je ÚOHS. Ten může kromě uložení pokut za přestupky proti zákonu uložit i nápravná opatření spočívající ve zrušení zadávacího řízení, zákazu uzavření smlouvy, zákazu plnění smlouvy atd.

Hrubé porušení zákona v této oblasti může vést až trestněprávní odpovědnosti - může naplnit např. skutkovou podstatu trestného činu porušování povinností při správě cizího majetku (§§ 220 a 221 zákona č. 40/2009 Sb., trestního zákoníku, zneužití informace, resp. postavení v obchodním styku (§§ 255 a 255a trestního zákoníku), zjednání výhody při zadání veřejné zakázky, při veřejné soutěži a veřejné dražbě (§ 256 trestního zákoníku) nebo pletichy při zadání veřejné zakázky a při veřejné soutěži (§ 257 trestního zákoníku).

Požadavek na zajištění péče řádného hospodáře lze v kontextu zadávání veřejných zakázek obecně dovodit již ze samotné existence zákona o zadávání veřejných zakázek, který pro subjekty hospodařící s veřejnými penězi stanoví specifický postup uzavírání smluv právě za účelem maximálně hospodárného využití veřejných prostředků.

Obecněji, tj. nejen v kontextu zadávání veřejných zakázek, je tento požadavek odražen např. v § 45 odst. 2 zákona č. 218/2000 Sb., rozpočtová pravidla (tzv. „velká“ rozpočtová pravidla), podle něhož je organizační složka státu povinna dbát mj. o to, aby plnila určené úkoly nejhospodárnějším způsobem. Podle § 14 odst. 1 zákona č. 219/2000 Sb., o majetku České republiky a jejím vystupování v právních vztazích, musí být majetek využíván účelně a hospodárně. Požadavek na péči řádného hospodáře lze dovodit též z některých ustanovení zákona č. 89/2012 Sb., občanského zákoníku, např. z jeho § 2900, podle něhož platí, že vyžadují-li to okolnosti případu nebo zvyklosti soukromého života, je každý povinen počínat si při svém konání tak, aby nedošlo k nedůvodné újmě na svobodě, životě, zdraví nebo na vlastnictví jiného.

Odpovědnost za nežádoucí stav či nefunkčnost může vzniknout v rovině soukromoprávní, přestupkové i trestní.

Vznikne-li v důsledku pochybení v oblasti informačních a komunikačních technologií škoda fyzické nebo právnické osobě, je tato osoba podle povahy věci, tj. zda orgán veřejné moci jednal v rovině soukromého práva anebo při výkonu své veřejné moci, oprávněn požadovat náhradu vzniklé škody, a to podle soukromoprávních předpisů, primárně občanského zákoníku, anebo zákona č. 82/1998 Sb., o odpovědnosti za škodu způsobenou při výkonu veřejné moci rozhodnutím nebo nesprávným úředním postupem. Je možné požadovat náhradu škody i nemajetkové újmy, uvedení v původní stav apod.

Zákony upravující povinnosti v oblasti ICT řešení, kybernetické bezpečnosti, ochrany utajovaných informací, ale i zákony upravující samotné agendy, které jsou prostřednictvím informačních a komunikačních technologií vykonávány, upravují celou řadu skutkových podstat přestupků, za něž lze mj. orgánům veřejné moci uložit pokuty.

V rovině trestního práva může být v důsledku pochybení v oblasti informačních a komunikačních technologií naplněna skutková podstata např. trestného činu neoprávněného nakládání s osobními údaji (§ 180 trestního zákoníku), porušování povinností při správě cizího majetku (§§ 220 a 221 trestního zákoníku), poškození záznamu v počítačovém systému a na nosiči informací a zásah do vybavení počítače z nedbalosti (§ 232 trestního zákoníku), porušení autorského práva, práv souvisejících s právem autorským a práv k databázi (§ 270 trestního zákoníku) nebo ohrožení utajované informace z nedbalosti (§ 318 trestního zákoníku).

V kontextu poptávání plnění v oblasti informačních a komunikačních technologií je poptávající orgán veřejné moci povinen plnit povinnosti uložené zákonem č. 181/2014 Sb., o kybernetické bezpečnosti, a jeho prováděcími předpisy, zejména pokud jde o analýzu a řízení rizik, a zohlednění opatření NÚKIB, např. tzv. varování. Závěry z těchto činností vzešlé je orgán veřejné moci povinen zohlednit v zadávací dokumentaci k veřejné zakázce. Nedodržení povinností podle zákona o kybernetické bezpečnosti může mít za následek vznik odpovědnosti podle ustanovení tohoto zákona, a to i za situace, kdy k narušení kybernetické bezpečnosti nedojde. Samotné narušení kybernetické bezpečnosti pak může založit odpovědnost za následky popsané v části 1.5.2.2.3.

Každý veřejný zadavatel moci je podřízen zákonu č. 320/2001 Sb., o finanční kontrole ve veřejné správě a o změně některých zákonů, který vymezuje povinnost postupovat efektivně (efficiency), účelně (effectiveness) a hospodárně (economy) při zacházení s veřejnými prostředky. Sledování dodržování těchto principů upravují zejména zákony č. 218/2000 Sb., o rozpočtových pravidlech, ve znění pozdějších předpisů; zákon č 219/2000 Sb., o majetku České republiky a jejím vystupování v právních vztazích. Použitím dobře zpracovaných požadavků je zcela zásadní k dosáhnutí všech výše vymezených cílů.

Principy 3E jsou aplikovány nejen za účelem samotného získání ICT řešení, ale i za účelem toho k čemu ICT řešení mohou a mají sloužit.

Základní pohled na tyto pojmy 3E je, že efektivita znamená dělat věci správně, účelností se myslí dělání správných věcí, hospodárnost představuje přiměřenost vydání k získání chtěného užitku z hlediska nákladů na tento užitek. Zadavatel postupuje v souladu s 3E právě tehdy, když jednotlivé principy jsou ve vzájemné rovnováze a doplňují se.

Efektivitou se rozumí použití prostředků tak, aby bylo dosaženo nejlepších možných výstupů při daném množství vstupů. Tedy maximalizace kvality a kvantity vůči vstupům. V aplikaci na ICT řešení to má následující souvislost: Bez znalosti toho, co objednavatel/získatel přesně potřebuje, není možné poskytnout kvalitní řešení (především u vývoje na klíč) či dosáhnout optimální ceny (v případě již existujícího řešení).

Účelností se jedná o použití zdrojů tak, aby bylo dosaženo optimálních cílů, tedy zda bylo dosaženo cílů, které měly být dosaženy. U požadavků je tím myšleno to, že ICT řešení má takové vlastnosti, jaké objednavatel/získatel zamýšlel a ve skutečnosti získal. Účelné je též to, aby nevznikaly vedlejší náklady na činnosti. V případě ICT řešení jde o to, aby splňovaly takové kritéria, která jsou potřebná. Není účelné platit za funkcionality nevyužívané, či díky bezpečnostní chybě přijít o značné zdroje.

Hospodárností se myslí činnosti, kde jsou minimalizovány náklady na zdroje (finanční, kapacitní, lidské, věcné) a zároveň je dosaženo vyžadované kvality pro daný záměr. Zdroje musí být přítomny ve správnou dobu, na správném místě, v dostatečném množství a kvalitě, to vše za nejvýhodnější cenu. V oblasti ICT řešení jde tedy o to, aby dodávané služby a produkty byly dodány za použití minimálních zdrojů (finanční, kapacitní, lidské, věcné aj.).

Existuje souvislost mezi byznysovým výkonem funkce úřadu, architekturou a již zavedeným ICT. Tuto souvislost je potřeba zachytit pro sběr požadavků na ICT řešení.

Každé ICT řešení slouží v kontextu úřadu, kde je zasazen do business procesů veřejné správy ve své míře podrobnosti (samotný úřad, agenda, digitální služba, digitální úkon), z nichž plyne Entrprise Architecture, z nichž vyplývá samotné ICT. Na grafu je vidět válec, který popisuje souvislosti mezi těmito třemi oblastmi. Výška válce popisuje úroveň, na které je daná věc řešena. Interakce probíhají na různých úrovních od nejvyšších, po nejnižší.

Na vzniku a provozu ICT řešení se podílí vzájemně navazující oblasti. První je oblast byznysu jako takového, který v prostředí úřadu odpovídá výkonu veřejné správy a chod samotného úřadu. Jedná se o oblast věcného správce agendy. Oblast obsahuje strategické, sektorové a dílčí chování. Byznys taktéž plní roli ekonomickou a účtovací. Je správcem a rozdělovatelem finančních prostředků.

Druhou sférou je architektura, která navrhuje na takticko-strategické úrovni principy, způsoby provedení, výstavbu prvků úřadu.

Třetí sférou je samotná realizace a podpora výkonu veřejné správy pomocí informačních a komunikačních technologií, kde se vyskytuje technický správce.

Z hlediska čtyřvrstvé architektury jak vrstva informační, tak platformy a technologická slouží a zprostředkovává realizaci vrstvě byznysové. Vztah by samozřejmě měl být vyvážený. Správce rozpočtu by měl účelně a dlouhodobě na základě strategie podporovat oblast informatiky. Z druhé strany efektivně financované a stabilní ICT zpětně poskytuje úřadu nejen danou podporu a technologicko-informatické zprostředkování výkonu veřejné správy, ale dále nachází a přináší možnosti, jak celý chod nejen optimalizovat, ale transformovat.

Z hlediska komunikace spolu oblasti:

• Byznysu a ICT interagují právě a zejména pomocí rozpočtu a realizovaných kapacit, proto z tohoto důvodu, kdy dochází k této interakcié (po uvědomění si této vlastnosti).
• Jak dvojice Byznys a architektura, tak architektura a ICT spolu komunikují v mnohem širším spektru, kdy disciplína architektury úřadu takovouto efektivní komunikaci umožňuje. V obou pohledech architektura je prostředkem, jak efektivně řídit a transformovat jak věcnou/výkonnou byznysovou část organizace, tak i složku ICT, která tento výkon podporuje.

Obrázek 1 – Porovnání cen opravy požadavků

Sběrem požadavků se zabývá business analyst, tj. byznys analytik (synonymem je requirements analyst, systems analyst, requirements engineer, requirements manager, application analyst, business systems analyst, IT business analyst, nebo jednoduše analyst). Neznamená to nutně, že je to pracovní pozice, ale může jí být. Na jednom projektu se jich může podílet i více. Takovýto člen týmu či externí specialista pracuje s projektovými manažery, věcnými správci, provozovateli, znalci problematiky, vývojáři, a i s uživateli.

Tento postup je však modifikován okolním prostředím (zde je myšleno legislativní), ve kterém se veřejná správa jakožto v roli zadavatel vyskytuje. Je nutné rozlišovat podstatu funkce gestora, věcného a technického správce, který tedy nemusí být tatáž organizace. Tedy na tomto principu existuje více rolí analytiků – z pohledu gestora, věcného správce a technického správce.

Obrázek 2 – Základní fáze životního cyklu ICT služby VS a jejich návaznosti

Business analytik ve své analyzuje projekty v rámci kontextu, potřeb a dále navrhuje nová řešení. Dále se zabývá vyzvídáním potřeb, jejich sběrem, dokumentací a předáváním zainteresovaným stranám. Jeho hlavní přidaná hodnota je pochopení nejen toho, co daný stakeholder říká, ale i toho co ve skutečnosti potřebuje. Neboť jen málokterý uživatel ví, jak ve skutečnosti funguje ICT svět či jaké možnosti poskytuje (Wiegers, 2013 pp. 61-62).

Touto činností je myšlena dvoustupňová byznysová analýza, na které podílejí celé týmy lidí. Takovéto služby si lze najmout a často v prostředí českého eGovernmentu k tomu dochází. Je to rozhodně příklad dobré praxe, protože investování do kvalitně zpracovaných požadavků, především pak u rozsáhlých ICT řešení (systémů), je investicí, která má vysokou návratnost. U mnohých úřadů ani neexistuje kapacita takovou činnost dělat interně. Kromě spolupráce při vytváření a sběru požadavků lze takové služby využít pro práce související se zadáváním výběrového řízení, příkladem budiž formulace odpovědí zájemcům o zakázky (odpovědí je upřesňováno a modifikováno celé dílo).

ICT Architekt před s po sběru požadavků (byznysových, požadavků zainteresovaných stran, systémových). Nastupují role ICT architekti a to:

1. EA- Architekt úřadu, který popisuje organizaci- Poskytne podporu jak daný systém má být nejlépe začleněn do organizace a jak zavedení systému ovlivní organizaci.
2. SA – Soloution Architekt, jež organizace může mít vlastního, nebo si ho pronajmout. Jehož služby buď
   1. Jsou předmětem dodání konečného díla, nebo
   2. Tvoří mezistupeň k dodání konečného díla, tj. vytvoří zavázaný podklad pro dodání díla
3. SD- Solution designer – pakliže jde o vývoj na mírů pracuje se i s touto mírou návrhu

Jehož služby buď

1. Jsou předmětem dodání konečného díla, nebo
2. Tvoří mezistupeň k dodání konečného díla, tj. vytvoří zavázaný podklad pro dodání díla

Architekti úřadu nebo najmutí architekti mají za úkol zasadit řešení do architektonických pravidel eGovenmentu ČR.

Architekti úřadu nebo najmutí architekti mají za úkol zasadit řešení do architektonických pravidel a architektury úřadu.

Architekt primárně sesbírané požadavky konzultuje. Po vyhodnocení těchto požadavků následně navrhuje co možná nejlepší, avšak opodstatnitelnou a realizovatelnou, architekturu řešení a udává vymezení rámce daného řešení. Architekt by tedy neměl primárně dané požadavky sbírat, to je náplní tomu příslušných analytiků a dalších dílčích zdrojů.

Každý byznys požadavek na vlastnosti ICT řešení má aspekty kvalitativní a kvantitativní, respektive funkční (co to má dělat) a nefunkční (za jakých podmínek, okolností a v jakých metrikách to má splňovat funkční požadavky. Rozmanitost zejména ne-funkčních požadavků vede architekta k návrhu komponentizace aplikační a technologické architektury, „k sobě“ jsou dávány funkční požadavky s jejich dorazem v ne-funkčními požadavky (třeba dostupností).

Jakékoliv ICT řešení je stavěno v kontextu právního rámce. V případě že se jedná o agendové informační systémy, kde je úřad, jež systém využívá či nabývá i věcným gestorem dané problematiky tak nastává situace, jež nenastává v soukromé sféře, kdy úřad může měnit právní prostředí, ve kterém se pohybuje³⁾. Ale i nadále platí, že ICT řešení může být v souladu s právním prostředím. V rámci řízení rizik nelze spoléhat na návrhy změny legislativy, lze se při změnách spolehnout jen na definitivní znění zákona.

Legislativa musí být v souladu s následujícími pravidly (protože jen dobrá legislativa zajistí optimální funkci ICT řešení):

• Pravidly pro digitálně přívětivou legislativu⁴⁾
• Právem na digitální službu

Pro správně sepsané požadavky na ICT řešení musí dojít k porozumění chodu organizace a jak má organizace v budoucnu fungovat a to nejen z pohledu architektury, ale i z pohledu procesního (kde procesy vychází z architektury úřadu).

ICT řešení za své podstaty standardizuje business procesy v organizaci a to díky tom že v ICT řešení musí být zaneseny role, třídy a oprávnění uživatelů nebo jejich skupin. Dále ICT řešení vytváří data o svém chodu v unifikované podobě.

V této sekci je byznysovým procesním modelováním myšlena disciplína o poznání interního chování podniku, v tomto případě zejména pak jednotlivých úřadů. Byznysové procesní modelování přináší vnitřní znalost o fungování podniku. Z hlediska komplexity podniku, potažmo úřadu je vhodné toto modelování rozdělit na vysokoúrovňové modelování, které je na konkrétní implementaci nezávislé. A naopak nízko úrovňové, jež poskytuje velice detailní pohled na daný proces, jeho vstupu, výstupu a další pomocné dokumenty. Jedním z výstupů tohoto modelování jsou téže požadavky na ICT řešení.

Vysokoúrovňové modelování umožňuje zkoumání úřadu v jeho abstraktnější formě. Důraz je kladen na hlavní či základní vztahy a interakce. Je tedy řešeno, co se dělá a zda toto konání má smysl. To umožňuje prvotní optimalizaci.

Příkladem tohoto modelování je metodologie DEMO, která zjistí současný stav procesů As-Is. Na základě IK OVM, NAP a NAR (případně jiných dokumentů, pakliže zadavatel není OVM), navrhne procesy ToBe. Business procesy ToBe, jsou dále v souladu s byznys cíly, strategickým konceptem provozu ICT řešení a operačním konceptem provozu ICT řešení .

Nízkoúrovňové modelování s detailním popisem přináší další možnost pro optimalizaci. Zkoumaní jednoho procesu, či malého souboru procesů do detailu umožňuje další zlepšení procesu.

Následně dojde k procesnímu modelování. Nejprve jsou zmapovaný procesy AS-IS. Následně jsou navrhnuty procesy TO-BE. Je potřeba mí na paměti, že i když se Business procesy nezmění, tak může dojít ke změně procesů. Např.: role úředníka zůstane stejná a práva občana zůstanou stejná, avšak může dojít ke změnám procesů (např. směrem k větší efektivitě, přívětivosti k občanovi).

Příkladem nástrojů, notací, technik podporující tento typ modelování jsou kupříkladu BPMN, UML, vývojový diagramy. V prostředí veřejné správy České republiky se využívá metodiky procesní modelování agend⁵⁾ (PMA).

Výše zmíněné výstupy lze využít do procesu organizační změny. A ty to výstupy jdou použít pro celo organizační změny v částech organizace, které se tyto změny netýkali.

Pro volbu správného modelu realizace a provozu⁶⁾ ICT řešení je důležité provést volbu na základě analýzy všech výše zmíněných parametrů (role, prostředková typizace, doba provozu) jako uceleného souboru. A tedy, pokud má provozovaný či zamýšlené ICT řešení podporovat určitou funkci (a dále kooperovat ve vztahu s ekonomickou, bezpečnostních a dalších) nezbytné určit osy v následující 3D matici

Business funkce je možné dělit na klíčové, nebo kontextovou/okrajovou. Výchozím pravidlem je, že klíčové funkce není možno outsourcována z organizace pryč, kdežto okrajové funkce je možné outsourcurcovat. Zde je dopad na kybernetickou bezpečnost a prevenci vendor lock-in efektu.

Na základě byznysové analýzy je vydáno rozhodnutí, jak velkou část business procesu, ICT řešení má úřad skutečně provozovat. Osa je vytyčena dvěma protipóly, jedním je absolutní kontrola jak nad procesem, tak i následnou aplikací se vším všudy, druhým pak absolutní sdílení celého procesu, a tedy i dalšího aplikačního vybavení s externím subjektem (BPaaS).

V rámci samotné aplikace a jejích následných prostředků je možné tuto aplikaci provozovat jen jako službu (SaaS), anebo je možné vlastnit i provozovat fyzické prostředky, tj. servery, mainframy, datová uložiště aj. (On-Premise řešení). I z tohoto hlediska lze sestavit hierarchizovaný model. Diagram obsahuje členění jednotlivých součástí daného řešení (obrázek 3). Tedy pro řešení typu SaaS je dodavatel zodpovědný za celé řešení související se softwarem, při užití PaaS je oblast aplikací a dat přesunuta k objednavateli řešení. Analogicky z druhého konce pro On-Premise řešení platí, že obsahuje všechny zmíněné elementy.

Nezávisle na prostředkové typizaci je nutné vždy mít na pozoru oblast vlastnictví a dostupnosti dat. Správa dat samotných, po boku služeb, je jedním z kritických aktiv každého úřadu.

V rámci této problematiky se řeší dopad na ekonomiku, kybernetickou bezpečnost a flexibilitu.

Tabulka 1 – Typy standardizace stavebních kamenů architektury eGovernmentu

Na základě okolností a dostupných znalostí je nutné určit, po jak dlouhou dobu bude činnost ICT řešení provozováno. Existují situace, kdy činnost bude vykonávána jen krátký čas (jeden rok, dotační období), avšak na druhé straně existují situace, kdy se s činností předpokládá jako s trvalým stavem (agenda registru obyvatel, výběr daní). Takovýto faktor má dopad na návrh robustnosti řešení a zajištění dlouhodobé podpory, nebo snadnosti a možnosti migrace na řešení nové.

Nesekvenční popis možných náplní rolí 1

Díky rozdělení sowftwaru, nasazení a možnosti přesouvat řešení flexibilně mezi privátním a veřejným cloudem je možné odděleně soutěžit nebo budovat IaaS, PaaS, SaaS, tak aby bylo dosaženo optimálních provozních výsledků. PaaS pro všechny systémy, nebo jejich část, je možné vysoutěžit nezávisle na jednotlivých systémech a migrovat tak celé soubory řešení podle aktuální situace na jednou.

Možnost rozdělení nebo slučování soutěží na jednotlivé systémy musí odpovídat požadavkům 3E, IK úřadu, strategickému konceptu ICT řešení, operačnímu konceptu ICT řešení a dalším strategiím úřadu.

Jedním z hlavních výhod modularity a její standardizace je navržení stavebních bloků (v literatuře a materiálech uváděné též jako building blocks), které se podílejí na stavbě funkčních celků. Specifikovaní stavebních bloků, je možno vykonat pěti způsoby (tabulka 1). Krom samotného sběru požadavků pro samotné ICT řešení lze ten sběr znovu využít pro standardizace stavebních bloků architektury eGovernmentu.

Definice stavebního bloku je možno téže vyjádřit jako seznam funkčních a nefunkčních požadavků. Díky tomu je možné poměrně exaktně na základě porovnání schopností/možností daných stavebních bloků s patřičným seznamem požadavků pro novou službu porovnat, zda je užití již jednou sestaveného řešení vyhovující a případně do jaké míry se liší.

Moduly by svojí funkcí měly být budovány pro co nejvíce dalších řešení, jak v rámci celého úřadu, tak v rámci kontextu celého e-Governmentu.

Základní vlastností stavebních bloků je možnost jejich vícenásobného použití a replikace. Je doporučováno tyto již existující stavební bloky v rámci ICT řešení znovu-využívat. Samozřejmě v případě nejen díky jejich pouhé existence ale i jejich vhodnosti užití. Tato vhodnost užití je právě umožněna díky možnosti porovnání požadavků.

Modularita je podstatným požadavek pro udržitelnost ICT řešení, jež nevykonávají triviální funkce. Umožňuje lepší správu ICT řešení a možnost rozvoje i po delší dobu provozu. Je nutné jít rozdělit na dva stupně:

• ICT řešení je modulární sám o sobě – tj. umožňuje technologicky neutrálních řešení pro integraci
• ICT řešení je objednáván od více dodavatelů (při splnění předchozí podmínky) – a přidaná hodnota integrace je vytvářena (třeba i sub dodávkou) na straně úřadu

Přechodem od monolitického řešení je možné flexibilních řízení životních cyklu jednotlivých modulů, jenž jsou nezávislé nad životních cyklem svrchovaného a souhrnného informačního ICT řešení. Při dostatečné míře modularity je téže možné upravovat či nahrazovat moduly nejen jako celé portfolio, ale po jednotlivých modulech v různých časech. To umožnuje vyšší a flexibilní kontrolu nad ICT řešením, neboť je možné spravovat každý modul zvlášť, a každý modul může mít svého dodavatele se svým životním cyklem, a to i mimo výše zmíněný hlavních životní ICT řešení. Tím se jedná i o jednu z možných efektivních obran proti vendor lock-in efektu.

Avšak aby princip modulárního řešení byl funkční (a téže splňoval obranu proti vendor-lock-inu), je nutné myslet na způsob komunikace mezi těmito moduly. V případě specifikace komunikačního rozhraní, je tedy zásadní nastavit pravidla a standardy tak, aby je mohli využívat nezávisle (finančně, technologicky aj.) i další strany/potenciální další dodavatelé.

Dalším možným krokem k zvýšení modularity ICT řešení je možné celý informační systém rozdělit na více zakázek a přidanou hodnotu integrace vytvářet na straně objednavatele. Nebo integraci objednat, jako sub dodávku od dalšího dodavatele. Nebo další možností je objednat modulární dílo od jednoho dodavatel a mít možnost měnit dodavatele správce jednotlivých modulů. Míra rozdělení musí odpovídat zásadám 3E, schopnosti řídit rizika a schopnosti integrace.

Bez ohledu nad zvoleným typem provozu se veškeré právní aspekty a dopady řídí platnou legislativou (viz občanský zákoník aj.) To, co v daném smluvním materiálu není specifikováno, se řídí obecnými předpisy a zvyklostmi, tedy jejich výklad je více otevřený na interpretaci v daném prostředí.

Z tohoto legislativního principu vyplývá, že je nutno jakékoliv smluvní vztahy koncipovat takovým způsobem, aby byly v rámci smlouvy právně specifikované, dokazatelné a následně vymahatelné. Tohoto stavu si musí úřad být vědom.

Celý vývoj ICT řešení lze rozdělit, ve smyslu úloh nikoliv modularity, do několika rolí, jež nemusí být obsazeny stejnými osobami či organizacemi. Ovšem úroveň dělby práce a outsourcing musí odpovídat nárokům 3E. Přidanou hodnotou této služby je a mělo by být i odhad pracnosti a nákladovosti jednotlivých požadavků.

Při pořizování ICT řešení je vhodné rozdělit pořízení a dodávku na řešení na dva dílčí kroky, které na sebe časově navazují. Jedním je samotná tvorba a tedy i pořízení ICT řešení. Druhým je pak implementace ICT řešení a uvedení do provozu. Tímto rozdělením se tento proces dá jako celek zefektivnit, neboť toto oddělení dodavatele a implementátora umožňuje optimální výběr specializovaných stran pro daný typ úkonu.

Samotné rozdělení na dodavatele a implementátora však nelze vždy považovat za ekonomicky výhodné například z pohledu sumy samotných zakázek (a jejich plánované udržitelnosti). Proto je tedy nutné vždy danou situaci posoudit. Avšak toto rozdělení vždy zvyšuje odolnost vendor lock-in efektu, tedy je zvyšována míra nezávislosti na konkrétním dodavateli.

Příklad

Mějme potřebu úřadu pro nový modelovací nástroj pro architekturu úřadu. V prvním kroku se vysoutěží nástroj na podnikovou architekturu (architekturu úřadu) s parametry světového standardu a splňujíc kvality pro provoz ve veřejné správě. V druhém kroku, poté co již mám smluvně ošetřeno dodání produktu a další spolupráci, proběhne výběrové řízení na implementátora tohoto řešení, neboť má na rozdíl od ostatních nejen lepší cenovou nabídku, ale co je hlavní dostupné know-how a zkušenosti s nasazováním takového produktu v samé či obdobné organizaci.

Smyslem tohoto rozdělení je, že může nastat situace (vždy je nutné posoudit), kdy existuje strana, která je excelentní v oblasti vývoje, avšak se vůbec nezabývá implementací. A naopak existuje druhá strana, která je na tom opačně, tedy umožňuje excelentní implementaci, ale sama se vývojem nezabývá, nebo nemá patřičné schopnosti.

Za účelem provozu informačních systémů je nezbytné zvolit správnou licenční politiku a podmínky pro výběr podporovaných řešení za účelem dosažení cílů 3E. Nevýhodný Vendor lock-in, tj. situace kdy dodavatel zneužívá svého dominantního postavení, je proti zásadám 3E. Typicky následujícím způsobem:

Pro eliminace tohoto rizika tedy musí být splněny dvě základní podmínky:

1. Musí být dobře nastavena licenční a smluvní politika
2. Znalost o systému musím být dostatečně rozšířená i mimo původní organizaci tvůrce

Lze si představit situace kdy sice úřad má dobře nastavené licenční podmínky, ale ICT řešení je natolik obskurní že ho nelze spravovat. A naopak systém je dobře a velice znám, ale licenční politika je tak nevýhodná, že to nemění situaci. A proto je nezbytné stanovit příslušná kvalifikační kritéria na technologickou základnu řešení (např.: „Databázová technologie je mezi 10 světové nejpoužívanějšími na světě“ nebo v případě požadavku na open source: „Serverová platforma je mezi 5 pěti nejvíce používanými open source serverových platforem nabízených s podporou“).

V situacích vývoje na míru potřebám úřadu, pakliže nebudou rizika pokryta jinak, dle specifických požadavků, musí buď být dílo vedeno pod (zde se jedná o zásady Z16 a Z17):

1. Otevřeným kódem, nebo
2. Plně ve vlastnictví úřadu

Dále je doporučeno, že kompetenty, jež jsou znovu využitelné v jiných řešeních do budoucna, je vhodné vést pod otevřenou licencí.

Důležité je mít na paměti že i v případě propriálního systému nebo jazykového vybavení je stále možné toto zajisti (pakliže tomu nebrání jiné situace, např. výslovný zákaz).

Zvolení a správa jednotlivých typů licenčních ujednání, nebo využití služby, ze své podstaty přináší různé klady, ale i negativa.

Základní shrnutí (tabulka xy)

Přístup k intelektuálním právům na informační systém lze rozdělit na dva přístupy:

Homogenní přístup k intelektuálním právům, nastává tehdy, když celé ICT řešení je vedeno jen pod jedním režimem vlastnických práv. Tento přístup má menší výhodu v jednodušší licenční správě, avšak někdy zbytečně dochází k újmě objednavatele tím, že dodavatel překryje celou část kódu více restriktivními podmínkami, než je nutné. Dále je nutné konstatovat, že u větších systémů tento přístup není praktický.

Heterogenní přístup k intelektuálním právům, nastává tehdy, když ICT řešení je vedeno pod více režimy vlastnických práv. Tento přístup má menší administrativní nevýhodu v tom, že je nutné spravovat více typů licencí. Avšak díky tomuto přístupu a obzvláště pak v kombinaci s modulárním ICT řešení, je možné dosáhnout lepší udržitelnosti, možnosti rozvoje a efektivněji zabránit vendor lock-inu. A to následujícím způsobem: Díky možnosti přebrat správu licencí pod svojí činnost (in-sourcing), lze zajistit licenční správu ICT řešení i bez dodavatele. A to i v situaci kdy některé části jsou unikátně dodané dodavatelem, pakliže tyto části jsou řádně smluvně ošetřeny. Tyto unikátní části by měli tvořit moduly ICT řešení, aby je bylo možno nahrazovat.

Kombinací různých režimů intelektuálních práv, lze dosáhnout optimální situace, než být ve stavu, kde je vše v licenci dodavatele. Lze si představit situace, kde ICT řešení kombinuje všechny vyjmenované licenční režimy. Databáze využívá komerčně dostupný software, operační systém je pod Open Sourcem, sběrnice je zajištěna již vlastním kódem a napojení na systémy e-Governmentu je zajištěno centrálně dodaným softwarem.

Režimy vlastnění jsou následující:

Software, potažmo kód spadající pod licenci typu open source je ve své podstatě otevřený (tj. přímý přístup kódu, možnost jeho změny, přidávání funkcionality, použití není zpoplatněno). Avšak tento termín a licenční ujednání nabývá mnoha druhů a forem, kde některá předchozí práva jsou omezena či jinak specifikována.

I k Open Source ICT řešení pořídit kvalitní podporu.

Je vyvíjen externími společnostní za účelem zisku. Existují dva základní přístupy, dostupné balíkové řešení, jenž se dá přímo koupit (COTS) a smluvní zakázkou vyvíjený produkt. Z hlediska spolupráce s externím subjektem je nutné rozmyslet licenční politiku na daný produkt a jeho licenci včetně přístupu ke zdrojových kódů, dokumentacím (vývojovým). Téže je nutné posoudit a smluvně vyřešit možnosti na změny a s tím spojené finanční břímě. Neboť jakékoliv dílčí změny jsou zajištovány smluvně a mohou se prodražit

Kód a software vyvíjen vlastními podnikovými silami je speciálním typem, z hlediska pořízení, zatímco Open source a komerční software je pořizován s tím, že bude mít více uživatelů, tak zde dochází k vytváření hodnoty uvnitř společnosti, to však přenáší veškeré úlohy s vývojem tím spojené na podnik samotný. Téže se jedná o režim tvorby softwaru na míru, pakliže je výhradní licenci.

Je možné, že v některých případech může být pořízen software, který bude pořízen pro všeobecné použití ve veřejné správě. Bude se pravděpodobně jednat o běžně komerčně využívaný software.

Všechny požadavky, které jsou známy před, jež by mělo být maximum. Je nutné přepsat do předmětu veřejné zakázky a vzorových smluv k ním přiložených.

Rozsah práv v oblasti duševního vlastnictví je vhodné nastavit co nejvíce ve prospěch orgánu veřejné moci jakožto zadavatele, jestliže je to hospodárné a technicky účelné. Obecně platí, že pokud je dané řešení na základě poptávky zadavatele přímo vyvíjeno a implementováno, měl by zadavatel mít k tomuto řešení sjednán maximální rozsah práv, zejména právo ke zdrojovému kódu, právo řešení upravovat jiným subjektem, postupovat jej jinému subjektu apod. Je tomu tak proto, že je to právě zadavatel, kdo hradí vývoj daného řešení a je tedy nanejvýš vhodné, aby zadavatel měl nad tímto řešení maximální ekonomickou a technickou kontrolu, nikoliv aby toto zadavatelem uhrazené plnění dodavatel dále zpeněžoval. Naopak pokud je poskytováno široce dostupné řešení, vyvinuté nákladem dodavatele a totožné či podobné pro všechny zákazníky, tj. tzv. krabicové řešení, které lze zároveň snadno nahradit, není nutné mít maximální rozsah práv sjednán, neboť by to nebylo účelné a hospodářská náročnost by byla neodpovídající. Přesto i v tomto případě by měl mít zadavatel sjednán adekvátní oprávnění, pokud jde o úpravy řešení, sublicencování, apod., zejména s přihlédnutím k vnitřním procesům (tj. vazby licencí na stanice vs. na zaměstnance, zahrnutí např. pravidelných úprav podle změn legislativy, oprávnění k licencím pro podřízené organizace, apod.).

Dále je nutné mít na paměti, že autorská práva se dělí na:

1. Autorská práva majetková
2. Autorská práva osobní

A je nezbytné zajistit si oba typy práv, pakliže dochází k vývoji na míru, nebo dle požadavků úřadu, nebo v jiných případech kdy je to příhodno. A to ve vyžadovaném rozsahu (nebo rozsahu větším, avšak vždy tak aby smluvní klauzule s úžeji definovanými právy (avšak dostatečnými právy) byla platná)).

Je zřejmé, že plnění v oblasti informačních a komunikačních technologií není plněním jednorázovým, nýbrž je založeno na průběžném dodávání plnění. Zadavatel musí tuto potřebu dalších plnění, zejména pokud jde o aktualizace, reakce na vývoj legislativy, reakce na vývoj v oblasti kybernetické bezpečnosti, adekvátně anticipovat a případně využít např. rámcovou smlouvu, sjednání opce, apod., a toto další anticipované plnění adekvátně zohlednit v zadávací dokumentaci.

Při koncipování smluv a dlouhodobých plánů pro pořízení ICT řešení je potřeba vyházet z toho že je v případě ICT řešení na mírů úřadu, lze vycházet z předpokladu, že ten kdo řešení vybudoval, bude ICT řešení lépe než ostatní, než kdokoliv jiný (a to i přes doporučováno variantu používání co nejvíce standartních řešení, jak otevřených tak komerčně užívaných). Snahou je přesunout a co nejvíce znalostí do širšího pole působení, pokud možno otevřenou licencí. Ale nelze se vyhnout faktu, že informace (tj. znalostí) jsou ve společnosti distribuovány asymetricky a asynchronně. Z tohoto důvodu je ve většině případů vhodné, díky této informační asymetrii spojit vybudování, správu, podporu, rozvoj a údržbu do jedné zakázky. Dalším důvodem je, že pakliže dodavatel řešení pověřen i budoucí správou, tak je spíše motivován vybudovat udržitelné ICT řešení, protože ono ICT řešení bude spravovat i nadále. Obecně jsou lepší dlouhodobější vztahy pro správu ICT sofistikovaných řešení. U vztahů komoditního typu je na otázce optimalizace kapacit a fixace cen.

Správa by měla odpovídat délce provozu, avšak díky legislativními omezeními (díky je možné uzavírat smlouvy o podpoře jen na 48 měsíců, případně prodloužit o dalších 12 měsíců navíc, nebo do vyčerpání finančního rámce či 48 měsíců do kdy má být rámec čerpán.

Smluvní zajištěn může probíhat dvěma variantami:

1. Rámcovou smlouvu, která je platná do:

a. vyčerpání rámce, na který byla uzavřena, nebo

b. vypršení doby, na kterou byla uzavřena a to maximálně na 48, s možným neopakovaným prodloužením o další 12 měsíců

2. Smlouvou, která je platná

a. maximálně po dobu 48 měsíců, nebo

b. po dobu prodlužování smlouvy, maximálně však o 12 měsíců

Ovšem úřad by si měl být vědem rizik ze špatně vypověditelných a dlouhodobých smluv. Další možností, či doplněním možností,. jak vztah s dodavatel řídit, je možnost využívání opcí na další provoz, po ukončení současné smlouvy. , strana 36.

S dobou plánovaného provozu ICT řešení se pojí požadavky na udržitelnost ICT řešení, která musí být v souladu s plánovanou dobou provozu, nebo musí být zajištěna adekvátní technologická náhrada zastarávajících součástí.

Pořízení ICT řešení je sám o sobě samostatným projektem z čehož plyne:

1. Nutnost použití nástrojů a postupů projektového řízení
2. Samotný projekt na IS má své požadavky na to aby byl realizován
3. Zavedení, obnova, rozvoj nebo rozšíření informačního ICT řešení přinese změny v organizaci.

Samotné pořízení ICT řešení je součástí širší organizační změny, jež musí být

Zavádění ICT řešení je a má být zasazeno do širšího kontextu (viz graf X hierarchický popis souvisejících činností) mnohem obsáhlejšího projektu. V grafu je znázorněno, jak proces zavádění souvisí s dalšími činnostmi.

Prvním krokem při pořízení ICT řešení je stanovení si „business objective“ v češtině cíle organizace. Byznysové cíl mohou být např: snížení administrativní náročnosti, tak aby bylo zapotřebí jen 25 % současného množství pracovníků“ či vedení agendy dle nového zákona. Cílů může být více. Také aplikace strategií či jiných strategických dokumentů je záhodno propsat do byznysových cílů

V této části je definována, co by mělo ICT řešení splňovat, tak aby splnil vytyčené cíle. Tento proces pořízení ICT řešení je vytyčen projektovým záměrem.

Při pořízení ICT řešení je nezbytné uvažovat o změnách v samostatné organizaci. Je vycházet z vize architektury úřadu a byznys architektury, jež má vycházet kromě jiných pravidel i z pravidel NAP, NAR a metod řízení ICT. ICT řešení je nástroje podpory výkonu činnosti. Dále je nutné změnit stavy a alokaci pracovníků a změnit kompetence.

V průběhu provozu informačního ICT řešení budou kromě pořizovacích nákladů vznikat náklady další, proto je nezbytné zajistit financování a ekonomický model provozu v dlouhodobém měřítku.

V případě evropských dotací se kromě financích z nich obdržených pojí požadavky na udržitelnost. Z čehož plynou požadavky na podporu díla.

Nezbytnou součástí procesu zavádění a užívání ICT řešení je nutnost proškolit uživatele či administrátory ICT řešení. Nutnost proškolení rolí odpovídá úrovni, do jaké hloubky chce úřad ICT řešení provozovat (viz. část „prostředková typizace“). A dále získat vlastní kapacitu školení do úrovně potřebné organizací, pakliže školení bude prováděno samotným úřadem.

Pořízení nového ICT řešení

Zavedení ICT řešení

Zavedení nového ICT řešení sebou obnáší role integrace do současného prostředí, kde je nezbytné součinnost (a tedy i její smluvní a organizační zajištění) se dodavatelem současného a dodavateli, případně integrátory, současných řešení. Včetně ustanovení do provozu.

Údržba ICT řešení

Je nutné zajistit rozpočet a organizaci údržby ICT řešení, tak aby splňoval do budoucna daná kritéria.

Podpora ICT řešení

Je nutné myslet i na zajištění podpory ICT řešení (help desk, podpora na místě). Rozsah podpory musí odpovídat úrovni, do jaké hloubky a šířky chce úřad ICT řešení provozovat, či jaké činnosti chce provozovat interně či externě.

Rozvoj nového ICT řešení

V průběhu provozu informačního ICT řešení se budou objevovat nové požadavky na nové funkcionality, na tyto požadavky.

Každé zavedení nového informačního ICT řešení sebou obnáší příležitosti pro organizaci. Obecně jde konstatovat, že veškeré „Ohrožení“ dle SWOT matice jdou otočit na „možnosti“.

Po zavedení ICT řešení vzniknou nové kontinuálně provozované činnosti úřadem, které nejsou projektového rázu.

Samotné ICT řešení je nezbytné řídit jak v strategické, operační tak i v zdrojové úrovni.

ICT řešení bude muset být provozováno, zaleží na prostředkové typizaci.

S ICT řešením bude muset pracovat určitý počet pracovníků, kteří s ním budou muset pracovat.

Pakliže rozsah rozvoje řešení nepřesáhne přidělené prostředky, možnosti vlastního rozvoje dle smlouvy s dodavatelem, nebo nepřesáhne pracovní síly, jež jsou k dispozici, tak menší rozvoj ICT řešení je kontinuální činností.

Formulování požadavků je mezidisciplinární disciplína, jež dělá mediátora mezi potřebami odběratele a dodavatele, tak aby se splnili zájmy a potřeby, které má ICT řešení, software, systém nebo služba mít. Výsledkem procesu sběru a tvorby dobrého požadavku je:

1. Porozumění mezi zainteresovanými stranami.
2. Požadavky jsou ospravedlnitelné oproti reálným potřebám.
3. Sběr požadavků s následným vyhodnocením poskytuje základ pro návrhu architektury řešení, případně návrhu řešení (pakliže je řešeno). Dále pro formulování testovací a akceptačních scénářů, jimiž se návrh architektury řešení, případně návrhu řešení a jeho implementace ověřuje.

Procesně orientovaná definice: „Požadavek je cokoliv, co rozhoduje o volbách designu“ (Wiegers, 2013 p. 6) Statická definice požadavku: „Vyjádření, jež převádí nebo vyjadřuje potřebu a její asociované omezení“ (ISO/IEC/IEEE, 2011 p. 5)

Dobře formulovaný požadavek má následující vlastnosti

1. Může být verifikovaný
2. Musí být dosaženy nebo obsahován v systému za účelem vyřešení problému zainteresované strany, či cíle zainteresované strany
3. Je kvalifikovaný měřitelnými podmínkami a ohraničený omezeními
4. Definuje výkon systému, když je používán specifickými zainteresovanými stranami nebo koresponduje se systémem, nebo schopností uživatele, operátora nebo jiné zainteresované stran

Požadavky jdou rozdělit do několika rovin. Z pozice, v jakém detailu a hierarchii jsou sbírány. Na vrcholu stojí Business požadavky (kterými jsou naplňovány byzynsové cíle), z nichž plynou požadavky zainteresovaných stran, které vedou k systémovým požadavkům. Dále existují typy požadavků, jež se třídí podle obsahových kritérií.

Požadavky mají svojí hierarchii jak v čase (v prvotní tvorbě systému) tak ve významu, kdy a jaké požadavky jsou nadřazeny jiným.

1. Business požadavky – jsou požadavky co má systém dělat z pohledu business funkce
2. Požadavky zainteresovaných stran – jsou požadavky, které každá zainteresovaná strana vnímá, že je potřebuje k dosažení svých cílů. (Seznam možných zainteresovaných stran je uveden v tomto materiále)
3. Systémové požadavky – jsou požadavky na samotný systém, co konkrétního má systém dělat.

Funkční – Funkční požadavky popisují funkce systému, funkce systémových prvků nebo úloh, které mají být provedeny (ISO/IEC/IEEE, 2011 p. 13). Nebo „[Funkční požadavky] je popis chování systému, jež bude projevovat za určitých podmínek. (Wiegers, 2013 p. 7)

Nefunkční požadavky – „Tyto požadavky popisují skutečnosti/stavy, za kterých systém musí operovat, existovat nebo popisují systémové vlastnosti. Specifikují jakost systému.“ (ISO/IEC/IEEE, 2011 p. 14). Nebo „popis vlastností nebo charakteristik, které systém musí projevovat, nebo omezení která musí být respektována“. (Wiegers, 2013 p. 7)

Každý požadavek musí mít všechny následující vlastnosti:

1. Je nezbytný – jeho nesplnění by znamenalo nesplnění cíle
2. Implementačně volný – požadavek nesmí klást zbytečné limitace pro jeho implementaci, plní se konkrétní cíle a neříká se, jak ho splnit.
3. Jasný – požadavky jsou jasně formulovány a mohou být vyloženy pouze jedním způsobem
4. Konzistentní – požadavek je bez střetu s jinými požadavky. Pokud ke střetům, jež jsou oprávněné, dochází, tak jsou konzistentně vypořádány.
5. Kompletní – požadavek nepotřebuje další zdůraznění.
6. Jednotný – váže se k jedinečnému požadavku bez souběhu. Tedy neexistuje sdružené nebo duplicitní požadavky.
7. Uskutečnitelný – je možné ho dosáhnout bez velkých technologických pokroků a zapadne mezi systémové omezení (cena, rozvrh, technické parametry, právní normy a regulace) s akceptovatelným rizikem.
8. Vypátratelný – lze vypátrat proč daný požadavek vzniknul až k dokumentu, který specifikuje požadavky zainteresovaných stran.
9. Verifikovatelný – Požadavek má prostředek k verifikaci, že splňuje daný požadavek. Požadavek je posílen tím, že je měřitelný.

Každý vedený požadavek má mít následující atributy. U některých atributů se vede škála, v rámci bezpečnostní komunity se zažila škála 1-4 kde 1 je nejnižší hodnota a 4 nejvyšší. Proto ji doporučuje využívat i zde:

1. Identifikace – jednoznačný identifikátor
2. Priorita zainteresované strany v číselném rozsahu
3. Závislost na jiném požadavku. Pakliže existuje závislost na jiném požadavku, tak je potřeba ji jednoznačně identifikovat.
4. Riziko v číselném rozsahu. Jaké existuje riziko podle jeho dopadu nebo možnosti se vyhnout riziku.
5. Zdroj – odkud požadavek přišel
6. Zdůvodnění – proč byl daný požadavek zaveden.
7. Náročnost pro zavedení ve škále.
8. Typ požadavku.

Soubory požadavků splňují následující:

1. Kompletní – všechny požadavky jsou vyspecifikované. Neobsahuje fráze „bude určeno“ nebo „bude specifikováno“.
2. Konzistentní – Nedochází ke konfliktům mezi jednotlivými požadavky a požadavky jsou unikání.
3. Dostupný – Je reálně tyto požadavky splnit v průběhu celého životního cyklu produktu s akcentací na jeho první fáze. Požadavky by obecně měly být splněny co nejdříve.
4. Omezený – omezený jen na danou oblast a nejde mimo vymezenou oblast

Proces sběru požadavků můžeme rozdělit na dva typy sběru podle času:

1. Požadavky, které organizace sbírá kontinuálně v rámci řízení ICT technologií v rámci organizace.
2. Požadavky, které se sbírají v rámci jednoho projektu zavedení konkrétního ICT řešení.

V rámci systému řízení (tj. plánování, budování, nákupu a rozvoje) ICT technologií⁷⁾ má mít organizace zavedený systém sběru požadavků. Tento systém řízení ICT technologií je uveden v XXX kde rozpracovává sběr požadavků ve své části YYY. Součástí kontinuálního sběru požadavků je i využití nástrojů, kde jsou požadavky zaznamenávány, včetně náležitostí, které jsou uvedeny v následujících kapitolách tohoto dokumentu. Po jejich sběru následuje hodnocení, přiřazování priorit a případná implementace. Požadavky k minulým i budoucím konkrétním ICT řešením se též sbírají pro jejich další využití. Takovéto nástroje by měl též umožňovat sběr požadavků i ke konkrétnímu projektu.

Ke konkrétnímu ICT řešení, nebo k jeho aktualizaci, se využívají jak požadavky, které byly sebrány v rámci kontinuálního sběru požadavků, tak i požadavky, které se sbírají ke konkrétnímu ICT řešení. Poznatky ke konkrétnímu ICT řešení u se též předávají do ICT řešení sběru požadavků (viz předchozí kapitola) pro jejich další využití. Popis sběru bude více popsán dále.

Při sběru požadavků jak při kontinuální bázi, tak při sběru požadavků na konkrétní projekt, dochází ke dvěma typům sběrů požadavků. Jednak k rekursivnímu sběru tak k iterativnímu sběru. Z pohledu úřadu a státní správy je rekursivní sběr upřednostňován (jak v prioritách, tak i v procesech řízení) před iterativním. Avšak iterativní proces nelze vyloučit z důvodů toho, že přináší hodnotu zachycení dalších požadavků

Ve zjednodušeném pohledu se jedná o přístup od shora dolů, kde sbírané požadavky se přepisují z vrchní vrstvy na nižší, dále jsou dovozovány další požadavky a tím je přidávána hodnota ICT řešení. Prostup ale může být i obou směrný. Avšak obecný postup je odvozené požadavky dedukovat.

Ve zjednodušeném pohledu se jedná o přístup od zdola nahoru, kde sbírané požadavky se přepisují ze spodní vrstvy na vyšší, dále jsou dovozovány další a tím je přidávána hodnota ICT řešení. Opět může být zde i vazba směrem zpátky na nižší vrstvy z výších vrstev, ale postup je odvozené požadavky indukovat.

Zainteresovanou stranou jsou organizace či osoby, jež přímo či nepřímo, je zainteresovaná na projektu buď tím že se na ní podíl, dotýká nebo má z něj užitek.

V rámci sběru požadavků existují jako podmnožina zainteresované strany i třídy. Převážně se používají pro uživatele.

Vedení organizace či části organizačního celku ustanovuje omezení, zdroje a povinnosti. V případě nezapojení věcného gestora přejímá jeho činnosti. Vedení úřadu může zadávat požadavky nejen v rámci zadání vertikálně z pozice moci, ale i horizontálně jako jeden ze skupiny zainteresovaných stran.

Jsou přímými uživateli a provádí běžnou činnost. Ti specifikují požadavky pro přímé užívání. (U této skupiny je důležité třídění požadavků, které mají, kvůli nepotřebě).

Tito uživatelé se budou podílet ve větší míře na procesních požadavcích.

Toto jsou uživatelé výstupů. Často jsou to vedoucí pracovníci, kteří dohlíží nebo monitorují nižší pracovníky a používají výstupy jejich činnosti. Ti specifikují toho, co by ICT řešení mělo umět pro jejich potřeby nebo potřeby organizace.

Specifikují požadavky a podílejí se na výběru a dodavatel nebo alokaci zdrojů.

Právní oddělení specifikuje případné další právní požadavky, které nenastolilo vedení organizace nebo věcný gestor a stanovuje právní rámec (případně navrhuje optimalizaci legislativy, pakliže je čas ji provést). Dále v souvislosti s novým ICT řešeními specifikuje možnosti spolupráce dalších již zavedených ICT řešení.

Manažer bezpečnosti nebo bezpečnostní odbor navrhuje pravidla, jež se týkají bezpečnosti fyzické, administrativní, osobní a technické a jiné.

Pakliže úřad má architekta, který se zabývá architekturou úřadu, tak je povinou zainteresovanou stranou. Jeho úkolem je, promítnou architektonickou vizi do požadavků. Z tohoto svého mandátu dodávají architektonické požadavky.

Ve většině organizací státní správy je zaveden věcný správce, ten pomáhá se schopnostmi aplikace a vnitřním organizačním kontextem.

Takováto oddělení se zabývají architekturou a rozvojem IT organizace. Toto oddělení vypomáhá se specifikacemi, které se týkají napojení s ostatními ICT řešeními a potenciálními synergiemi které mohou vzniknout. Dále je to centrum sběru požadavků v organizaci, tj. vede centrálním systém sběru požadavků v organizaci. Dále toto oddělení má na starosti ICT řešení úřadu.

Předává a zpracovává chybová hlášení pro jejich nápravu a pro další vylepšení.

Podstatná zainteresovaná strana. U některých není občan zainteresován přímo, u některých ano. Pakliže že občan je zainteresovanou stranou je podstatné ho jako zainteresovanou stranu zahrnout.

Pakliže existuje externí sponzor projektu, nebo nadřízená organizace tak ta specifikuje většinou byzynsové požadavky

Lidská společnost není ideální, proto existují i zainteresované strany, která mají různé zájmy, na (ne)vzniku, (ne)obnově, (ne)rozvoji nebo (ne)rozšíření ICT řešení. Nebo i tyto zájmy jdou na úkor celého projektu. Ovšem zodpovědností úřadu je se s takovými vlivy vypořádat. Důvodů může být několik:

• Větší transparentnost (agentových dat, chodu agendy)
• Změna nasazení pracovníků
• Změna dodavatele
• Další neznámé
• Ignorované faktory
• Kombinace výše uvedeného

Jedním z hlavních a napříč celým spektrem universálním požadavkem je jasná definice komunikace. Řízení stávajících ICT řešení, kde dochází k úpravám, či vytváření nových řešení je vždy propojeno s nutností komunikace. Ta probíhá v zásadě ve formě interní (komunikace organizace, mezi jejími složkami), tak externí (komunikace s dodavatelem a dalšími stranami).

Interní

Musí být ustanoveno kdo a v jaké kompetenci může komunikovat potřeby dále.

K dodavateli

Musí být ustanoveni styční pracovníci na obou stranách, včetně mechanismů jejich obměny. A dále ustanoveny kdo jaké požadavky může formulovat a schvalovat ve své finální podobě.

V jiných kapitolách je popsáno „čeho“ by systém měl být schopen. Jak bylo uvedeno: každý požadavek má být verifikovatelný. To sebou nese kritéria validace, která jsou známá př. „komunikace musí probíhat pomocí SHA 4096“, takovýto požadavek je jasně verifikovatelný.

Důležitým aspektem je též kvalita ICT řešení a kódu samotného systému (jež v případově řešení na míru bude nezbytné řešit), subsystému a softwaru. Finanční dopad kvality kódu je následovný: Většina informačních systémů vyžaduje 20 % z pořizovacích nákladů na údržbu za rok. Dobře spravovaný kód vyžaduje je jen 10-12 % z pořizovacích nákladů na údržbu za rok. Excelentně spravovaný kód vyžaduje jen 3-5 % pořizovacích nákladů za rok. Avšak verifikace kvality ICT řešení a kódu systému je komplexnějšími tématem. K řešení kvality ICT řešení kódu je zapotřebí:

• Definovat související nefunkční požadavky
  • Přístup ke kódu
  • Možnost kód ukázat
• Definovat požadavky na dodavatele/ výrobce
  • Interní kontrola kvality postupů prací dle procesních požadavků definovaných př. ISO
  • Interní kontrola kvality kódu např. ISO
  • Spolupráce s auditivními orgány
• Mít vhodně uzavřené SLA
  • Snížení ohodnocení dle domluvených schémat (např.: CISQ)⁸⁾
  • Definovat metriky chyb např.:(CVE, CWE, CISQ)
  • Zajistit kontrolu kvality výše uvedených bodů.
• Pomocí interních auditorů (méně pravděpodobné, že veřejné správa tyto schopnosti má)
  • Pomocí externích auditorů, kteří nejsou spojeni s kontrolovaným subjektem (zde se použijí obdobné principy jako u auditu kybernetické bezpečnosti či finanční kontroly).
  • Interní a externí auditoři mohou použít automatizované či polo-automatizovaných nástroje, které mohou být napojeny na systémy správy požadavky a vztahů s dodavateli.

Pakliže návrh ICT řešení dělají architekti, paralelou pravidel eGovernmentu je urbanistika, tak paralelou (ohledně kontroly kvality) ze stavebnictví se jedná o stavební dozor.

Každá ze zainteresovaných stran bude mít požadavky ICT řešení, ovšem je nutné zjistit formalizovaný a dokumentovaný postup požadavků od jejich zajištění do jejich implementace. Mezi funkční implementací a požadavkem je mnoho mezi kroků, které pakliže nejsou dodrženy, tak hrozí negativní následky (zpoždění, více náklady, bezpečnostní chyby, neúplná funkčnost programu, rozšiřování záměru atd.). Ve všech fázích je prováděna dokumentace, dle postupů popsaných v XXX.

1. Identifikace potřeby (může být přeskočeno)
2. Detekce požadavku z potřeby a to buď:
   1. Zjištěním (pomocí kontaktu se zainteresovanými stranami)
   2. Objevením (po kontaktu se zainteresovanými stranami)
   3. Vývojem (Dedukcí či indukcí od jiných požadavků)
3. Analýza
4. Zjištění verifikační metody – jak bude požadavek ověřen
5. Validace požadavku
   1. Schválení požadavku – vedením zainteresované strany
   2. Schválení požadavku – vlastníkem aktiva
6. Zahrnutí do souboru požadavků, nebo do následující úpravy
7. Vývoj
8. Implementace
9. Verifikace a předání

V průběhu času pravděpodobně dojde ke změně souboru požadavků, proto je důležité si nastavit procesy, aby se včas a v co nejlepší kvalitě (ze kterých plynou požadavky) byli zaznamenány a obratem vy komunikovány další zainteresovaným stranám a řídícím orgánům projektu. Včasné zaznamenání změny, i bez alternativy, má svoji hodnotu. Dodavatel může změnit priority a nedojde k mrhání prostředků. Změnou požadavků může být i vynechání některých požadavků, jejich změna nebo přidání nových.

Před zahájením procesu sběru požadavků je nezbytné/ dobré schválit následující závazné a koncepční dokumenty, ze kterých budou plynout následující akce. Tyto dokumenty jsou předpokládány v Metodách řízení.

Účelem tohoto dokumentu je nastínit kontext a souvislosti, jež se s projektem pojí. Tento dokument slouží především k formulaci, jak bude systém nebo systémy využívány. Vychází z předpokladů nebo záměrů výkonu funkcí úřadu. Jeho hlavním účelem je pomoct zainteresovaným stranám pochopit kontext při sestavování požadavků na systém.

Na rozdíl os soukromé sféry se dochází k definici potřeb, jež se týkají legislativy. Takový to proces se v soukromé sféře se nevykytuje. Řeší se otázky oprávnění a změn legislativy, aby systém či systémy mohli fungovat z hlediska právního.

Tento dokument slouží k pochopení toho, co má systém konkrétně vykonávat a v jakém kontextu je zasazen. Dochází ke konceptualizaci vztahů mezi systémy a interakcemi uživatelů.

Po schválení souborů požadavků zainteresovanými stranami se požadavky hierarchicky dělí na následujících kategorie:

1. Byznysové požadavky
   Požadavky, jež se pojí k byznysovým požadavkům
2. Požadavky zainteresovaných stran
   Požadavky, jež se pojí k požadavků zainteresovaných stran
3. Systémové požadavky
   Požadavky, jež se pojí k systému jako celku.
4. Sub Systémové požadavky
   Požadavky, jež se pojí k subsystémům.
5. Softwarové požadavky
   Požadavky, jež se pojí k Softwaru.

Vztah mezi těmito požadavky je kaskádovitý od byznysových požadavků po softwarové požadavky.

Operační koncept provozu ICT řešení, který vchází ze Strategického konceptu provozu ICT řešení, ovlivňuje sběr požadavků a požadavky, tím že vytváří společný základ sběru požadavků. Byzynsové požadavky formují požadavky zainteresovaných stran a tím vytváří ucelené požadavky vůči předchozím dokumentům.

V rozsáhlých projektech bude nezbytné zajistit dodávky služeb pro sběr požadavků externími silami, protože úřad nedisponuje patřičným know-how, jak tuto činnost provést, a i lidskými silami nad rámec běžné činnosti (i při zavedení systému průběžném sběru tyto situace mohou nastat) Je však nezbytné, aby dodavatel služeb měl patřičné schopnosti pro realizaci této činnosti. Talentovaní analytici jsou ti, jenž z projektu udělají, ten, který uspěje.

Možný požadavek na certifikace pro dodavatele služeb:

Sběrem požadavků se zaobírají organizace International Institute of Business Analysis a International Requirements Engineering Board. Tyto organizace poskytují certifikace a školení v oblasti sběru požadavků.

Oblastí dodávky jsou patřičné pracovní síly (man day), které zajistí danou činnost, protože tato činnost je částečně nárazovitého charakteru a lidské zdroje nebudou k dispozici. Nehledě na to že pro tuto činnost musí pracovníci splňovat patřičné kvality.

Sběr požadavků na ICT je samostatnou disciplínou. Schopnost realizovat tuto činnost mají jen někteří dodavatelé, nikoliv všichni. Je za potřebí požadavky sbírat ve standardizované formě, tak aby se s nimi dalo pracovat opakovaně.

Při sběru požadavků je nutné mít vhled do dané oblasti, tak aby „to be“ stav odpovídal moderním požadavkům a trendům. Nejlépe příklady nejlepší praxe ze zahraničí, jak ze státního, tak i soukromého sektoru. Znalost dané oblasti může být v méně optimální variantě kompenzována znalostí obdobných prací na rozsáhlejších ICT řešení. Pakliže nejsou zmapovány procesy „AS IS“ je otázkou do jaké míry je mapovat, pakliže dojde ke změně.

V průběhu sběru požadavků je důležité mít to, aby ti, co požadavky sbírají, měli patřičné „měkké dovednosti“, tak aby dokázali zaktivizovat úřad k dobré spolupráci. Tato oblast je ovšem těžko smluvně pod chytitelná, přesto ji zde uvádíme.

Další podmínkou dodání služeb je to že externí partner předá požadavky na nové ICT řešení, případně pakliže dochází i k mapování starého ICT řešení, tak i u něho, ve formátu architektury, kterému úřad rozumí. Míra detailu sběru architektonických požadavků má dopovídat jakou volnost dostane dodavatel ICT řešení, při dodávce svého díla. Stejně tento požadavek platí i pro procesní modely. Dále je požadavkem i dodání pohledů (zvolené grafické reprezentace) modelů pro rozhodování vedoucích pracovníků.

Jednou z podmínek, dle uvážení úřadu, je možnost stanovit výlučnost rolí. Dodavateli konzultačních služeb může být zakázáno účastnit se výběrového řízení na ICT řešení samotný, nebo poskytovat služby dodavatelům. Případně může dodavateli služeb na sběr požadavků být zakázány další navržené role.

V rámci chodu organizace je nutné sběr požadavků standardizovat, a to pomocí procesů, rolí a dedikovaným úložištěm. Je absolutně nezbytné všechny požadavky sepisovat a nevést je jen ve formě distribuované znalosti.

Zde navrhovaný systém sběru požadavků je využitelný i jako systém sběru požadavků v celé organizaci i na požadavky mimo oblast ICT a jde dále napojit i na další manažerské, informační, ekonomické (napojení na DNS) a jiné systémy. Díky mírným úpravám postupů a informačního systému je takovéto rozšíření jednoduché.

Nastavením jednotného stylu procesu dochází k jasnější a přehlednější správě procesu jako takového. Navíc se díky tomu proces sběru stává rutinní záležitostí, což přispívá k bezproblémovému chodu organizace.

Je nutné stanovit konkrétního pracovníka, osobu, který je za proces jako celek zodpovědný. Aby takový člověk mohl tuto odpovědnost přijmout, tak je povinné tomuto pracovníkovi zajistit mandát pro zajištění a řízení běhu tohoto procesu.

Úřad musí nastavit podmínky pro sběr požadavků v organizaci (a to i s externími partnery). Většina zaměstnanců úřadu nemá znalosti pro danou tématiku a je tedy úkolem úřadu poskytnou jim patřičné znalosti vhled a kontext do problematiky a její důležitost. Včetně motivačních prostředků, tak aby zapojení uživatelů bylo dostatečné.

Pro zajištění funkce sběru požadavků je nutné ustanovit odpovědnosti pro řízení sběru požadavků nejméně v následujícím rozsahu a za zlepšování procesu. Sběr požadavky by měl být řízen a podporován vrcholným řízením ICT.

V samotném sběru požadavků je nezbytné zajistit několik funkci a několik roli a to buď:

1. interně
2. externě
3. kombinací externích a interních zdrojů

Musí být ustanoven konkrétní pracovník, který má proces sběru požadavků jako svou odpovědnost Jeho úkolem je zajistit proces sběru požadavků jako takový. Nebo zajištovat sběry požadavků, kde je určen pracovník odpovědný za další pracovníky, kteří sbírají požadavky pro své ICT řešení.

Musí být stanoveny osoby, jež jsou odpovědni za požadavky jako takové. Jak v úrovni oblastí požadavků, tak v úrovni jednotlivých ICT řešení.

Horizontální pohled

Jsou dále pověřeni pracovníci, kteří odpovídají za konkrétní oblasti (portfolia) požadavků. Každá oblast (bezpečnost, GDPR, dokumentace) má svého správce požadavků. Viz. Zainteresované strany.

Vertikální pohled

Jsou dále ustanoveni pracovníci odpovědni za konkrétní ICT řešení, tak aby porozuměli potřebám, jež jsou kladeny na ICT řešení.

Vzhledem k širokému záběru informačních ICT řešení do jednotlivých aspektů a oblastí (jako je bezpečnost, architektura, udržitelnost a další) je doporučeno přiřadit tyto aspekty a oblasti ICT řešení (a k nim jejich požadavky) v rámci organizační struktury jednotlivým útvarům, jež mají znalosti a vykonávají danou roli.

Díky kontinuálnímu procesu sběru požadavků od jejich detekce až po jejich validaci předání lze sledovat současný stav ICT řešení a soubor požadavků, které jsou v procesu zpracování. Tyto požadavky jsou zapracovávány buď:

1. Průběžně – kdy v rámci uvolňovaní postupných update jsou zabudovávány. Převážně jde o opravy a bezpečnostní změny či menší změny.
2. Ve větší balíčcích – v případě dodávky nových větších funkcionalit

Vedení samotných požadavků musí být v souladu s interními a externími pravidly organizace. K vedení požadavků se mají používat centrální nástroje pro zprávu a vedení požadavků. Absolutním minimem, jež není doporučováno, je použití tabulkového editoru kde budou požadavky vedeny řádně. Avšak toto řešení nevyhovuje. Existuje celá řada nástrojů pro správu požadavků, které jsou dostupné jako:

1. Open Source řešení
2. Komerční balíkové řešení
3. Cloudové řešení

Jak bylo řečeno průběžně v celém tomto dokumentu, existence specializovaného dedikovaného úložiště je předpokladem pro efektivní komplexní správu požadavků v dané organizaci. Úložiště musí být téže aktivně spravováno tak, aby sloužilo jako aktivní, přístupný zásobník vědomostí a požadavků k nim.

Smluvně a organizačně je nezbytné stanovit (přiřazení rolí), s kým bude komunikováno a kdo má jaké oprávnění k odsouhlasení návrhů či změn. Jde o příslušnou míru delegace činností v organizaci a přidělení kontaktních osob z dodávajících společností. Dále musí být myšleno na to jak, kdy a jakým způsobem bude probíhat komunikace, se zajištěním prostředí, které zamezuje vzniku komunikačních bariér.

Jednou specifickou bariérou pro komunikaci zabývající se informatickými a komunikačními technologiemi (což je i sběr požadavků) je užití odlišného jazyka mezi věcným, byznysovým světem a světem informatiky.

Pro komunikace mezi externími celky (např, dodavateli) je určeno jednotné komunikační místo (Single Point of Contact), tak aby tento kanál byl zřetelně jasný.

Pro sběr požadavků, jejich analýzu a klasifikaci se používají následující techniky (výčet je pouze demonstrativní povahy):

1. Analýza materiálů (legislativa, strategie, další materiály)
2. Přímá účast (zadavatel, uživatel)
3. Pozorování (přímé, nepřímé)
4. Rozhovor (strukturovaný, polostrukturovaný, nestruktorovaný)
5. Dotazník a zpětná vazba
6. Návrhy a prototypy

Součástí procesu sběru požadavků je nezbytnost iterací procesu formulování požadavků. Žádné požadavky nemohou být nikdy dokonalé, ale cílem je v rámci zásad 3E dosáhnout 2 až 3 iteracemi dobrých požadavků. Součástí iterací nemusí být sběr požadavků na nejnižší úrovni, nebo při druhé iteraci. Další nezbytnou praxí je předvádění maket v průběhu sběru a předvádění prototypů v rámci vývoje, aby chyby mohli být napraveny v nejranějším stadiu realizace.

Všechny podněty k požadavkům by měli být sebrány (pakliže panuje nejistota, jestli něco je požadavkem nebo ne, tak to požadavek pravděpodobně je) i pakliže jsou na první pohled nevalidní (např. pro příští využití). V průběhu sběru vyhodnocování požadavků může dojít k situacím, kdy jsou požadavky na ICT řešení v konfliktu. Proto je nezbytné ustanovit kritéria priorit.

Důležitým prvkem je sledovatelnost požadavku v celém jeho cyklu. Proto musí být ustanovena pravidla pro jejich sledování

Na všechny fáze života ICT řešení je potřeba myslet na začátku, při vytváření požadavků na ICT řešení. Fáze životního cyklu informačního ICT řešení jsou rozpracovány v hlavním dokumentech jako příloh k Informační Koncepci ČR, zejména v dokumentu Metody řízení ICT.

Dost často se užívá pojem plánovaná životnost ICT řešení. Tato životnost je však vždy závislá na konkrétní aplikaci. Dále je nutno rozlišovat mezi životností agendy a jejího výkonu a životností aplikačního a technologické části tohoto ICT řešení.

Vrcholové požadavky a omezení, jenž se následně mají uplatnit. Jedná se zejména o plnění strategických cílů v zatím velice abstrahované podobě, tedy business objectives. Jejich uplatněním vznikají již jednotné principy, zásady, které tvoří základní rámec pro následný tvořený či užívaný ICT řešení. Těmito principy a zásadami se téže myslí architektonický pohled na věc a požadavky plynoucí z architektury úřadu.

Tato část obsahuje konkrétní Vize o funkčnosti (co má tedy ICT řešení dělat) konkrétního ICT řešení.

Tato fáze se dá rozlišit na dva základní režimy, po analýze, jež určuje dané přiřazení. Těmi jsou: typizované řešení a tvorba unikátního nového řešení. Zároveň v plánu dochází případně k přípravě rámcových smluv, které umožňují průběžně čerpání dle potřeby. Sběr požadavků jako metodika, která vyústí v jejich sesbírání a zpracování je následně použita pro výběr mezi možnostmi, které jsou uvedeny v následujících podkapitolách.

OVS vybírá optimální dostupní komerční řešení. Toto řešení však nemusí vždy úplně vyhovovat z důvodu specifických požadavků. Úprava tohoto řešení je rozvíjena standardizovanými metodami, které to umožňují, tato možnost úprav je reflektována už při pořizování.

Za COTS považujeme i Open Source, který je specifický tím, že je v samotném základu zdarma, ale podpora, či další funkcionality, jako je například rozvoj na míru, je již placená (pokud toto není řešeno vlastními zdroji).

V rámci konkrétní přípravy vzniká základní, rozsáhlý a detailně vyspecifikovaný seznam požadavků, které jsou kladeny na nové ICT řešení. Na základě tohoto seznamu dojde k vyhovení jednotlivých možných variant řešení. Z těchto řešení je vybráno to optimální, vzhledem k holistickému principu. Následně pokud dochází k dalším úpravám, či změnám zadání, je nutné tento prvotní seznam stále aktualizovat a verzovat.

V průběhu realizace při dobře nastavených požadavcích z minulé fáze se v této fázi akcentuje zejména implementace daných požadavků a jejich kontrola kvality (tedy shoda dle specifikace).

Avšak běžnou praxí je nutné být připraven i na další změnová řízení už i v průběhu samotné realizace. A to na základě režimu změnového managementu, kdy jsou nové požadavky vytvářeny a zpracovávány. Vyřešení těchto nových požadavků je však finančně mnohem náročnější, proto je důležité příčiny vzniku těchto požadavků minimalizovat.

Z hlediska učící se organizace se i při provozu musí monitorovat, uchovávat a spravovat v té době nově vyvstalé požadavky.

V této sekci se aktivně řeší provozní optimalizace, malé balíčky práce (workpackage). Téže jsou identifikované požadavky na zásadní změny, modernizace. Právě tyto zásadní změny a modernizace jsou následně přesunuty do fáze vyhodnocení.

Pro provozní optimalizaci se využívají manažerské metody typu PDCA (a jeho varianty, DMAIC, 8D), lean Six Sigma, které mohou využívat monitorovací nástroje pro optimilzace chodu systému.

V této části se vypořádávají a dávají podnět k realizaci zásadních změny a modernizace. Ty spolu se strategií a jejími změnami zahajují nový životní cyklus ICT řešení.

Exit strategie. ICT řešení samotná již při návrhu musí počítat s eventualitou ukončení ICT řešení, nebo částečného ukončení, řešení a udržitelnosti ICT řešení včetně problematiku přenosu dat z ICT řešení jako takového.

Prvním procesem je zjištění návazností na ostatní ICT řešení, pakliže tady tyty neexistují, či byly vyřešeny, tak je možné ICT řešení ukončit. Následně v takovémto ICT řešení jsou zbylá data vypořádána, buď aktivním přesunem do dalších částí infrastruktury, nebo svojí archivací. Archivována mají být nejen data, ale i stav, verze sestavení (build), a další data ICT řešení. Podchycení této fáze se provádí pomocí dostatečné dokumentace ICT řešení, datového modelu a přístupům ke kódu. Z tohoto hlediska se jedná o nastavení dostatečné kvality nefunkčních požadavků a právních vztahů. Je možné si představit, pakliže k ICT řešení máme plná práva, že dojde pouze k částečnému ukončení části ICT řešení. Tato dílčí část ICT řešení se následně může využít v dalších řešeních.

Správa požadavků v organizaci je komplexní činnost, která se dotýká více vrstev správy požadavků, kde cyklus je stejný, avšak je realizován na několika různých vrstvách. Požadavek může být přenesen z nižší vrstvy na nižší a na opak. Vrstvy jsou z pohledu z vrchu dolů následující:

1. Národní vrstva (Ovšem tu úřad nerealizuje sám)
2. Vrstva celého úřadu
3. Vrstva skupiny ICT řešení / skupiny systémů (pro něž je realizován strategie provozu ICT řešení)
4. Vrstva ICT řešení / systému
5. Modul ICT řešení / subsystému
6. Služba / funkce

V předchozích kapitálách bylo řečeno, že s požadavky jde provádět indukce (domyšlení souboru požadavků) a dedukce (z obecného požadavku vytvořit požadavek dílčí). Tato činnost se děje ve stejné vrstvě.

Hewitt, Eben. 2018. Technology Strategy Patterns. Sebastopol : O'Reilly Media, Inc., 2018.

ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 29148:2011(E). Systems and software engineering — Life cycle processes — Requirements engineering. 2011.

Wiegers, Karl Eugene. 2013. Software Requirements, Third Edition. Redmond : Microsoft Press, 2013.