Překlady této stránky:

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.

Příklad:

Úřad provozuje nevyhovující informační systém, jehož obnova dle dále navrhovaných kritérií a skutečných potřeb úřadu by byla dražší než pořízení nového informačního systému. Ovšem skutečnou cenu rekonstrukce stávajícího systému, stejně jako skutečnou cenu nového informačního systému lze zjistit pouze zpětně po jeho provozování. Avšak na základě analýzy potřeb úřadu ve formě funkčních a nefunkčních požadavků lze stanovit rozsah prací, následně vyhodnotit jednotlivé varianty a tuto analýzu mít jako podklad pro následné uskutečnění výběrového řízení v dané optimální variantě.

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ázek1)
  • 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.

Příklad:

Jako jeden z výkonných pracovníků úřadu jste byli pověřeni zpracováním základního konceptu pro modernizaci řešení digitalizace interního archivu. Toto zadání bylo provedeno netechnickým jazykem, proto jste jej v dialogu přetransformovali na podklad nových funkcionalit a požadavků na ICT řešení.

Vzhledem k tomu, že se nejedná o zcela nové řešení, tak se již užité řešení musí reflektovat. Důslednou správou požadavků existuje přehled o požadavcích na nynější provozovaný systém, jak těch výchozích, tak i požadavků změn, které byly buď zapracovány, nebo jsou v řešení. Díky tomu je možné získat expertní a komplexní přehled i o nynějším stavu.

Syntézou stávajícího stavu s nově zadanými parametry je jasná představa o nutných změnách v relaci na tyto požadavky. Ta se dá následně užít při dalším zpracování (gap analýza, analýza nákladů a přínosů, následná transformace na požadavku pro zadávací dokumentaci).

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.

Ekonomické dopady špatných požadavků

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

Právní dopady špatných požadavků

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é.

Nesplnění principů ze zákona o zadávání veřejných zakázek

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).

Péče řádného hospodáře

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, respektive nefunkčnost IS s dopadem na výkon agend úřadu

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).

Narušení kybernetické bezpečnosti

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.

Efektivita (efficiency)

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 (effectiveness)

Úč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 (economy)

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ů

Úroveň Byznys Arch ICT
L0 Spor o zdroje (peníze, kvalitu)

Byznys poskytuje peníze, ICT realizuje schopnosti a tím poskytuje nové možnosti byznysu, což umožňuje transformaci na základě přístupu ICT tažené organizace2), jenž má za důsledek flexibilní a efektivní řízení a správu (governace)

V případě dlouhodobého podfinancování se schopnosti snižují, či dokonce přestávají existovat.
Národní strategie Spor mezí tím, co se má dělat (samotný byznys) a jak se to má dělat (architektura)

Byznys poskytuje rozsah operací a vstupy pro tvorbu architektury

Architektura přidává vhled do těchto operací.
IKČR,

MŘICT,

NAP,

NAR
Spor mezí architektonickou vizí, plány a skutečností

Architektura řeší standardizuje, ICT koná

Výstupem sporu je flexibilita řešení versus vzniklá rigidita napojená na architektonické vzory a stavební bloky
IKČR,

Globální technické předpisy, provedení,

standardy
L1 Strategie úřadu IK OVS IK OVS
L2 Sektorová Architektura OVS Relevantní část IK OVS
L3 Část sektorové strategie Část architektury OVS Výsek relevantní části IK OVS

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 2media_image2.jpg – Základní fáze životního cyklu ICT služby VS a jejich návaznosti

Úroveň Funkce Popis Role Popis
Gesce/
Věcný správce/

Byznysová vrstva / ohlašovatel agendy
Gestor/
Věcný správce
Spravuje problematiku a zároveň může mít vliv na změnu prostředí (legislativa a strategie) Byznys analytik v úrovni gesce Je zde zejména v dohledové, přehledové a koncepční roli.
Vykonavatel Vykonavatel Spravuje problematiku rámci byznys procesu a zároveň může podat podnět ke změně agendy směrem ke gestoruByznys analytik v úrovni věcného správce Co ICT řešení má svým výkonem zajišťovat. K čemu tedy slouží. Jak má vypadat provozně a procesně, tedy v netechnické rovině
Technický správce Technický správce Technicky zajištuje výkon agendy Analytik v úrovni technického správce AKA Technický analytik, IT analytikZajištuje technický aspekt věci

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 pohybuje3). 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 legislativu4)
  • 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ě.

Byznysové procesní modelování

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é byznysové procesní modelování

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 souladubyznys cíly, strategickým konceptem provozu ICT řešení a operačním konceptem provozu ICT řešení .

Nízkoúrovňové byznysové procesní modelování

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í agend5) (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 provozu6) 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

Core vs Context Business

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.

Core business Context business
Velká pravděpodobnost vendor lock-inu

Řešení bude muset být vyvíjeno na míru

Typicky Agendové informační systémy
Menší pravděpodobnost vendor lock-inu

Budou existovat typizovaná řešení

Typicky docházkový systém

Prostředková typizace provozu

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

Vyšší míra vlastního řešení Nižší míra vlastního řešení
+
Vyšší kontrola

Možnost vyšší kybernetické bezpečnosti

V dlouhém měřítku může být levnější

-

Nižší flexibilita
+

Vysoká flexibilita

Možná lepší prvotní nastavení kybernetické bezpečnosti

V krátkém měříku může být výhodnější

-

Nižší kontrola

Příklad:

Dle usnesení <doplnit> je dnes povinnost zohlednit při budování ICT řešení veřejné správy užití eGovernment cloudu a využít ho, pokud je cloudové řešení vhodné. Kde snahou je upřednostnit a soustředit se na byznysový proces samotný, neboť k technický aspekt řešení je přesunut na externí dodavatele/cloud. Úřad úřaduje, eGoverment se stará. Dle přiložené grafiky (obrázek 3) se jedná o zvolení jednoho z více flexibilních řešení, v eGovernement cloudu tedy SaaS (BPaaS zatím není v eGov cloudu obsažen). Pokud takové řešení není rentabilní, tak se zvolí méně flexibilní v pořadí PaaS, IaaS, On-premise.

Avšak již nyní obecně je doporučené rozdělit hardwarovou a softwarovou část tak, aby se dala tvořit flexibilní modulární řešení. Díky tomu se otevírá možnost znovu-použitelnosti, sdílení služeb, virtualizace, kontejnerizace a přístupu SOA (službově orientovaná architektura). Rozdělením na hardwarovou a softwarovou část je nejen umožněno nasazení do cloudu, ale i díky tomuto rozdělení je implementace cloudového řešení usnadněna.

Časový horizont provozu ICT řešení

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

Dlouhý provoz Krátký provoz
Robustnější řešení, dobře definovaná exit strategie, s možným postupným odchodem.Možnost méně robustního řešení. Jednoduchá, avšak účiná, exit strategie vyplývá z definice zadání.

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.

Příklad:

Strategií úřadu je převést všechny provozní systémy do privátního cloudu. Po vybudování eGov cloudu se úřadu vyplatí dát všechny své provozní systémy do veřejného cloudu a tak to i učiní.

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ů.

Způsob specifikace stavebního bloku Znovu využití sběru požadavků
Služba Využití sběru požadavku je dvojí v rámci jednoho sběru

* Sběrem požadavků dojde k navržení centrální služby. Zde jako poskytovatel mám službu specifikovanou (funkčnost služby, rozhraní) s definovaným možnostmi užití. Pro odběratele služby vytvořím (poskytovatel ji může i sám využívat) požadavky na danou službu pro její využití, včetně specifikace, jak službu propojit. Tímto sběrem dojde i ke specifikaci požadavků pro odběratele služby.
* Pro odběratele služby vznikne povinnost použít výše vyspecifikované požadavky pro svůj ISVS, který vytvořil poskytovatel služby.
Open source Užití open sourcových řešení je při užití centrálního sběru a případného katalogu požadavků a k něm dostupným řešením je vícero:

* Jako základ komunikace projektu s komunitou
* Aby ostatní uživatelé věděli, jaké open sourcové řešení jsou k dispozice s detailní popisem funkčnosti.
* Otevřené možnosti přidání dalších funkcionalit dalším projektem.
* Další podklad pro přímo společný projekt.
* Dále z toho může být vytvořen národní standart z původního zadání
Národní standard * Pokud v rámci sběru požadavků dojde k vytvoření uceleného souboru požadavků, jenž svojí charakteristikou zcela naplňuje charakteristiku stavebního celku. A daný subjekt má potřebný mandát. Poté je možné tento stavební blok prohlásit za národní standard a všechny ostatní dále budovaná řešení ho musí splňovat.
* Existuje-li národní standard, a následně z něj open source vznikne, tak stavební blok může být naplňován Open Sourcem (avšak referenční je národní standard)
Společné výběrové řízení * Vytvoří společný rámec pro výběrová řízení.
* A možný podklad pro vznik dalších forem stavebních bloku.
Vybudován jedním OVS (nebo pověřeným komerčním subjektem) za účelem poskytování za úplatu (např. převodem rozpočtové položky).* Úřady přesně vědí, pakliže se podílí na nakoupení stavebního bloku, co nakupují s jasně definovanými požadavky
* Úřad přesně ví, co může přesunutím rozpočtové položky sdílet s jinými úřady
* Nebo možný podklad pro vznik dalších forem stavebních bloků

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

Modularita ve vtahu k řízení jednotlivých modulů a jejich životních cyklů

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.

Příklad:

Mějme celostátní informační systém veřejné správy. Obsáhlejší změnou legislativy dochází ke změnám v procesech, jenž jsou technicky podporovány a řešeny několika dílčími komponentami (moduly). V případě této změny stačí upravit pouze tyto moduly a není nutné zasahovat do zbytku informačního systému.

Mějme informační systém, kde analytický sub-systém zastaral. Díky modularitě řešení je analytický možno nahradit snadno a to řešením, jež podporuje nejmodernější trendy v oblasti analýzy dat (např. strojové učení, velká data).

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é.

Příklad:

Mějme informační systém s celorepublikovou působností. Systém sice „moduly“ obsahuje, avšak jsou dodávány pomocí jednoho dodavatele. Navíc tyto moduly jsou propojeny proprietárním komunikačním rozhraním z dílny toho stejného dodavatele. Přestože systém obsahuje „moduly“, tak se nedá říci, že naplňuje princip modularity popisovaným a doporučovaným v této metodice.

Modularita podpořená více dodavateli – manažerské zajištění integrace na straně objednatele

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.

Typ modularity Výhoda Nevýhoda
Nemodulární ICT řešení od jednoho dodavatele V případě jednoduchých ICT řešení je to levné. Nelze upravovat, nebo velice draze.
Modulární ICT řešení od jednoho dodavatele Lze upravovat ICT řešení a integrace proběhne pravděpodobně hladce. Otázka je míra modularity, jestli části ICT řešení jsou skutečně modulární a rozhraní je technologicky neutrální.
Modulární ICT řešení od jednoho dodavatele s možností náhrady jednoho modulu bez narušení hlavní smlouvyLze upravovat ICT řešení a integrace proběhne dobře a obměňovat komponenty je možné dle potřeby. Otázka je míra modularity, jestli části ICT řešení jsou skutečně modulární a rozhraní je technologicky neutrální. Je nutné zajistit spolupráci prvního dodavatele i při pro něj nevýhodné situaci.
Modulární ICT řešení od více dodavatelů s integrací jako sub dodávkou Lze upravovat obměňovat komponenty zcela běžně.

Zkušenosti z integrace jsou přenášeny do další externí organizace (ovšem i vztah s ní je nutno řídit).
Je nutno zajistit dobré rozvržení rozhraní a spolupráce. Jakékoliv zpoždění či nefunkční stav na jakékoliv nezbytné komponentě způsobuje ohrožení projektu.
Modulární ICT řešení od více dodavatelů s vlastní integrací Existuje vysoká znalost o ICT řešení uvnitř organizace a velká část přidané hodnoty vzniká uvnitř organizace. Změny jsou snadné. Uvnitř úřadu musí existovat schopnost řídit komplexní projekty rychle a efektivně. Musí existovat schopnosti vývoje vlastních celků (již jen pro schopnost sub dodávek). A to vše na úrovni komerčních firem.

Dále je nutno zajistit dobré rozvržení rozhraní a spolupráce. Jakékoliv zpoždění či nefunkční stav na jakékoliv nezbytné komponentě způsobuje ohrožení projektu ICT řešení.

Příklad:

Úřad si rozhodl rozdělit informační systém na několik zakázek, které budou vytvářet jednotlivé moduly. Úřadu se podařilo vy soutěžit a získat tři za čtyř modulů pro nový systém, jež nahrazuje nevyhovující. Ale díky absenci čtvrtého modulu nemohl být systém spuštěn a úřad byl donucen prodloužit podporu na stávající nevyhovující systém. Nový systém mezitím zastarával díky jeho nespuštění. Projekt nebyl dostatečně časově, manažersky a schopnostmi integrace zajištěn. A tak vznikl situace, která je značně neoptimální.

Jiný úřad si pořizoval rozsáhlý systém, kde jako součást exit strategie je možno ukončit spolupráci na částech pořizovaného systému (který je modulární) dle požadavku úřadu.

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.

Příklad:

Nechť je v existence informační systém, jenž schraňuje důležitá data. Tento systém je provozován (vysoutěžen) soukromou firmou. Následně v průběhu provozu byl tento systém postižen kritickým výpadkem, kdy došlo k neobnovitelné ztrátě dat. Tento typ události byl smluvně ošetřen, avšak nebyla smluvně stanovena žádná sankce. Úřad, tedy přišel nenávratně o data a navíc dále ani nebyl schopen vymáhat kompenzaci za tento výpadek.

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ů.

Úroveň Tvorba Kontrola
Solution architecture Tvorba návrhu Solution Architektury Kontrola návrhu Solution Architektury
Solution Design Tvorba návrhu Solution designu Kontrola návrhu Solution design
Funkční a nefunkční požadavkyTvorba souboru funkčních nefunkčních požadavkůKontrola funkčních nefunkčních požadavků
Zadávací dokumentace Tvorba zadávací dokumentace Kontrola zadávací dokumentace
Dodávka díla Dodávka díla Kontrola dodávky díla
Nasazení díla Nasazení díla Kontrola nasazení díla
Provoz Provoz díla Kontrola provozu díla

Příklad:

Středně velký úřad se rozhodne pořídit nový informační systém. Návrh Solution architektury a funkční a nefunkční požadavků si nechá dodat od externího poradce s dobrými referencemi. Kontrolu jim dodaného návrhu zvládne sám. Solution design je ponechán v rukou dodavatel, pakliže se bude držet vymezených mezí Solution architektury Zadávací dokumentaci včetně návrhu smluv si nachá zpracovat od renomované právní kanceláře. Přebrání díla zajistí poradce. Na implementaci vypíše další výběrové řízení (protože k němu má již dokumentaci z předchozích kroků).

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:

Princip 3E Způsob narušení Příklad:
Efektivita (efficiency) Systém nesplňuje parametry pro efektivní systém Práce v systému je neefektivní a zdlouhavá
Účelnost (effectiveness)Prostředky na chod systému jsou vynakládány neúčelněSystém má zbytečné funkcionality
Hospodárnost (economy) Systém je nákladné udržovat Náklady na systém jsou disproporčně veliké

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).

Příklad:

Úřad provozuje podnikový ekonomický systém v nevýhradní licenci. Vznikl požadavek na vytvoření specifické funkcionality. Tento modul již úřad otevře jako open source, protože je očekávané situace že další uživatelé onen otevřený modul (byť třeba v proprietárním jazyce) použijí též a dojde k jeho rozvoji.

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)

Licence Výhoda Nevýhoda
Open Source * Pomáhá k eliminaci vendor lock-inu
* Na vývoji mohou participovat další zúčastnění.
* V případě oblíbených open source řešení dochází k jeho širokému rozvoji
* V některých situacích může být otevřenost kódu nevhodná
* Nutné si zajistit podporu a záruku
(ovšem ani komerční sofware nutě nepřichází s podporou)
Vlastní řešení * Pomáhá k eliminaci vendor lock in
* Plné vlastnictví umožňuje možností transformaci vlastnictví
* Může být vytvořeno velice obskurní dílo, takže stejně ho bude umět spravovat jen jedna strana
* Může technologicky zaostávat oproti celosvětovým technologickým trendům
Komerčně dostupný software * Může poskytovat pokroková řešení * Riziko vendor lock inu
* Nutno velice pečlivě řídit vztahy s dodavateli
Software sdílený ve státní správě* Může být dosaženo na vlastnictví softwaru, který by jinak nebylo možné získat v podobné ceně/ kvalitě * Komplikovaný proces pořízení a řízení vztahů
Služby * Nejsou počáteční investiční náklady
* Přechod může být plynulejší
* Můžou dobře řešit dočasné požadavky
* V dlouhodobém horizontu se nemusí vyplatit
* Nelze ze své podstaty do těchto služeb nikdy investovat.
* Nutno připravit dobrou migrační politiku
(to je zapotřebí všude, avšak je potřeba myslet na specifika služeb)

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ý.

Příklad:

Úřad si chce koupit antivirový software, vlastní nebo zakázkový vývoj nemá cenu, takže je zvolena varianta nákupu standartních licencí.

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.

Příklad:

Úřad chce spustit nový agendový informační systém. Dodavatel dodá informační systém, kde servery jsou provozovány na operačním systému v režimu Open Source, ale dodavatel zajištuje podporu. Protože úřad již provozuje značnou část svým databází jako komerční a běžně dostupné řešení, bude tato databáze implementována do současného řešení (tento krok je opřen o informační koncepci daného úřadu). Část systému obsahuje řešení, jež plně vlastní úřad.

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

Open source

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.

Komerční software s nevýhradní licencí

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

Vlastní kód (v plném vlastnictvím a výhradní licencí) nakoupený či vyvinutý na míru

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.

Software sdílený ve státní správě

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.

Práva stran, autorská práva majetková a osobní

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á)).

Příklad:

Úřad si chce nechat vyvinout část řešení pod otevřenou licencí. Součást podmínek dodání díla je i vypořádání i autorského právo osobního. Autoři díla dají souhlas k využití jejich díla v rozsahu dané licence.

Další rozvoj

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

Činnosti související se zaváděním nového ICT řešení

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.

Stanovení byznysových cílů

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ů

Záměr pořízení nového ICT řešení

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.

Organizační změny a změny kompetencí

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.

Zajištění dlouhodobého financování

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.

Školení

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.

Příležitosti

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.

Řízení ICT řešení

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

Provoz ICT řešení

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

Obsluha ICT řešení

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

Rozvoj ICT řešení

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.

Definice požadavku

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)

Opodstatněnost požadavků

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

Typizace a hierarchizace požadavků

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í.

Hierarchizace požadavků

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.

Typy požadavků

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)

Vlastnosti samotného požadavku

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ý.

Atributy požadavků

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í.

Kontinuální sběr požadavků

V rámci systému řízení (tj. plánování, budování, nákupu a rozvoje) ICT technologií7) 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.

Příklad:

Úřad vede sběr požadavků kontinuálně díky změně legislativy o oblasti GDPR je tento požadavek zaznamenán a při pravidelné údržbě systému je implementován do všech systému, kterých se tento požadavek týká.

Sběr požadavků ke konkrétnímu ICT řešení

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říklad:

V konkrétním systému je zaznamenán požadavek na zavedení flexibilní work-flow podpory. Tento požadavek se přenese i do obecné sbírky požadavků a je zařazen pro implementaci u relevantních systémů.

Sběr požadavků dle postupu sběru

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ů

Rekursivní sběr 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.

Příklad:

Při sběru požadavků na IS existuje požadavek, aby IS komunikoval se současnými systémy. Z toho plny že, současným systémem je i spisová služba. A z toho plyne, že komunikuje přes rozhraní, které má technické specifikace.

Iterativní vývoj

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.

Příklad:

Při sběru požadavků připomene bezpečnostní odbor, že komunikace IS má být šifrována. Šifrována má být, protože je to součástí bezpečnostní politiky. Soulad s bezpečnostní politikou byl zahrnut do souboru požadavků.

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.

Dělení na zainteresované strany a jejich třídy

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.

Příklad:

Při sběru požadavků na novou spisovou službu je kromě zainteresované strany „uživatelé“ vedeny i její třídy. „zkušení uživatelé“, „noví uživatelé“ a „uživatelé specifické agendy X“. Dále například administrátoři.

Minimální okruh zainteresovaných stran

Vedení organizace – management

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.

Přímí uživatelé

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.

Nepřímí uživatelé

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.

Ekonomická oddělení

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

Právní oddělení

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 – bezpečnostní odbor

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

Architekt úřadu

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.

Pověřenec pro ochran osobních údajů (Data protection officer)
Hlavním úkolem pověřence pro ochranu osobních údajů je návrh pravidel pro ochranu osobních údajů a dalších práv, jež vyplívají ze směrnice GDPR.

Širší okruh zainteresovaných stran

Věcní správci – gestoři

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.

Oddělení rozvoje IT

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.

Oddělení provozu IT

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

Klienti veřejné správy – občané

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.

Příklad:

Buduje se nová aplikace do portálu občana. Občany nelze zahrnout jako takové do interních pracovních postupů. Ovšem reprezentativní vzorek občanů je konzultováni pomocí dotazníků a hloubkových rozhovorů.

Sponzor projektu

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

Příklad:

Typický sponzorem projektu může být EU, která určuje podmínkami dotací business požadavky, které jsou nepřekročitelné. Např.: „Systém musí být provozován 5 let.“ Z čehož plyne požadavek na udržitelnost celého systému na 5 let provozu. Dalším sponzorem může být stát, v rámci dotací ze státního rozpočtu. Nebo kraje, které poskytnou dotace na rozvoj IS obcí, ale s podmínkou že IS musí být schopny přesunu do technologických center kraje.

Skryté zainteresované strany – negativní vlivy na projekt

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

Signifikantní požadavky

Nastavení komunikace

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ě.

Kvalita kódu a dopad na udržitelnost systému.

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)8)
    • 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.

Sekvenčně je postup požadavku k funkční implementaci následující:

  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í
Změnový management

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.

Návaznost na dokumenty: Informační koncepce úřadu, Informační koncepce úřadu, ICT koncepce resortu, Strategické koncepce úřadu, Věcné koncepce úřadu,
Na kolik systému se vztahuje:Na jeden konkrétní, na skupinu konkrétních, skupinu tematickou (např.: podpůrné systémy, provozní systémy), nebo na všechny systémy
Připravuje: IT obory ve spolupráci s věcnými gestorem či gestory
Schvaluje: Vedení

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ů.

Návaznost na dokumenty: Strategický koncept provozu ICT řešení
Na kolik systému se vztahuje:Na jeden konkrétní
Připravuje: IT obory
Schvaluje: Věcný gestor

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ů.

Dodávka externí pracovní síly

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.

Dodávka know-how sběru požadavků

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ě.

Dodávka znalosti oboru nebo řízení velkých informačních ICT řešení

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ě.

Dodávka leadership dovedností pro aktivizaci pracovních sil

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.

Dodávka služeb ve formátu architektury úřadu a zavedeného procesního modelování

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ů.

Výlučnost rolí

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é.

Příklad:

Při zavedení systému sběru požadavků organizace ví jaké požadavky a v jakém počtu (pakliže byli katalogizovány) jsou vyžadovány. Tento systém lze využít i pro položky, jež se nepojí s ICT. Díky katalogu si odbor úřadu vyžádá novou kancelářskou židli, tento požadavek je validován ekonomickým oddělením a židle je dodána. Stačí, že v systému je kategorie ne-ICT požadavků. Některé požadavky mohou být absolutně bez katalogového zařazení, např. požadavek na zavedení klimatizace do objektu. Ovšem požadavek je evidován pro další využití.

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é.

Příklad:

Mgr. Adolf Slovák je referentem na svém oddělení již 10 let. Díky úzké pracovní specializaci mu nejsou dány známy okolnosti pro sběr požadavků na nové ICT řešení. Při předávání požadavků opomene to, že potřebuje export dat ze systému ve formátu “.xlsx“. Díky tomuto opomenutí systém neplní svojí hlavní roli primární evidence ekonomický případů. Referent si stále vede oddělenou tabulku s daty a dobudování této funkcionalitu by stále mnoho prostředků.

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.

Příklad:

V organizaci byli zavedeny kromě jiných rámců řízení i standardy ISO 20 000 a ISO 38 500, které jako jednu ze svých požadavků řeší:

odpovědnost – vedení vůči fungování IT, tak i odpovědnost určit odpovědnosti konkrétním pracovníkům

soulad ICT řešení – s obecnými tak i vnitřními pravidly, jak na technické úrovni, tak i na právní.

V takové organizaci již existuje rámec tedy jak zavést procesy řízení ICT.

Zajištění rolí v procesu

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ů
Odpovědnost za proces a zajištění sběru

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í.

Příklad:

V organizaci pracuje Ing. Petr Sbíravý je vedoucím oddělení rozvoje IT. Je pověřen svým náměstek a popisem práce, jako odpovědný pracovník za sběr požadavků ve své organizaci. Existuje nástroj pro sběr požadavků v organizaci, se kterým jsou seznámeni a proškoleni účastníci procesu a oddělení pan Ing. Sbíravého věcně odpovídá za tento nástroj.

Odpovědnost za požadavky

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.

Příklad:

Ing. Antonín Lorenc je vedoucím bezpečnostního odboru, ten zodpovídá za oblast bezpečnostních požadavků.

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í.

Příklad:

Mgr. Jan Psavý je pověřen sběrem požadavků na spisové služby je odpovědný za to, že požadavky na spisovou službu jsou sebrány řádně.

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.

Příklad:

Role GDRP zmocněnce je jednou ze standardizovaných rolí. Pracovník vykonávající tuto rolu v případě tvorby či změně ICT řešení se účastní jednání za svoji oblast (zde tedy GDPR), přináší, vytváří, spravuje požadavky v této oblasti a v rámci procesu je za ně odpovědný a udržuje je v specializovaném a dedikovaném uložišti.

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.

Komunikace

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ý.

Techniky sběru požadavků

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.

Řešení sporů v požadavcích a nevalidní požadavky

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.

Spor Na jaké úrovni Nutnost priorit Kdo rozhodne (návrh)
HorizontálníSpor v oblasti byznys požadavků Ustanovit priority byznys požadavků Vedení organizace
HorizontálníSpor v oblasti požadavků zainteresovaných stran Ustanovit hierarchii zainteresovaných stran, uživatelský tříd a skupin Vlastník projektu
HorizontálníSpor v oblasti systémových požadavků Ustanovit priority v oblasti systémových požadavků, nebo najít řešení, jež vyhovuje konfliktním požadavkům Ten, kdo navrhuje Solution architecture nebo solution design schvaluje vlastník projektu
Vertikální Spor mezi byznys požadavky a požadavky zainteresovaných stran Učit hranici (např. zákonná povinnost) kdy požadavky zainteresovaných stran, jsou důležitější než byznys požadavky, ačkoliv jsou přednější. Vlastník projektu
Vertikální Spor mezi požadavky zainteresovaných stran a systémovými požadavkyUčit hranici (např. absence ekonomické technologického řešení), kdy systémové požadavky jsou důležitější než požadavky zainteresovaných stran, ačkoliv jsou přednější.Zainteresovaná strana eskaluje k vlastníku projektu

Trasovatelná matice požadavků

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í.

Příklad:

Mějme agendu registru obyvatel (ROB), tato agenda bude vykonávána (pravděpodobně) v dnešním stávajícím, či obdobném rozsahu vždy. To samé platí o rozsahu zpracovávaných a uchovávaných dat. Avšak aplikační a technologický aspekt informačního systému se bude (pravděpodobně) měnit a vyvíjet (dle historie papírová evidence, dnes centrální digitální registr).

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í.

Příklad:

Resort má zřizovanou organizaci s širokou pobočkovou sítí. Ovšem strategie resortu hovoří o centralizaci podpůrných služeb, ale zachovat širokou sít poboček, kde nadále bude pomáháno klientům veřejné správy a části klientů bude vyhovovat aplikace na portálu občana, Z čehož může vzejít požadavek na centrální Cloudové řešení, avšak s mnoha koncovými body, kde jedna část systému má moduly pro řadového pracovníka stání správy a další modul zajištuje portál občana.

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.

Komerčně dostupné, balíkové řešení, COTS

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).

Nové řešení

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ě.

Příklad:

Požadavky na bezpečnost jsou dobře známy, ale pro příklad uveďme situaci, kdyby nebyly.

Byl vznesen požadavek, aby data uložená v subsystému byla šifrována. Indukcí dojede na to, že mají existovat bezpečnostní požadavky. Námět na kategorii bezpečnostní požadavků je přenesen výše na úroveň celého systému, následně skupiny systému, úřadu a celorepublikovou úroveň. Dále požadavek na bezpečnost je přenesen i níže na úroveň funkce

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.


2)
ICT driven organization
3)
Určitou výjimkou jsou krajská zastupitelstva, které mohou zprostředkovat potřeby krajského úřadu pro návrh změn legislativy.
4)
https://ria.vlada.cz/dokumenty/
6)
Společně tvoří význam angl. slova „deployment“.
7)
Lze využít ISO/IEC 38500:2015
8)
Viz konsorcium: Consortium for Information & Software Quality https:%%//%%www.it-cisq.org/
Vložte svůj komentář: