TECHNICKÁ SPECIFIKACE K VEŘEJNÉ ZAKÁZCE

TECHNICKÁ SPECIFIKACE

K VEŘEJNÉ ZAKÁZCE

„Pořízení HW a SW vybavení – Zvýšení kybernetické bezpečnosti významných ISKÚ pro PO zavedením nových technologií (nástrojů)“

dále též jen „Veřejná zakázka“

Obsah

1 Technologie a zkratky 4

2 Informace k veřejné zakázce 6

2.1 Důvody vyhlášení veřejné zakázky 6

2.2 Cíle projektu 7

3 Předmět veřejné zakázky 7

3.1 Současný stav 7

3.2 Požadované služby a dodávky 9

3.2.1 Podrobný návrh cílového konceptu řešení 9

3.2.2 Požadované služby a dodávky NGFW 9

3.2.3 Požadované služby a dodávky k IDM 9

3.2.4 Požadované dodávky a služby SAIW 10

3.2.5 Provádění dalších aktivit souvisejících s provozem a rozvojem řešení 10

4 Architektura řešení 11

4.1 Technologická architektura 11

4.2 Aplikační architektura 12

5 Technická specifikace NGFW 13

5.1 Obecné požadavky na cílové řešení NGFW 13

5.2 Funkční a nefunkční požadavky na řešení 14

5.2.1 Funkční a nefunkční požadavky technologie NGFW 14

5.2.2 Dodávka potřebných licencí k produktu 14

5.2.3 Školení 14

5.2.4 Uvedení pilotního provozu HW a SW vybavení a všech naimplementovaných řešení v rámci projektu  14

5.2.5 Uvedení systému do produkčního provozu  14

5.2.6 Údržba systému 14

5.2.7 Standardní podpora systému 16

5.2.8 Nadstandardní podpora systému 20

5.2.9 Znalostní podpora a provedení nezbytných úkonů při ukončení ▇▇▇▇▇▇▇ a předání služeb na jiného dodavatele 20

6 Technická specifikace IDM 22

6.1 Obecné požadavky na cílové řešení IDM 22

6.1.1 správa prostřednictvím portálu, 22

6.1.2 Funkční a nefunkční požadavky na řešení 23

6.1.3 Implementace řešení 23

6.1.4 Dodávka potřebných licencí k produktu 23

6.1.5 Školení 23

6.1.6 Uvedení pilotního provozu HW a SW vybavení a všech naimplementovaných řešení v rámci projektu  23

6.1.7 Uvedení systému do produkčního provozu  23

6.1.8 Údržba systému 24

6.1.9 Podpora systému 25

6.1.10 Znalostní podpora a provedení nezbytných úkonů při ukončení ▇▇▇▇▇▇▇ a předání služeb na jiného dodavatele 29

7 Technická specifikace SAIW 31

7.1 Obecné požadavky na cílové řešení SAIW 31

7.1.1 Funkční a nefunkční požadavky na řešení 31

7.1.2 Implementace řešení 31

7.1.3 Dodávka potřebných licencí k produktu 31

7.1.4 Školení 31

7.1.5 Uvedení pilotního provozu HW a SW vybavení a všech naimplementovaných řešení v rámci projektu  31

7.1.6 Uvedení systému do produkčního provozu  31

7.1.7 Údržba systému 32

7.1.8 Standardní podpora systému 33

7.1.9 Znalostní podpora a provedení nezbytných úkonů při ukončení ▇▇▇▇▇▇▇ a předání služeb na jiného dodavatele 38

1Technologie a zkratky

Název pojmu / zkratka	Popis / definice
AD	Active Directory
API	Application Programming Interface
BOZP	Bezpečnost a ochrana zdraví při práci
CMS	Content Management System
DC	Datové centrum
DMZ	Demilitarizovaná zóna
DPH	Daň z přidané hodnoty
ESX	Bare-metal hypervisor od VMware
FW	Firewall
GDPR	Obecné nařízení o ochraně osobních údajů
GINIS	Bezpečná integrační platforma pro veřejnou správu s garantovanou legislativou
HA	High-availability
HTCK	Hlavní technologické centrum kraje
HTTPS	Hypertext Transfer Protocol Secure
HW	Hardware
ICT	Information and Communications Technology
IDM	Identity Management
IS	Informační systém
KÚ	Krajský úřad
KÚSK	Krajský úřad Středočeského kraje
LAN	Local Area Network
MAN	Metropolitan Area Network
MFA	Multifaktorová autentizace
NGFW	Next-Generation Firewall
NTB	Notebook
OS	Operační systém
PC	Personal computer
PO	Příspěvková organizace
PRINCE	Projects In Controlled Environments
RDP	Remote Desktop Protocol
SAIW	Systém pro automatizaci incidenčních workflow
SAN	Storage Area Network
SčK	Středočeský kraj
SLA	Service-Level Agreement
SOC	Security Operations Center
SQL	Structured Query Language
SW	Software
TCK	Technologické centrum kraje
TOGAF	The Open Group Architecture Framework
VIS	Významný informační systém
VPN	Virtual Private Network
WF	Workflow
ZD	Zadávací dokumentace
ZKB	Zákon o kybernetické bezpečnosti
ZoISVS	Zákon o informačních systémech veřejné správy
ZoKB	Zákon o kybernetické bezpečnosti
ZTCK	Záložní technologické centrum kraje
ZTNA	Zero Trust Network Access
ZZVZ	Zákon o zadávání veřejných zakázek

2Informace k veřejné zakázce

2.1Důvody vyhlášení veřejné zakázky

Veřejná zakázka s názvem „Pořízení HW a SW vybavení – Zvýšení kybernetické bezpečnosti významných ISKÚ pro PO zavedením nových technologií (nástrojů)“ (dále jen „Veřejná zakázka“ nebo „Zadávací řízení“) je veřejnou zakázkou na dodávky. Je realizovaná v rámci projektu „Zajištění kybernetické bezpečnosti pro příspěvkové organizace Středočeského kraje“, který bude spolufinancován z Integrovaného regionálního operačního programu.

Předmětem realizace projektu je zajistit komplexní bezpečnost sdílených služeb, které jsou nabízeny z TCK, zajistit centrální IDM, který umožní centrální řízení identit PO, a to včetně centrálního řízení oprávnění do agend a informačních systémů poskytovaných žadatelem. V úrovni bezpečnosti zajistí kontrolu činností všech registrovaných uživatelů na všech úrovních zpracování dat, sledování datového provozu technologické a aplikační infrastruktury. Za tímto účelem budou v rámci tzv. investiční varianty projektu pořízeny a implementovány v prostředí KÚ a PO odpovídající technologie, a to v souladu se zákonem o kybernetické bezpečnosti. Dále budou tyto technologie napojeny na bezpečnostní technologie využívané v rámci IS KÚ, resp. bezpečnostní infrastruktury. Tento projekt bude tedy řešit kybernetickou bezpečnost PO v úrovni dodávky perimetrů/firewallů, přičemž stěžejním je nasazení centrální správy uživatelů – Identity management (IDM). V této podobě jde o řízení cca 2500 uživatelů PO a 500 uživatelů KÚ, kteří přistupují či budou přistupovat k jednotlivým sdíleným službám, resp. poskytovaným informačním systémům z TCK. Aktuálně jsou poskytovány ekonomický systém GINIS, spisová služba (aktuálně pro cca 180+ škol), anonymizační nástroj a nástroj v oblasti evidence a kontroly smluv. Do budoucna počítáme s nasazením Facility managementu a centrálního systému pro výměnu souborů.

Zadavatel bude projektem realizovat bezpečnostní technické opatření dle § 5 odst. 3) zákona č. 181/2014 Sb., o kybernetické bezpečnosti (ZKB), z těchto oblastí:

• nástroj pro ochranu integrity komunikačních sítí,

• nástroj pro ověřování identity uživatelů,

• nástroj pro řízení přístupových oprávnění,

• nástroj pro ochranu před škodlivým kódem,

• nástroj pro detekci kybernetických bezpečnostních událostí,

• kryptografické prostředky, které nejsou určeny k ochraně utajovaných skutečností.

2.2Cíle projektu

Hlavním cílem projektu je zajistit možnost využívání sdílených služeb nabízených a spravovaných krajem příspěvkovým organizacím kraje v Technologickém centru kraje (TCK). Jedná se pouze o technická řešení. V motivační vrstvě architektury jsou tyto cíle popsány následovně:

• Zvýšit kybernetickou bezpečnost Středočeského kraje a jeho PO;

• Zajistit bezpečnost sdílených služeb TCK (Technologické centrum kraje).

Dosažení cílů zajistí tyto výstupy projektu:

• Pořízení a implementace systému pro automatizaci incidenčního Workflow;

• Pořízení a implementace řešení k zajištění bezpečnosti sdílených služeb;

• Pořízení a implementace centrálního IDM.

Hlavní cíl bude naplněn, pakliže PO budou mít bezpečný přístup k Významným informačním systémům.

Cílem projektu je zvýšit kybernetickou bezpečnost Středočeského kraje a jeho PO.

Cíl bude naplněn, pakliže bude naimplementováno a zprovozněno „Komplexní řešení bezpečnosti sdílených služeb TCK“ a řešení „Centrální IDM“. Doplnění těchto subsystémů do celkového systému řízení informační bezpečnosti kraje a jeho PO celkovou úroveň bezpečnosti bezpochyby zvýší.

Synergický efekt u činností správy a provozu povede k celkovému snížení pracnosti na straně KÚ i PO. Dalším efektem bude metodické sjednocení aktivit a postupů v oblasti informační bezpečnosti kraje a jednotlivých PO.

3Předmět veřejné zakázky

3.1Současný stav

Zadavatel, resp. KÚSK, realizoval od roku 2019 projekt „Zvýšení kybernetické bezpečnosti informačních systémů KÚSK " (dále také IS KÚ), jehož předmětem bylo zajištění komplexního monitoringu ICT prostředků, kontrola činností všech registrovaných uživatelů na všech úrovních zpracování dat, sledování datového provozu informační infrastruktury, registrování útoků na prostředky ICT a průběžné odhalování případných interních a externích útočníků. Aktuálně je projekt v provozní fázi.

Za tímto účelem byly v rámci projektu pořízeny a v prostředí IS KÚ implementovány odpovídající technologie a zajištěny vybrané služby externího dodavatele, a to v souladu se zákonem o kybernetické bezpečnosti a nařízením EP a Rady (EU) 2016/679 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů.

V rámci projektu chce Středočeský kraj zabezpečit především tyto systémy:

• Elektronická spisová služba;

• Ekonomický systém GINIS;

• Facility Management;

• další SW (anonymizace dokumentů, centrální Exchange souborů).

V současné době spravuje KÚSK 4 významné informační systémy a agendové a provozní informační systémy. V rámci projektu jsou předmětem řešení prioritně 2 VIS KÚSK. Jedná se o následující systémy:

Řešené informační a komunikační systémy
GINIS – Ekonomický systém	VIS
E−spis – elektronická spisová služba	VIS

Zadavatel dále provozuje technologické centrum kraje (dále též „TCK“). Jádrem serverového řešení TCK jsou virtualizované ESX servery, které jsou umístěny do primární a záložní lokality. Virtualizované prostředí je vytvořeno prostřednictvím OS VMware (verze 7. x), kde HW základ HA clusteru je tvořen 15 blade servery s tím, že je 12 serverů v primární lokalitě (Praha) a 3 v záložní lokalitě (Kladno).

Z pohledu infrastruktury jsou TCK tvořeny výkonnými vzájemně propojenými přepínači s možností generování informací na bázi netflow/netstream. Dále je připojena další DMZ se službami a přístupová část pro uživatele, která je tvořena prvky bez možnosti generování informací na bázi netflow.

V následující části jsou uvedené počty fyzických prvků:

Fyzické prvky infrastruktury KÚSK
Fyzické servery	23
Aktivní síťové prvky	78
Datová úložiště	2
Firewally	2
Fyzické bezpečnostní prvky	5
Páskové mechaniky	1

V následující tabulce jsou uvedené počty vybraných aktivních licencí:

Přehled vybraných aktivních licencí KÚSK
MS Windows 2019 (WinSvrDCCore 2019 SNGL MVL 16Lic CoreLic)	8
MS SQL Server (SQLSvrStdCore 2019 SNGL MVL 2Lic CoreLic)	26
VMware vSphere 7 Enterprise Plus	26
VMware vCenter Server 7 Standard	2

V rámci prostředí IS KÚSK je provozováno cca 220 virtuálních serverů.

3.2Požadované služby a dodávky

3.2.1Podrobný návrh cílového konceptu řešení

Zadavatel požaduje, aby Dodavatel v rámci Fáze č.1 zpracoval podrobný cílový koncept vč. implementačního plánu a harmonogramu, který bude podrobně definovat implementaci HW a SW, resp. technologické a aplikační infrastruktury dle Fáze č. 2. a Fáze č.3 (testovací a produkční prostředí). Součástí cílového konceptu bude detailní technická dokumentace (technické listy/Data Sheets), zároveň architektonický model – Archimate, openformát.

3.2.2Požadované služby a dodávky NGFW

Zadavatel požaduje, aby Dodavatel v rámci veřejné zakázky jednorázově poskytl Zadavateli následující dodávky a služby a předal jejich výstupy:

• Dodávka a implementace HW (a SW) včetně licencí a nasazení konfigurace dle cílového konceptu, otestování řešení a dodávka kompletní dokumentace;

• Pilotní provoz HW a SW technologií;

• Údržba a podpora po dobu 60 měsíců od předání díla, resp. od ukončení Fáze
  č. 3;

• Podpora při ukončení služby a předání na jiného dodavatele (Exit plán).

3.2.3Požadované služby a dodávky k IDM

Zadavatel požaduje, aby Dodavatel v rámci veřejné zakázky jednorázově poskytl Zadavateli následující dodávky a služby a předal jejich výstupy:

• Dodávka a implementace SW včetně licencí a nasazení konfigurace dle cílového konceptu do testovacího a produkčního prostředí, otestování řešení a dodávka kompletní dokumentace;

• Pilotní provoz SW technologií;

• Údržba a podpora po dobu 60 měsíců od předání díla, resp. od ukončení Fáze
  č. 3;

• Podpora při ukončení služby a předání na jiného dodavatele (Exit plán).

3.2.4Požadované dodávky a služby SAIW

Zadavatel požaduje, aby Dodavatel v rámci veřejné zakázky jednorázově poskytl Zadavateli následující dodávky a služby a předal jejich výstupy:

• Dodávka a implementace SW včetně licencí a nasazení konfigurace dle cílového konceptu do testovacího a produkčního prostředí, otestování řešení a dodávka kompletní dokumentace;

• Pilotní provoz SW technologií;

• Údržba a podpora po dobu 60 měsíců od předání díla, resp. od ukončení Fáze
  č. 3;

• Podpora při ukončení služby a předání na jiného dodavatele (Exit plán).

3.2.5Provádění dalších aktivit souvisejících s provozem a rozvojem řešení

Zadavatel může po dobu účinnosti smlouvy požadovat, aby Dodavatel v rámci veřejné zakázky ad-hoc na základě požadavku a specifikace Zadavatele prováděl další aktivity, které budou bezprostředně souviset s provozem a rozvojem řešení. Zadavatel očekává celkový objem takto požadovaných aktivit do 20 MD za rok s možností převodu nevyčerpaných MD do následujících let do maximálního množství 100 MD. Tyto aktivity mohou zahrnovat:

• Mimořádné servisní úkony nad rámec pravidelné údržby;

• Dodatečnou customizaci a úpravu komponent řešení;

• Podporu při změně konfigurací nebo přenosu řešení.

Zadavatel vytvoří přesné zadání požadavku na rozvoj systému. Dodavatel připraví odhad pracnosti (maximální limit) v hodinách jednotlivých rolí a související cenu úkonu dle nasmlouvaných sazeb. Zadavatel akceptuje odhad pracnosti Dodavatele. Dodavatel realizuje plnění rozvoje systému dle akceptovaných podmínek. Dodavatel odevzdá příslušnou dokumentaci změny a konfigurační předpisy.

V případě potřeby na změnu požadavku, zastavení práce na požadavku, nebo v případě potřeby koordinace řešení s dalšími dodavateli, eskaluje Dodavatel tyto informace bezodkladně na Zadavatele skrze odpovědné pracovníky Odboru informatiky Zadavatele.

Zadavatel poskytne Dodavateli součinnost v následujícím rozsahu:

• Zadavatel zajistí a poskytne Dodavateli přístup do úložiště dokumentů a repozitářů, které budou sloužit ke sdílení veškerých elektronických dokumentů a architektonických návrhů vytvořených Dodavatelem v rámci plnění této veřejné zakázky.

• Zadavatel poskytne Dodavateli podporu při koordinaci činností s jinými dodavateli integrovanými nebo integrujícími své IS do prostředí Zadavatele. Odbor informatiky Zadavatele musí být informován o veškeré písemné komunikaci mezi dodavateli.

Výstupy budou vykazovány do výkazu práce na tříměsíční bázi, dle odpracovaných hodin za dané období. Výkaz dále obsahuje přehled všech požadavků na provedení dalších aktivit, které ▇▇▇▇▇▇▇▇▇ obdržel od Zadavatele, a jejich aktuální stav.

4Architektura řešení

4.1Technologická architektura

S
trukturální pohled na technologickou architekturu

Z pohledu NGFW budou do HTCK instalovány dva fyzické centrální NGFW napojené na stávající analyzační nástroj v rámci log managementu v podobě HW appliance (není součástí dodávky řešení). Stávající NGFW se přesune do záložního TCK. Centrální NGFW bude poskytovat služby pro PO, ve kterých bude dle velikosti PO instalován dle požadavků velký, střední nebo malý NGFW. Klientské stanice budou připojeny pomocí VPN klienta za pomocí Mobile Token aplikace.

S
távající farma serverů, diskových úložišť a dalších HW zařízení na KÚSK bude rozšířena o dva centrální NGFW (next generation firewally) a napojena na stávající Log Manager / Analyzer ve formě HW Appliance. Na každé PO bude instalován NGFW HW zařízení. NGFW bude poskytovat požadované firewallové služby na KÚSK, které budou čerpat odpovídající služby na protistraně, tedy na PO (pozn.: vazba NGFW KÚSK – NGFW PO je oboustranná). Na klientských stanicích PO bude instalován VPN klient a SW token, což umožní bezpečné čerpání všech služeb na aplikační úrovni. Pro centrální IDM bude vytvořen virtuální datový, aplikační a webový server/y. Pro SAIW bude také pořízen virtuální server a bude provedena integrace na stávající helpdeskové řešení iTop – IT provozní portál.

4.2A
plikační architektura

Stávajícím a existujícím sdíleným službám - spisová služba, ekonomika a anonymizace dokumentů - bude sloužit aplikace Centrální IDM, která společně s Externím AD (již v provozu, není součástí realizace) bude řídit základní přístupy a oprávnění uživatelů k aplikacím poskytujícím tyto služby. IDM dále nabídne uživatelům a administrátorům PO služby správy identit a přístupů. Bude naimplementován SAIW, který zajistí zasílání notifikací řešitelům (tel., email, sms), evidenci bezpečnostních událostí a incidentů, jejich propagaci do centrálního servisdeskového řešení a informování zainteresovaných osob o možných bezpečnostních událostech/incidentech. NGFW zajistí jak služby dohledu a centralizovaného logování, tak i klíčové firewallové služby, zejména šifrování ve VPN a správu veškerých FW pravidel.

5Technická specifikace NGFW

5.1Obecné požadavky na cílové řešení NGFW

Bude dodáno a zprovozněno minimálně 264 a maximálně 270 NGFW perimetrů na straně PO, (tolik perimetrů, kolik bude PO zapojených do projektu v době realizace) 2 centrální NGFW perimetry budou dodány a implementovány na straně KÚ pro komplexní bezpečnost sdílených služeb, které jsou nabízeny z TCK KÚSK. Zadavatel požaduje přenést komplexní FW pravidla (bezpečnostní politiky) ze starých NGFW na nové.

Uvedené řešení NGFW (Next Generation Firewall) bude dále doplněno o 3 000 subskripcí VPN klientů a 3 000 licencí aplikace pro generování jednorázového hesla pro mobilní zařízení.

Z důvodu ochrany již uskutečněných investic a minimalizace provozních nákladů zadavatel požaduje plnou integraci na stávající technologiemi a 100% kompatibilitu se zbytkem prostředí TCK. Stávající technologie zahrnuje Fortigate 500E, který bude přesunut do ZTCK a další produkty FortiMail, FortiSandbox, FortiADC, FortiAnalyzer.

Základním kamenem je klastr dvou výkonných centrálních NGFW instalovaných v hlavním TCK (HTCK), který umožní:

• poskytování HA (High Availability = vysoká dostupnost),

• terminování zabezpečených spojení,

• správu bezpečnostních politik,

• správu klientských agentů,

• správu MFA (multifaktorová autentizace).

Základní bezpečnostní politika bude umožňovat spojení pouze mezi centrálním NGFW v HTCK (resp. Fortigate 500E v ZTCK) a z NGFW v jednotlivých PO nebo z klientských zařízení (vybavených agenty).

Každé spojení k VIS/IS bude možné ověřit dalším faktorem. Centrální NGFW (resp. FG-500 ZTCK) budou mít nastavenou spolupráci s aplikací pro generování jednorázových hesel pro mobilní zařízení, které budou využívat jednotliví uživatelé s přístupem k VIS/IS např. v rámci práce z domova (HomeOffice) na straně KÚ a pro přístup ke sdíleným službám, resp. VIS/IS ze strany PO.

Dalším bodem v bezpečnostním systému budou NGFW na jednotlivých PO. Zde zadavatel požaduje mix několika kapacitně odlišných zařízení viz Příloze č.5a Funkční a nefunkční požadavky NGFW, a to dle velikosti PO.

Třetí částí systému budou agenti NGFW instalovaní na klientských koncových zařízeních, ze kterých jsou navazována spojení z jednotlivých PO do centrálních VIS/IS. Všechna spojení navazovaná z daných klientů budou ověřena přes aplikaci. Celý ekosystém bude spravován a bezpečnostně dohlížen pomocí centralizovaného nástroje pro sběr, analýzu a správu dat poskytovaných z NGFW.

5.2Funkční a nefunkční požadavky na řešení

5.2.1Funkční a nefunkční požadavky technologie NGFW

Funkční a nefunkční požadavky jsou obsahem Přílohy č. 5a Zadávací dokumentace.

5.2.2Dodávka potřebných licencí k produktu

Dodavatel spolu se zařízeními dodá licence k obslužnému software a zajistí jejich převod na Zadavatele. Zároveň zajistí maintenance na dobu 60 měsíců.

5.2.3Školení

Dodavatel připraví plán školení pro proškolení obsluhujícího personálu. Cílem proškolení obsluhujícího personálu je předání informací k obsluze implementovaného řešení v takové míře, aby mohl být proveden pilotní provoz. Školení obsluhujícího personálu proběhne minimálně na úrovni školení administrátorů v rozsahu 3 MD.

5.2.4Uvedení pilotního provozu HW a SW vybavení a všech naimplementovaných řešení v rámci projektu 

Dodavatel uvede systém do pilotního provozu. Účelem pilotního provozu je ověření funkčních vlastností implementovaného systému. Uvedení systému do pilotního provozu zahrnuje následující aktivity: 

• Přenesení komplexních FW pravidel (bezpečnostních politik) ze starých NGFW na nové NGFW vč. přemístění současných NGFW do ZTCK (Kladno);

• Ověření NGFW nasazených na jednotlivých PO;

• Aktualizace dokumentace, školení uživatelů a řízení změn;

• Vyhodnocení pilotního provozu a realizace nápravných opatření. 

5.2.5Uvedení systému do produkčního provozu 

Dodavatel uvede systém do produkčního provozu. Uvedení systému do produkčního provozu zahrnuje následující aktivity: 

• Uvedení do ostrého provozu postupným roll-outem na jednotlivá uživatelská pracoviště (KÚ a PO) včetně poskytování zvýšeného dohledu;

• Finální akceptace. 

5.2.6Údržba systému

Úkony údržby jsou vykazované nejpozději v následujícím měsíci po jejich provedení. Do úkonů údržby se zahrnují:

Profylaxe – Dodavatel provádí pravidelnou kontrolu a vyhodnocení stavu systému. Dodavatel na základě vyhodnocení stavu systému upozorňuje Zadavatele na nepravidelnosti v provozu systému a provádí změny konfigurací a další úkony potřebné k zajištění spolehlivého běhu systému. Dodavatel dále na základě vyhodnocení stavu systému doporučuje opatření k zajištění zdrojů pro udržení výkonu systému.

• Minimální četnost: 1x za 6 měsíců nebo dle aktuální potřeby;

• Způsob měření a vykazování: výčet provedených úkonů;

• Předpokládané časy údržby: podle dohody se Zadavatelem.

Dodávka a aplikace záplat a aktualizací – Dodavatel průběžně sleduje bezpečnostní upozornění, bezpečnostní a funkční záplaty a aktualizace systému včetně doporučení k jejich nasazení vydané výrobcem. Dodavatel vydané záplaty a aktualizace otestuje a doporučí Zadavateli termín a způsob jejich nasazení. Zadavatel rozhodne o doporučení. Dodavatel následně provádí úkony podle rozhodnutí Zadavatele.

• Četnost: průběžně;

• Způsob měření a vykazování: výčet aplikovaných záplat;

• Předpokládané časy údržby: podle dohody se Zadavatelem.

Průběžná aktualizace provozní a technické dokumentace – Dodavatel pravidelně provádí aktualizace provozní a technické dokumentace systému na základě změn do skutečného provedení systému provedených Dodavatelem nebo Zadavatelem, včetně popisu skutečného provedení systému pro testovací i ostré prostředí (architektonické modely v otevřeném formátu jazyka Archimate, popis technologií a konfigurací), popisu změn jednotlivých modulů při aktualizacích, popisu nasazovaných záplat a aktualizací včetně podmínek jejich nasazení, požadavků na koncové stanice, servery a infrastrukturu, uživatelských a systémových příruček s popisem provozních postupů, popisu pravidel, rozsahu a podmínek zálohování systému v různých prostředích.

• Minimální četnost: 1x ročně;

• Způsob měření a vykazování: výčet změn podle dokumentů;

• Předpokládané časy údržby: podle dohody se Zadavatelem.

Zadavatel poskytne Dodavateli součinnost v následujícím rozsahu:

Zadavatel poskytne Dodavateli technický popis prostředí IT Zadavatele, zejména konfigurační standardy platforem a standardy provozních postupů.

Zadavatel umožní odborným pracovníkům Dodavatele provádět fyzické prohlídky provozního prostředí KÚSK, ve kterém je provozován systému.

Zadavatel zajistí a poskytne Dodavateli přístup do úložiště dokumentů a repozitářů, které budou sloužit ke sdílení veškerých elektronických dokumentů, architektonických návrhů vytvořených Dodavatelem v rámci plnění této veřejné zakázky.

Zadavatel posoudí doporučení Dodavatele a rozhodne o nasazení záplat a aktualizací technologie NGFW.

Způsob plnění, termíny, akceptace:

Aktivity údržby jsou vykazovány do předem definovaných šablon dle výše popsaných požadavků.

Dodavatel bude při svých dodávkách koordinovat svoje činnosti s pracovníky Odboru informatiky Zadavatele tak, aby provoz systému odpovídal kontextu prostředí Zadavatele, tj. respektoval omezení datových toků infrastruktury a využití zdrojů platforem a korektně využíval centrální služby IT (např. zdroj přesného času, služby zálohování, jmenné a autentizační služby apod.) Odpovědnost za koordinaci činností Dodavatele s provozovateli infrastruktury IT, platforem a integrovaných informačních systémů na sebe bere Zadavatel.

Plnění služby je zahájeno dnem akceptace výstupů služby.

Dodavatel je povinen provádět údržbu systému do doby ukončení Smlouvy.

5.2.7Standardní podpora systému

Zadavatel definuje 3 požadované úrovně podpory – L1, L2, L3:

• L1: HelpDesk Zadavatele – pro každodenní drobnou podporu všech uživatelů systému, zajišťuje Zadavatel svými silami;

• L2: ServiceDesk Dodavatele – pro běžně náročné úkony podpory, pouze pro oprávněné pracovníky Kraje, provádí Dodavatel;

• L3: Odborníci Dodavatele – pro náročné úkony podpory vyžadující expertní znalost, pouze pro oprávněné pracovníky Kraje, provádí Dodavatel.

Pro účely poskytování podpory definuje Zadavatel:

• SLA: jedná se o domluvenou úroveň kvality služeb, kterou ▇▇▇▇▇▇▇▇▇ garantuje Zadavateli.

• Uživatelský požadavek: jedná se o Ticket popisující požadavek uživatele systému na podporu Dodavatelem, a to při úkonech zahrnutých do rozsahu podpory. Obsahuje popis požadavku, čas vytvoření, kontaktní osobu, kategorii požadavku, analýzu požadavku a návrh řešení, analýzu dopadů řešení, popis úkonů provedených k vyřešení požadavku, historii změn stavů Ticketu a další informace vztahující se k řešení požadavku.

• Závada: znamená nesoulad skutečné funkčnosti systému s funkčností, jež je popsána technickou dokumentací.

• Kybernetický incident: jde o narušení bezpečnosti informací v informačních systémech nebo narušení bezpečnosti služeb anebo bezpečnosti a integrity sítí elektronických komunikací v důsledku kybernetické bezpečnostní události.

• Hlášení závady: jedná se o Ticket popisující výskyt závady. Obsahuje popis závady, čas hlášení, kontaktní osobu, kategorii závady, vyhodnocení dopadů a příčin závady, popis úkonů provedených k odstranění závady, historii změn stavů Ticketu a další informace vztahující se k řešení závady.

• Response time: jedná se o dobu od okamžiku zadání uživatelského požadavku (příp. hlášení závady) do okamžiku, kdy je ▇▇▇▇▇▇▇▇▇▇ sděleno, že ▇▇▇▇▇▇ s jeho požadavkem (resp. hlášením) je přijat a bylo zahájeno jeho zpracování.

• Fix time: jedná se o dobu počínající okamžikem nahlášení závady (příp. zadání požadavku), do okamžiku, kdy je, a to buď dočasným, nebo kompletním řešením, závada odstraněna (resp. požadavek vyřešen) vyřešen.

Životní cyklus hlášení závady a uživatelského požadavku je definován skrze následující stavy, viz následující diagram:

• Zadáno – Ticket byl korektně nahlášen, začíná měření Response a Fix time;

• Přiděleno – Dodavatel přidělil Ticket k řešení odpovědnému řešiteli;

• Čekající – Řešení Ticketu čeká na aktivitu Zadavatele nebo třetí strany, Fix time je pozastaven;

• Vyřešen – Ticket je Dodavatelem vyřešen.

Poskytování podpory zahrnuje:

• Hot-line prostřednictvím HelpDesku, telefonu či e-mailu pro vyjmenované pracovníky Zadavatele (tj. odpovědi na otázky k užívání a fungování systému, příjem požadavků, hlášení závad, stav Ticketů);

• Řešení požadavků KÚSK, například příprava/úprava sestav/výkazů, změny/migrace dat, změna/definice uživatelských rolí, vytvoření nového uživatele, optimalizace konfigurace, doplnění číselníku apod.;

• Podpora při vytváření plánů obnovy, provádění testů obnovy a dostupnosti systému;

• Řešení problémových stavů v datech vzniklých činností uživatelů;

• Řešení závad a nepravidelností v provozu systému;

• Osobní asistence při administraci systému;

• Metodická pomoc, účast a asistence na metodických jednáních;

• Konzultace otázek spojených s užíváním systému.

V případě, že Zadavatel kontaktuje ▇▇▇▇▇▇▇▇▇▇ s požadavkem na podporu ohledně úkonů, které nejsou součástí podpory, zasílá Dodavatel tento požadavek zpět na Zadavatele s odůvodněním (bez povinnosti předávat tento požadavek k řešení). Mezi takové požadavky jsou zařazeny zejména:

• Závady v IT infrastruktuře;

• Požadavky na přizpůsobení nebo změny funkcí systému;

• Správa instalací na stanicích uživatelů.

Zadávání požadavků v rámci podpory a údržby a s tím související komunikace úkonů podpory Dodavatele bude realizována primárně pomoci ServiceDesku Dodavatele. Podpora bude Dodavatelem poskytována v pracovních dnech od 7:00 do 19:00 hodin. Mimo tuto dobu zadává Zadavatel požadavky písemnou formou (email, web), a Dodavatel tyto požadavky řeší přednostně při nejbližším termínu běžné pracovní doby poskytování podpory. Telefonická podpora v pracovní době (od 7:00 do 19:00 hodin) slouží pro operativní vyřizování dotazů oprávněných pracovníků Zadavatele. V případě potřeby změnit prioritu řešení nebo v případě potřeby koordinace řešení s dalšími dodavateli, eskaluje Dodavatel tyto informace bezodkladně na Zadavatele skrze ServiceDesk popř. odpovědné pracovníky Odboru informatiky Zadavatele.

Zadavatel bude realizovat měření dostupnosti služby a dalších systémů s pomocí monitorovacího nástroje, který ověřuje dostupnost aplikací pravidelnými automatizovanými dotazy.

Podrobná specifikace služeb (SLA) se vypočítává dle času technologické podpory a je vymezena následovně:

Dostupnost (v provozním čase)	99,5% Dostupnost = ((požadovaná doba dostupnosti – suma (doby nedostupnosti podle měření) / (doba dostupnosti)) * 100
Technologická podpora	7x12 Po-Ne 7:00 – 19:00
Zadávání požadavků ServiceDesk (email, web)	7x24
Odezva (Response time)	Dle detailu priorit v následující tabulce
Řešení (Fix time)	Dle detailu priorit v následující tabulce
Plánovaná údržba	Mimo provozní čas, souvislá délka odstávky max. 4 hodiny – servisní okno

Kategorie priorit – řešení jednotlivých požadavků:

Priorita/kategorie vady	Popis	Odezva (Response time)	Řešení do (Fix time)
1 – kritická Kategorie vady A	Systém nefunguje vůbec nebo jeho nefunkčnost je omezena tak, že tento stav má významný dopad na klíčové procesy Zadavatele Aplikaci nebo některou její klíčovou funkci není možné používat Dochází k narušení uživatelských dat závažným způsobem Dochází ke zhroucení systému jednou nebo několikrát za den	1 hod.	4 hod.
2 – vysoká Kategorie vady B	Funkce systému je narušena tak, že dochází k významnému zpomalení výkonu klíčových procesů Zadavatele.	2 hod.	8 hod.
3 – střední Kategorie vady C	Funkce systému je omezena, ale toto omezení má minimální vliv na zpracování klíčových procesů Zadavatele Závada narušuje, avšak neznemožňuje využití systému Blokuje dokončení určitých úkolů, které nejsou časově kritické působí dílčí závadu nebo nepohodlí uživatele procesní závada (vyřeší se změnou procesu) Tuto závadu lze jiným náhradním dočasným způsobem (např. ruční úpravou dat) nebo dočasnou změnou pracovního postupu obejít (workaround). Uživatel však musí vykonat vícepráce na obejití závady.	4 hod.	24 hod.
4 – nízká Kategorie vady D	Systém je funkční. Závada způsobuje jen minimální obtíže při jeho používání. Jde o situace, kdy: vznikne malý problém nebo nepohodlí obsluhy kosmetická chyba ve vizuálním rozhraní (chybné popisy, řazení dat, překreslování) Uživatel nemusí vykonat vícepráce na obejití závady. Způsobuje mu nepohodlí při práci (např. pohyb myší navíc, klik myší navíc, stisk několika kláves navíc atp.).	8 hod.	120 hod.

Lhůty se ve věcech reakčních dob (Response time) pro řešení požadavků počítají v rámci pracovní doby Zadavatele, tedy běh lhůty se pozastavuje na konci každého pracovního dne a obnovuje na počátku pracovní doby následujícího pracovního dne. Pracovní doba se pro tento případ definuje od 7:00 do 19:00. Pozastavení počítání lhůty s koncem pracovní doby neplatí pro řešení chyby kategorie A. Není-li vzájemně dohodnuto jinak, lhůta pro měření doby reakce a doby odstranění požadavků započne běžet časem předání požadavku Dodavateli a bude ukončena v čase předání vyřešeného požadavku zpět Zadavateli. Celková doba odstranění je pak součet všech časových dob, po které byl požadavek v řešení na straně Dodavatele. Z celkové doby odstranění požadavku jsou vyloučeny časové doby, kdy Dodavatel prokazatelně nemohl pokračovat v řešení požadavku z důvodů, které nebyly jim způsobené.

Způsob plnění, termíny, akceptace:

Plnění služby Dodavatel vykazuje do protokolu na tříměsíční bázi. Protokol vyhodnotí stav plnění všech parametrů SLA (Response time, Fix time) dle kategorie požadavku, dále udává statistické informace jako průměrné splněné SLA hodnoty, průměrné nesplněné SLA hodnoty, celkový počet Ticketů dle stavu a kategorie, a jiné relevantní údaje podle dohody se Zadavatelem.

5.2.8Nadstandardní podpora systému

Dodavatel je povinen držet připravenost na nadstandardní podporu systému, která je iniciována ze strany Zadavatele např. v případě kybernetického útoku. Tato podpora bude dostupná pouze v případě nutnosti a iniciace ze strany Zadavatele v režimu 24/7.

5.2.9Znalostní podpora a provedení nezbytných úkonů při ukončení ▇▇▇▇▇▇▇ a předání služeb na jiného dodavatele

Podpora a provedení nezbytných úkonů při ukončení smlouvy a předání služeb na jiného dodavatele zahrnuje následující požadavky na Dodavatele:

• Vypracování plánu exitu a podpory předávání znalostí novému dodavateli;

• Předání veškeré zpracované technické a provozní dokumentace systému podle plánu.

Zadavatel poskytne Dodavateli součinnost v následujícím rozsahu:

• Zadavatel umožní odborným pracovníkům Dodavatele provádět fyzické prohlídky provozního prostředí Zadavatele.

• Zadavatel zajistí a poskytne Dodavateli přístup do úložiště dokumentů a repozitářů, které budou sloužit ke sdílení veškerých elektronických dokumentů, architektonických návrhů vytvořených Dodavatelem v rámci plnění této veřejné zakázky.

Zadavatel akceptuje od Dodavatele výstupy dle výše popsaných náležitostí.

Dodavatel je povinen poskytnout službu na výzvu Zadavatele, nejpozději však 2 měsíce před vypršením smlouvy.

Odměna za službu je zahrnuta v ceně poskytování podpory.

Vady rozvojových aktivit, respektive rozpory zjištěné a oznámené Zadavatelem Dodavateli během doby aktivní podpory a údržby je Dodavatel povinen na vlastní náklady odstranit bez zbytečného odkladu po jejich oznámení. Nejpozději však ve smluvně stanovených lhůtách. Dodavatel se zavazuje odstranit vady systému, které se na systému vyskytnou v průběhu záruční doby.

Dodavatel se zprostí odpovědnosti za vady v případě, prokáže-li, že vada byla způsobena poskytnutím nesprávných informací i ze strany Zadavatele či jeho nevhodnými pokyny, na kterých trval.

Zadavatel je povinen informovat Dodavatele o jakékoliv vadě systému, na niž se vztahuje záruka, bez zbytečného odkladu po jejím vzniku. Vady musí být již při jejich uplatnění srozumitelně a přesně popsány. Poté, co Zadavatel řádně nahlásí vadu prokazatelným způsobem, Dodavatel odstraní závady ve stanovených lhůtách dle jejich charakteru a závažnosti.

Za vady systému se nepovažují poruchy funkčnosti nebo odchylky od zadávací dokumentace, které jsou důsledkem:

• Použití systému či jeho části pro jiné účely, než pro jaké je určen dle dokumentace a použití systému či jeho části v rozporu s příslušnou dokumentací, která se váže k systému či jeho části.

• Provedení změny systému či jeho části anebo jiný neoprávněný zásah Zadavatele nebo třetí strany bez vědomí a souhlasu Dodavatel.

• Změny v SW nebo HW, na kterých systém pracuje nebo je s nimi propojen, nebo na kterých je jinak závislý, pokud tyto změny provedl Zadavatel nebo třetí strana bez vědomí a souhlasu Dodavatele.

• Vada nebo porucha SW nebo HW, které nebyly předmětem dodávky, a na kterých systém pracuje nebo je s nimi propojen, nebo na kterých je systém závislý.

6Technická specifikace IDM

6.1Obecné požadavky na cílové řešení IDM

Bude implementován IDM, který:

• umožní centrální řízení identit PO, a to včetně základního řízení oprávnění přístupů do agend a informačních systémů poskytovaných žadatelem pro PO viz. kapitola 3.1 – Řešené informační a komunikační systémy,

• bude integrován se stávajícími VIS/IS na úrovni oddělené instance od stávající integrace interního ActiveDirectory (AD) žadatele. IDM prioritně bude řídit oprávnění na úrovni jednotlivých modulů GINIS. V případě ostatních VIS/IS jde zejména o správu identit jednotlivých PO a řízení rolí. V rámci rozvoje bude předmětem vývoj konektorů do stávající a budoucích IS.

• zpřístupní funkce správy identit PO uživatelům a administrátorům z PO dle jejich práv prostřednictvím portálu. Zadavatel požaduje, aby každá organizace měla k dispozici vlastní portálovou část pro správu identit PO a základních rolí.

Oblast identit (nástupu, výstupů zaměstnanců, přidělování základního oprávnění do jednotlivých informačních systémů, agend) musí být v gesci každé PO, která musí udržovat konsolidovaný seznam zaměstnanců/identit a průběžně ho aktualizovat, přičemž musí být striktně odděleni interní a externí uživatelé. Pro účely autorizace a autentizace uživatelů bude IDM napojeno na systém již existujícího ActiveDirectory (AD) a data o externích uživatelích budou mezi nimi synchronizována.

V systému IDM budou evidovány účty interních uživatelů (KÚ) a externích uživatelů, tedy uživatelů z jednotlivých PO. IDM bude umožňovat evidenci jak sady obvyklých generických atributů (telefonní číslo apod.), tak i sady aplikačně závislých atributů, které umožní oprávněným osobám přístup k patřičným zdrojům. Samozřejmostí bude používání business rolí, odpovídajících aplikačních rolí uživatelských rolí a systematizovaných míst v organizační struktuře.

Účet každé PO bude spravovat pověřený správce z PO. Správce z PO bude ke správě uživatelských účtů využívat těchto možností:

6.1.1správa prostřednictvím portálu,

• dávkový import seznamu uživatelů v definované struktuře s patřičnými atributy a metadaty,

• v ojedinělých případech (max. 5 případů) napojení vlastního IDM PO na webové služby centrálního IDM (součást budoucího rozvoje).

Koncovým uživatelům bude IDM poskytovat obvyklé funkcionality, jako např. žádost o přístup k aplikaci či její části určenou vlastnímu správci, reset uživatelského hesla v aplikaci apod.

Za účelem autorizace a autentizace uživatelů bude IDM napojeno na stávající systém ActiveDirectory (AD). Data o uživatelích PO budou mezi synchronizována AD a IDM.

IDM musí zároveň řídit oprávnění na úrovni jednotlivých modulů GINIS. V případě spisové služby budou řízeny základní role, resp. přístupy do systému. V rámci dalšího rozvoje se počítá s realizací konektorů do dalších systémů „Facility management, Anonymizační nástroj,
centrální Exchange souborů a Portál PO“.

6.1.2Funkční a nefunkční požadavky na řešení

Funkční a nefunkční požadavky IDM jsou obsahem Přílohy č. 5b Zadávací dokumentace.

6.1.3Implementace řešení

V rámci tohoto bodu se jedná především o následující aktivity:

• centralizovaná správa identit a přístupových oprávnění k VIS/IS pro PO,

• integrace se stávajícími VIS/IS.

6.1.4Dodávka potřebných licencí k produktu

Dodavatel dodá potřebné licence, jejich maintenance a převod na KÚSK. Dodavatel bude poskytovat podporu po dobu 60 měsíců.

6.1.5Školení

Dodavatel připraví plán školení pro proškolení obsluhujícího personálu. Cílem proškolení obsluhujícího personálu je předání informací k obsluze implementovaného řešení v takové míře, aby mohl být proveden pilotní provoz. Školení obsluhujícího personálu proběhne minimálně na úrovni školení administrátorů v rozsahu 10 MD.

6.1.6Uvedení pilotního provozu HW a SW vybavení a všech naimplementovaných řešení v rámci projektu 

Dodavatel uvede systém do pilotního provozu. Účelem pilotního provozu je ověření funkčních vlastností implementovaného systému. Uvedení systému do pilotního provozu zahrnuje následující aktivity: 

• Vytvoření produkčního prostředí v TCK;

• Provedení migrace řešení z testovacího prostředí do produkčního;

• Aktualizace dokumentace, školení uživatelů a řízení změn;

• Vyhodnocení pilotního provozu a realizace nápravných opatření. 

6.1.7Uvedení systému do produkčního provozu 

Dodavatel uvede systém do produkčního provozu. Uvedení systému do produkčního provozu zahrnuje následující aktivity:

• Uvedení do ostrého provozu postupným roll-outem na jednotlivá uživatelská pracoviště včetně poskytování zvýšeného dohledu;

• Finální akceptace.

6.1.8Údržba systému

Úkony údržby jsou vykazované nejpozději v následujícím měsíci po jejich provedení. Do úkonů údržby se zahrnují:

Profylaxe – Dodavatel provádí pravidelnou kontrolu a vyhodnocení stavu systému. Dodavatel na základě vyhodnocení stavu systému upozorňuje Zadavatele na nepravidelnosti v provozu systému a provádí změny konfigurací a další úkony potřebné k zajištění spolehlivého běhu systému. Dodavatel dále na základě vyhodnocení stavu systému doporučuje opatření k zajištění zdrojů pro udržení výkonu systému. Součástí dodávky je také pravidelný přenos kopie produkčních dat do testovacího prostředí včetně nastavování prostředí systému a integračních vazeb na testovací instance jiných informačních systémů).

• Minimální četnost: 1x za 3 měsíce;

• Způsob měření a vykazování: výčet provedených úkonů;

• Předpokládané časy údržby: podle dohody se Zadavatelem.

Dodávka a aplikace záplat a aktualizací – Dodavatel průběžně sleduje bezpečnostní upozornění, bezpečnostní a funkční záplaty a aktualizace systému včetně doporučení k jejich nasazení vydané výrobcem. Dodavatel vydané záplaty a aktualizace otestuje a doporučí Zadavateli termín a způsob jejich nasazení. Zadavatel rozhodne o doporučení. Dodavatel následně provádí úkony podle rozhodnutí Zadavatele.

• Četnost: průběžně;

• Způsob měření a vykazování: výčet aplikovaných záplat;

• Předpokládané časy údržby: podle dohody se Zadavatelem.

Průběžná aktualizace provozní a technické dokumentace – Dodavatel pravidelně provádí aktualizace provozní a technické dokumentace systému na základě změn do skutečného provedení systému provedených Dodavatelem nebo Zadavatelem, včetně popisu skutečného provedení systému pro testovací i ostré prostředí (architektonické modely v otevřeném formátu jazyka Archimate, popis technologií a konfigurací), popisu změn jednotlivých modulů při aktualizacích, popisu nasazovaných záplat a aktualizací včetně podmínek jejich nasazení, požadavků na koncové stanice, servery a infrastrukturu, uživatelských a systémových příruček s popisem provozních postupů, popisu pravidel, rozsahu a podmínek zálohování systému v různých prostředích.

• Minimální četnost: 2x ročně;

• Způsob měření a vykazování: výčet změn podle dokumentů;

• Předpokládané časy údržby: podle dohody se Zadavatelem.

Zadavatel poskytne Dodavateli součinnost v následujícím rozsahu:

• Zadavatel poskytne Dodavateli technický popis prostředí IT Zadavatele, zejména konfigurační standardy platforem a standardy provozních postupů;

• Zadavatel umožní odborným pracovníkům Dodavatele provádět fyzické prohlídky provozního prostředí KÚSK, ve kterém je provozován systému;

• Zadavatel zajistí a poskytne Dodavateli přístup do úložiště dokumentů a repozitářů, které budou sloužit ke sdílení veškerých elektronických dokumentů, architektonických návrhů vytvořených Dodavatelem v rámci plnění této veřejné zakázky;

• Zadavatel posoudí doporučení Dodavatele a rozhodne o nasazení záplat a aktualizací technologie IDM.

Způsob plnění, termíny, akceptace:

• Aktivity údržby jsou vykazovány do předem definovaných šablon dle výše popsaných požadavků.

• Dodavatel bude při svých dodávkách koordinovat svoje činnosti s pracovníky Odboru informatiky Zadavatele tak, aby provoz systému odpovídal kontextu prostředí Zadavatele, tj. respektoval omezení datových toků infrastruktury a využití zdrojů platforem a korektně využíval centrální služby IT (např. zdroj přesného času, služby zálohování, jmenné a autentizační služby apod.) Odpovědnost za koordinaci činností Dodavatele s provozovateli infrastruktury IT, platforem a integrovaných informačních systémů na sebe bere Zadavatel.

• Plnění služby je zahájeno dnem akceptace výstupů služby.

• Dodavatel je povinen provádět údržbu systému do doby ukončení Smlouvy.

6.1.9Podpora systému

Zadavatel definuje 3 požadované úrovně podpory – L1, L2, L3:

• L1: HelpDesk Zadavatele – pro každodenní drobnou podporu všech uživatelů systému, zajišťuje Zadavatel svými silami;

• L2: ServiceDesk Dodavatele – pro běžně náročné úkony podpory, pouze pro oprávněné pracovníky Kraje, provádí Dodavatel;

• L3: Odborníci Dodavatele – pro náročné úkony podpory vyžadující expertní znalost, pouze pro oprávněné pracovníky Kraje, provádí Dodavatel.

Pro účely poskytování podpory definuje Zadavatel:

• SLA: jedná se o domluvenou úroveň kvality služeb, kterou ▇▇▇▇▇▇▇▇▇ garantuje Zadavateli.

• Uživatelský požadavek: jedná se o Ticket popisující požadavek uživatele systému na podporu Dodavatelem, a to při úkonech zahrnutých do rozsahu podpory. Obsahuje popis požadavku, čas vytvoření, kontaktní osobu, kategorii požadavku, analýzu požadavku a návrh řešení, analýzu dopadů řešení, popis úkonů provedených k vyřešení požadavku, historii změn stavů Ticketu a další informace vztahující se k řešení požadavku.

• Závada: znamená nesoulad skutečné funkčnosti systému s funkčností, jež je popsána technickou dokumentací.

• Kybernetický incident: jde o narušení bezpečnosti informací v informačních systémech nebo narušení bezpečnosti služeb anebo bezpečnosti a integrity sítí elektronických komunikací v důsledku kybernetické bezpečnostní události.

• Hlášení závady: jedná se o Ticket popisující výskyt závady. Obsahuje popis závady, čas hlášení, kontaktní osobu, kategorii závady, vyhodnocení dopadů a příčin závady, popis úkonů provedených k odstranění závady, historii změn stavů Ticketu a další informace vztahující se k řešení závady.

• Response time: jedná se o dobu od okamžiku zadání uživatelského požadavku (příp. hlášení závady) do okamžiku, kdy je ▇▇▇▇▇▇▇▇▇▇ sděleno, že ▇▇▇▇▇▇ s jeho požadavkem (resp. hlášením) je přijat a bylo zahájeno jeho zpracování.

• Fix time: jedná se o dobu počínající okamžikem nahlášení závady (příp. zadání požadavku), do okamžiku, kdy je, a to buď dočasným, nebo kompletním řešením, závada odstraněna (resp. požadavek vyřešen) vyřešen.

Životní cyklus hlášení závady a uživatelského požadavku je definován skrze následující stavy, viz následující diagram:

• Zadáno – Ticket byl korektně nahlášen, začíná měření Response a Fix time;

• Přiděleno – Dodavatel přidělil Ticket k řešení odpovědnému řešiteli;

• Čekající – Řešení Ticketu čeká na aktivitu Zadavatele nebo třetí strany, Fix time je pozastaven;

• V yřešen – Ticket je Dodavatelem vyřešen.

Poskytování podpory zahrnuje:

• Hot-line prostřednictvím HelpDesku, telefonu či e-mailu pro vyjmenované pracovníky Zadavatele (tj. odpovědi na otázky k užívání a fungování systému, příjem požadavků, hlášení závad, stav Ticketů);

• Řešení požadavků KÚSK, například příprava/úprava sestav/výkazů, změny/migrace dat, změna/definice uživatelských rolí, vytvoření nového uživatele, optimalizace konfigurace, doplnění číselníku apod.;

• Podpora při vytváření plánů obnovy, provádění testů obnovy a dostupnosti systému;

• Řešení problémových stavů v datech vzniklých činností uživatelů;

• Řešení závad a nepravidelností v provozu systému;

• Osobní asistence při administraci systému;

• Metodická pomoc, účast a asistence na metodických jednáních;

• Konzultace otázek spojených s užíváním systému či integrací systému na jiné IS.

V případě, že Zadavatel kontaktuje ▇▇▇▇▇▇▇▇▇▇ s požadavkem na podporu ohledně úkonů, které nejsou součástí podpory, zasílá Dodavatel tento požadavek zpět na Zadavatele s odůvodněním (bez povinnosti předávat tento požadavek k řešení). Mezi takové požadavky jsou zařazeny zejména:

• Závady v IT infrastruktuře;

• Požadavky na přizpůsobení nebo změny funkcí systému;

• Správa instalací na stanicích uživatelů.

Zadávání požadavků v rámci podpory a údržby a s tím související komunikace úkonů podpory Dodavatele bude realizována primárně pomoci ServiceDesku Dodavatele. Podpora bude Dodavatelem poskytována v pracovních dnech od 7:00 do 19:00 hodin. Mimo tuto dobu zadává Zadavatel požadavky písemnou formou (email, web), a Dodavatel tyto požadavky řeší přednostně při nejbližším termínu běžné pracovní doby poskytování podpory. Telefonická podpora v pracovní době (od 7:00 do 19:00 hodin) slouží pro operativní vyřizování dotazů oprávněných pracovníků Zadavatele. V případě potřeby změnit prioritu řešení nebo v případě potřeby koordinace řešení s dalšími dodavateli, eskaluje Dodavatel tyto informace bezodkladně na Zadavatele skrze ServiceDesk popř. odpovědné pracovníky Odboru informatiky Zadavatele.

Zadavatel bude realizovat měření dostupnosti služby a dalších systémů s pomocí monitorovacího nástroje, který ověřuje dostupnost aplikací pravidelnými automatizovanými dotazy.

Podrobná specifikace služeb (SLA) se vypočítává dle času technologické podpory a je vymezena následovně:

Dostupnost (v provozním čase)	98% Dostupnost = ((požadovaná doba dostupnosti – suma (doby nedostupnosti podle měření) / (doba dostupnosti)) * 100
Technologická podpora	5x9 Po-Ne 8:00 – 17:00
Zadávání požadavků ServiceDesk (email, web)	7x24
Odezva (Response time)	Dle detailu priorit v následující tabulce
Řešení (Fix time)	Dle detailu priorit v následující tabulce
Plánovaná údržba	Mimo provozní čas, souvislá délka odstávky max. 4 hodiny - servisní okno

Kategorie priorit – řešení jednotlivých požadavků:

Priorita/kategorie vady	Popis	Odezva (Response time)	Řešení do (Fix time)
1 – kritická Kategorie vady A	Systém nefunguje vůbec nebo jeho nefunkčnost je omezena tak, že tento stav má významný dopad na klíčové procesy Zadavatele Aplikaci nebo některou její klíčovou funkci není možné používat Dochází k narušení uživatelských dat závažným způsobem Dochází ke zhroucení systému jednou nebo několikrát za den	1 hod.	4 hod.
2 – vysoká Kategorie vady B	Funkce systému je narušena tak, že dochází k významnému zpomalení výkonu klíčových procesů Zadavatele.	2 hod.	8 hod.
3 – střední Kategorie vady C	Funkce systému je omezena, ale toto omezení má minimální vliv na zpracování klíčových procesů Zadavatele Závada narušuje, avšak neznemožňuje využití systému Blokuje dokončení určitých úkolů, které nejsou časově kritické působí dílčí závadu nebo nepohodlí uživatele procesní závada (vyřeší se změnou procesu) Tuto závadu lze jiným náhradním dočasným způsobem (např. ruční úpravou dat) nebo dočasnou změnou pracovního postupu obejít (workround). Uživatel však musí vykonat vícepráce na obejití závady.	4 hod.	24 hod.
4 – nízká Kategorie vady D	Systém je funkční. Závada způsobuje jen minimální obtíže při jeho používání. Jde o situace, kdy: vznikne malý problém nebo nepohodlí obsluhy kosmetická chyba ve vizuálním rozhraní (chybné popisy, řazení dat, překreslování) Uživatel nemusí vykonat vícepráce na obejití závady. Způsobuje mu nepohodlí při práci (např. pohyb myší navíc, klik myší navíc, stisk několika kláves navíc atp.).	8 hod.	120 hod.

Lhůty se ve věcech reakčních dob (Response time) pro řešení požadavků počítají v rámci pracovní doby Zadavatele, tedy běh lhůty se pozastavuje na konci každého pracovního dne a obnovuje na počátku pracovní doby následujícího pracovního dne. Pracovní doba se pro tento případ definuje od 8:00 do 17:00. Pozastavení počítání lhůty s koncem pracovní doby neplatí pro řešení chyby kategorie A. Není-li vzájemně dohodnuto jinak, lhůta pro měření doby reakce a doby odstranění požadavku započne běžet časem předání požadavku Dodavateli a bude ukončena v čase předání vyřešeného požadavku zpět Zadavateli. Celková doba odstranění je pak součet všech časových dob, po které byl požadavek v řešení na straně Dodavatele. Z celkové doby odstranění incidentu jsou vyloučeny časové doby, kdy Dodavatel prokazatelně nemohl pokračovat v řešení požadavku z důvodů, které nebyly jim způsobené.

Způsob plnění, termíny, akceptace:

Plnění služby Dodavatel vykazuje do protokolu na měsíční bázi. Protokol vyhodnotí stav plnění všech parametrů SLA (Response time, Fix time) dle kategorie Ticketu, dále udává statistické informace jako průměrné splněné SLA hodnoty, průměrné nesplněné SLA hodnoty, celkový počet požadavků dle stavu a kategorie, a jiné relevantní údaje podle dohody se Zadavatelem.

6.1.10Znalostní podpora a provedení nezbytných úkonů při ukončení ▇▇▇▇▇▇▇ a předání služeb na jiného dodavatele

Podpora a provedení nezbytných úkonů při ukončení smlouvy a předání služeb na jiného dodavatele zahrnuje následující požadavky na Dodavatele:

• Vypracování plánu exitu a podpory předávání znalostí novému dodavateli;

• Předání veškeré zpracované technické a provozní dokumentace systému podle plánu.

Zadavatel poskytne Dodavateli součinnost v následujícím rozsahu:

• Zadavatel umožní odborným pracovníkům Dodavatele provádět fyzické prohlídky provozního prostředí Zadavatele.

• Zadavatel zajistí a poskytne Dodavateli přístup do úložiště dokumentů a repozitářů, které budou sloužit ke sdílení veškerých elektronických dokumentů, architektonických návrhů vytvořených Dodavatelem v rámci plnění této veřejné zakázky.

• Zadavatel akceptuje od Dodavatele výstupy dle výše popsaných náležitostí.

• Dodavatel je povinen poskytnout službu na výzvu Zadavatele, nejpozději však 2 měsíce před vypršením smlouvy.

• Odměna za službu je zahrnuta v ceně poskytování podpory.

• Vady rozvojových aktivit, respektive rozpory zjištěné a oznámené Zadavatelem Dodavateli během doby aktivní podpory a údržby je Dodavatel povinen na vlastní náklady odstranit bez zbytečného odkladu po jejich oznámení. Nejpozději však ve smluvně stanovených lhůtách. Dodavatel se zavazuje odstranit vady systému, které se na systému vyskytnou v průběhu záruční doby.

• Dodavatel se zprostí odpovědnosti za vady v případě, prokáže-li, že vada byla způsobena poskytnutím nesprávných informací i ze strany Zadavatele či jeho nevhodnými pokyny, na kterých trval.

• Zadavatel je povinen informovat Dodavatele o jakékoliv vadě systému, na niž se vztahuje záruka, bez zbytečného odkladu po jejím vzniku. Vady musí být již při jejich uplatnění srozumitelně a přesně popsány. Poté, co Zadavatel řádně nahlásí vadu prokazatelným způsobem, Dodavatel odstraní závady ve stanovených lhůtách dle jejich charakteru a závažnosti.

Za vady systému se nepovažují poruchy funkčnosti nebo odchylky od zadávací dokumentace, které jsou důsledkem:

• Použití systému či jeho části pro jiné účely, než pro jaké je určen dle dokumentace a použití systému či jeho části v rozporu s příslušnou dokumentací, která se váže k systému či jeho části.

• Provedení změny systému či jeho části anebo jiný neoprávněný zásah Zadavatele nebo třetí strany bez vědomí a souhlasu Dodavatel.

• Změny v SW nebo HW, na kterých systém pracuje nebo je s nimi propojen, nebo na kterých je jinak závislý, pokud tyto změny provedl Zadavatel nebo třetí strana bez vědomí a souhlasu Dodavatele.

• Vada nebo porucha SW nebo HW, které nebyly předmětem dodávky, a na kterých systém pracuje nebo je s nimi propojen, nebo na kterých je systém závislý.

7Technická specifikace SAIW

7.1Obecné požadavky na cílové řešení SAIW

Bude implementován systém pro řízení komunikačních scénářů při řešení bezpečnostních incidentů. SAIW, zajistí zasílání notifikací řešitelům, evidenci bezpečnostních událostí a incidentů a jejich propagaci do centrálního helpdeskového řešení Zadavatele (IT provozní portál iTop – verze 2.7.7-9622, popř. vyšší verze) a informování zainteresovaných osob o možných bezpečnostních událostech či incidentech vč. zajištění vazeb na NGFW a IDM, resp. technologickou a aplikační architekturu.

7.1.1Funkční a nefunkční požadavky na řešení

Funkční a nefunkční požadavky technologie SAIW jsou obsahem Přílohy č. 5c Zadávací dokumentace.

7.1.2Implementace řešení

V rámci tohoto bodu se jedná především o následující aktivity:

• zavedení systému pro automatizaci incidenční workflow,

• integrace na systémy Helpdesk iTop, s vazbou na NGFW a IDM.

7.1.3Dodávka potřebných licencí k produktu

Dodavatel dodá potřebné licence, jejich maintenance a převod na KÚSK. Dodavatel bude poskytovat podporu po dobu 60 měsíců.

7.1.4Školení

Dodavatel připraví plán školení pro proškolení obsluhujícího personálu. Cílem proškolení obsluhujícího personálu je předání informací k obsluze implementovaného řešení v takové míře, aby mohl být proveden pilotní provoz. Školení obsluhujícího personálu proběhne minimálně na těchto úrovních:

• školení administrátorů v rozsahu 1 MD,

• školení personálu využívající systém v rozsahu 1 MD.

7.1.5Uvedení pilotního provozu HW a SW vybavení a všech naimplementovaných řešení v rámci projektu 

Dodavatel uvede systém do pilotního provozu. Účelem pilotního provozu je ověření funkčních vlastností implementovaného systému. Uvedení systému do pilotního provozu zahrnuje následující aktivity: 

• Vytvoření produkčního prostředí v TCK;

• Provedení migrace řešení z testovacího prostředí do produkčního;

• Aktualizace dokumentace, školení uživatelů a řízení změn;

• Vyhodnocení pilotního provozu a realizace nápravných opatření. 

7.1.6Uvedení systému do produkčního provozu 

Dodavatel uvede systém do produkčního provozu. Uvedení systému do produkčního provozu zahrnuje následující aktivity: 

• Uvedení do ostrého provozu včetně poskytování zvýšeného dohledu;

• Finální akceptace. 

7.1.7Údržba systému

Úkony údržby jsou vykazované nejpozději v následujícím měsíci po jejich provedení. Do úkonů údržby se zahrnují:

Profylaxe – Dodavatel provádí pravidelnou kontrolu a vyhodnocení stavu systému. Dodavatel na základě vyhodnocení stavu systému upozorňuje Zadavatele na nepravidelnosti v provozu systému a provádí změny konfigurací a další úkony potřebné k zajištění spolehlivého běhu systému. Dodavatel dále na základě vyhodnocení stavu systému doporučuje opatření k zajištění zdrojů pro udržení výkonu systému. Součástí dodávky je také pravidelný přenos kopie produkčních dat do testovacího prostředí včetně nastavování prostředí systému a integračních vazeb na testovací instance jiných informačních systémů).

• Minimální četnost: 1x za 3 měsíce;

• Způsob měření a vykazování: výčet provedených úkonů;

• Předpokládané časy údržby: podle dohody se Zadavatelem.

Dodávka a aplikace záplat a aktualizací – Dodavatel průběžně sleduje bezpečnostní upozornění, bezpečnostní a funkční záplaty a aktualizace systému včetně doporučení k jejich nasazení vydané výrobcem. Dodavatel vydané záplaty a aktualizace otestuje a doporučí Zadavateli termín a způsob jejich nasazení. Zadavatel rozhodne o doporučení. Dodavatel následně provádí úkony podle rozhodnutí Zadavatele.

• Četnost: průběžně;

• Způsob měření a vykazování: výčet aplikovaných záplat;

• Předpokládané časy údržby: podle dohody se Zadavatelem.

Průběžná aktualizace provozní a technické dokumentace – Dodavatel pravidelně provádí aktualizace provozní a technické dokumentace systému na základě změn do skutečného provedení systému provedených Dodavatelem nebo Zadavatelem, včetně popisu skutečného provedení systému pro testovací i ostré prostředí (architektonické modely v otevřeném formátu jazyka Archimate, popis technologií a konfigurací); popisu změn jednotlivých modulů při aktualizacích; popisu nasazovaných záplat a aktualizací včetně podmínek jejich nasazení; požadavků na koncové stanice, servery a infrastrukturu; uživatelských a systémových příruček s popisem provozních postupů; popisu pravidel, rozsahu a podmínek zálohování systému v různých prostředích.

• Minimální četnost: 2x ročně;

• Způsob měření a vykazování: výčet změn podle dokumentů;

• Předpokládané časy údržby: podle dohody se Zadavatelem.

Zadavatel poskytne Dodavateli součinnost v následujícím rozsahu:

• Zadavatel poskytne Dodavateli technický popis prostředí IT Zadavatele, zejména konfigurační standardy platforem a standardy provozních postupů.

• Zadavatel umožní odborným pracovníkům Dodavatele provádět fyzické prohlídky provozního prostředí Středočeského kraje, ve kterém je provozován systému.

• Zadavatel zajistí a poskytne Dodavateli přístup do úložiště dokumentů a repozitářů, které budou sloužit ke sdílení veškerých elektronických dokumentů, architektonických návrhů a balíčků zdrojových kódu vytvořených Dodavatelem v rámci plnění této veřejné zakázky.

• Zadavatel posoudí a schválí Plán nasazení legislativních změn do systému předložený Zadavatelem.

• Zadavatel posoudí doporučení Dodavatele a rozhodne o nasazení záplat a aktualizací technologie SAIW.

Způsob plnění, termíny, akceptace:

• Aktivity údržby jsou vykazovány do předem definovaných šablon dle výše popsaných požadavků.

• Dodavatel bude při svých dodávkách koordinovat svoje činnosti s pracovníky odboru informatiky Zadavatele tak, aby provoz systému odpovídal kontextu prostředí Zadavatele, tj. respektoval omezení datových toků infrastruktury a využití zdrojů platforem a korektně využíval centrální služby IT (např. zdroj přesného času, služby zálohování, jmenné a autentizační služby apod.) Odpovědnost za koordinaci činností Dodavatele s provozovateli infrastruktury IT, platforem a integrovaných informačních systémů na sebe bere Zadavatel.

• Plnění služby je zahájeno dnem akceptace výstupů služby.

• Dodavatel je povinen provádět údržbu systému do doby ukončení Smlouvy.

7.1.8Standardní podpora systému

Zadavatel definuje 3 požadované úrovně podpory – L1, L2, L3:

• L1: HelpDesk Zadavatele – pro každodenní drobnou podporu všech uživatelů systému, zajišťuje Zadavatel svými silami;

• L2: ServiceDesk Dodavatele – pro běžně náročné úkony podpory, pouze pro oprávněné pracovníky Kraje, provádí Dodavatel;

• L3: Odborníci Dodavatele – pro náročné úkony podpory vyžadující expertní znalost, pouze pro oprávněné pracovníky Kraje, provádí Dodavatel.

Pro účely poskytování podpory definuje Zadavatel:

• SLA: jedná se o domluvenou úroveň kvality služeb, kterou ▇▇▇▇▇▇▇▇▇ garantuje Zadavateli.

• Uživatelský požadavek: jedná se o Ticket popisující požadavek uživatele systému na podporu Dodavatelem, a to pří úkonech zahrnutých do rozsahu podpory. Obsahuje popis požadavku, čas vytvoření, kontaktní osobu, kategorii požadavku, analýzu požadavku a návrh řešení, analýzu dopadů řešení, popis úkonů provedených k vyřešení požadavku, historii změn stavů Ticketu a další informace vztahující se k řešení požadavku.

• Závada: znamená nesoulad skutečné funkčnosti systému s funkčností, jež je popsána technickou dokumentací.

• Kybernetický incident: jde o narušení bezpečnosti informací v informačních systémech nebo narušení bezpečnosti služeb anebo bezpečnosti a integrity sítí elektronických komunikací v důsledku kybernetické bezpečnostní události.

• Hlášení závady: jedná se o Ticket popisující výskyt závady. Obsahuje popis závady, čas hlášení, kontaktní osobu, kategorii závady, vyhodnocení dopadů a příčin závady, popis úkonů provedených k odstranění závady, historii změn stavů Ticketu a další informace vztahující se k řešení závady.

• Response time: jedná se o dobu od okamžiku zadání uživatelského požadavku (příp. hlášení závady) do okamžiku, kdy je ▇▇▇▇▇▇▇▇▇▇ sděleno, že ▇▇▇▇▇▇ s jeho požadavkem (resp. hlášením) je přijat a bylo zahájeno jeho zpracování.

• Fix time: jedná se o dobu počínající okamžikem nahlášení závady (příp. zadání požadavku), do okamžiku, kdy je, a to buď dočasným, nebo kompletním řešením, závada odstraněna (resp. požadavek vyřešen) vyřešen.

Životní cyklus hlášení závady a uživatelského požadavku je definován skrze následující stavy, viz následující diagram:

• Zadáno – Ticket byl korektně nahlášen, začíná měření Response a Fix time;

• Přiděleno – Dodavatel přidělil Ticket k řešení odpovědnému řešiteli;

• Čekající – Řešení Ticketu čeká na aktivitu Zadavatele nebo třetí strany, Fix time je pozastaven;

• V yřešen – Ticket je Dodavatelem vyřešen.

Poskytování podpory zahrnuje:

• Hot-line prostřednictvím HelpDesku (s integrací na ServiceDesk Zadavatele – iTop – IT provozní portál), telefonu či e-mailu pro vyjmenované pracovníky Zadavatele (tj. odpovědi na otázky k užívání a fungování systému, příjem požadavků, hlášení závad, stav Ticketů);

• Řešení požadavků KÚSK, například příprava/úprava sestav/výkazů, změny/migrace dat, změna/definice uživatelských rolí, vytvoření nového uživatele, optimalizace konfigurace, doplnění číselníku, apod.;

• Podpora při vytváření plánů obnovy, provádění testů obnovy a dostupnosti systému;

• Řešení problémových stavů v datech vzniklých činností uživatelů;

• Řešení závad a nepravidelností v provozu systému;

• Osobní asistence při administraci systému;

• Metodická pomoc, účast a asistence na metodických jednáních;

• Konzultace otázek spojených s užíváním systému či integrací systému na jiné IS.

V případě, že Zadavatel kontaktuje ▇▇▇▇▇▇▇▇▇▇ s požadavkem na podporu ohledně úkonů, které nejsou součástí podpory, zasílá Dodavatel tento požadavek zpět na Zadavatele s odůvodněním (bez povinnosti předávat tento požadavek k řešení). Mezi takové požadavky jsou zařazeny zejména:

• Závady v IT infrastruktuře;

• Požadavky na přizpůsobení nebo změny funkcí systému;

• Správa instalací na stanicích uživatelů.

Zadávání požadavků v rámci podpory a údržby a s tím související komunikace úkonů podpory Dodavatele bude realizována primárně pomoci ServiceDesku Dodavatele. Podpora bude Dodavatelem poskytována v pracovních dnech od 7:00 do 19:00 hodin. Mimo tuto dobu zadává Zadavatel požadavky písemnou formou (email, web), a Dodavatel tyto požadavky řeší přednostně při nejbližším termínu běžné pracovní doby poskytování podpory. Telefonická podpora v pracovní době (od 7:00 do 19:00 hodin) slouží pro operativní vyřizování dotazů oprávněných pracovníků Zadavatele. V případě potřeby změnit prioritu řešení nebo v případě potřeby koordinace řešení s dalšími dodavateli, eskaluje Dodavatel tyto informace bezodkladně na Zadavatele skrze ServiceDesk popř. odpovědné pracovníky Odboru informatiky Zadavatele.

Zadavatel bude realizovat měření dostupnosti služby a dalších systémů s pomocí monitorovacího nástroje, který ověřuje dostupnost aplikací pravidelnými automatizovanými dotazy.

Podrobná specifikace služeb (SLA) se vypočítává dle času technologické podpory a je vymezena následovně:

Dostupnost (v provozním čase)	98% Dostupnost = ((požadovaná doba dostupnosti – suma (doby nedostupnosti podle měření) / (doba dostupnosti)) * 100
Technologická podpora	5x9 Po-Ne 8:00 – 17:00
Zadávání požadavků ServiceDesk (email, web)	7x24
Odezva (Response time)	Dle detailu priorit v následující tabulce
Řešení (Fix time)	Dle detailu priorit v následující tabulce
Plánovaná údržba	Mimo provozní čas, souvislá délka odstávky max. 4 hodiny - servisní okno

Kategorie priorit – řešení jednotlivých požadavků:

Priorita/kategorie vady	Popis	Odezva (Response time)	Řešení do (Fix time)
1 – kritická Kategorie vady A	Systém nefunguje vůbec nebo jeho nefunkčnost je omezena tak, že tento stav má významný dopad na klíčové procesy Zadavatele Aplikaci nebo některou její klíčovou funkci není možné používat Dochází k narušení uživatelských dat závažným způsobem Dochází ke zhroucení systému jednou nebo několikrát za den	1 hod.	4 hod.
2 – vysoká Kategorie vady B	Funkce systému je narušena tak, že dochází k významnému zpomalení výkonu klíčových procesů Zadavatele.	2 hod.	8 hod.
3 – střední Kategorie vady C	Funkce systému je omezena, ale toto omezení má minimální vliv na zpracování klíčových procesů Zadavatele Závada narušuje, avšak neznemožňuje využití systému Blokuje dokončení určitých úkolů, které nejsou časově kritické působí dílčí závadu nebo nepohodlí uživatele procesní závada (vyřeší se změnou procesu) Tuto závadu lze jiným náhradním dočasným způsobem (např. ruční úpravou dat) nebo dočasnou změnou pracovního postupu obejít (workround). Uživatel však musí vykonat vícepráce na obejití závady.	4 hod.	24 hod.
4 – nízká Kategorie vady D	Systém je funkční. Závada způsobuje jen minimální obtíže při jeho používání. Jde o situace, kdy: vznikne malý problém nebo nepohodlí obsluhy kosmetická chyba ve vizuálním rozhraní (chybné popisy, řazení dat, překreslování) Uživatel nemusí vykonat vícepráce na obejití závady. Způsobuje mu nepohodlí při práci (např. pohyb myší navíc, klik myší navíc, stisk několika kláves navíc atp.).	8 hod.	120 hod.

Lhůty se ve věcech reakčních dob (Response time) pro řešení požadavků počítají v rámci pracovní doby Zadavatele, tedy běh lhůty se pozastavuje na konci každého pracovního dne a obnovuje na počátku pracovní doby následujícího pracovního dne. Pracovní doba se pro tento případ definuje od 8:00 do 17:00. Pozastavení počítání lhůty s koncem pracovní doby neplatí pro řešení chyby kategorie A. Není-li vzájemně dohodnuto jinak, lhůta pro měření doby reakce a doby odstranění požadavku započne běžet časem předání požadavku Dodavateli a bude ukončena v čase předání vyřešeného požadavku zpět Zadavateli. Celková doba odstranění je pak součet všech časových dob, po které byl požadavek v řešení na straně Dodavatele. Z celkové doby odstranění požadavku jsou vyloučeny časové doby, kdy Dodavatel prokazatelně nemohl pokračovat v řešení incidentu z důvodů, které nebyly jim způsobené.

Způsob plnění, termíny, akceptace:

Plnění služby Dodavatel vykazuje do protokolu na měsíční bázi. Protokol vyhodnotí stav plnění všech parametrů SLA (Response time, Fix time) dle kategorie Ticketu, dále udává statistické informace jako průměrné splněné SLA hodnoty, průměrné nesplněné SLA hodnoty, celkový počet Ticketů dle stavu a kategorie, a jiné relevantní údaje podle dohody se Zadavatelem. Čas podpory se měří pomocí HelpDesku Zadavatele.

7.1.9Znalostní podpora a provedení nezbytných úkonů při ukončení ▇▇▇▇▇▇▇ a předání služeb na jiného dodavatele

Podpora a provedení nezbytných úkonů při ukončení smlouvy a předání služeb na jiného dodavatele zahrnuje následující požadavky na Dodavatele:

• Vypracování plánu exitu a podpory předávání znalostí novému dodavateli.

• Předání veškeré zpracované technické a provozní dokumentace systému podle plánu.

• Zadavatel poskytne Dodavateli součinnost v následujícím rozsahu:

• Zadavatel umožní odborným pracovníkům Dodavatele provádět fyzické prohlídky provozního prostředí Zadavatele.

• Zadavatel zajistí a poskytne Dodavateli přístup do úložiště dokumentů a repozitářů, které budou sloužit ke sdílení veškerých elektronických dokumentů, architektonických návrhů vytvořených Dodavatelem v rámci plnění této veřejné zakázky.

Zadavatel akceptuje od Dodavatele výstupy dle výše popsaných náležitostí.

Dodavatel je povinen poskytnout službu na výzvu Zadavatele, nejpozději však 2 měsíce před vypršením smlouvy.

Odměna za službu je zahrnuta v ceně poskytování podpory.

Vady rozvojových aktivit, respektive rozpory zjištěné a oznámené Zadavatelem Dodavateli během doby aktivní podpory a údržby je Dodavatel povinen na vlastní náklady odstranit bez zbytečného odkladu po jejich oznámení. Nejpozději však ve smluvně stanovených lhůtách. Dodavatel se zavazuje odstranit vady systému, které se na systému vyskytnou v průběhu záruční doby.

Dodavatel se zprostí odpovědnosti za vady v případě, prokáže-li, že vada byla způsobena poskytnutím nesprávných informací i ze strany Zadavatele či jeho nevhodnými pokyny, na kterých trval.

Zadavatel je povinen informovat Dodavatele o jakékoliv vadě systému, na niž se vztahuje záruka, bez zbytečného odkladu po jejím vzniku. Vady musí být již při jejich uplatnění srozumitelně a přesně popsány. Poté, co Zadavatel řádně nahlásí vadu prokazatelným způsobem, Dodavatel odstraní závady ve stanovených lhůtách dle jejich charakteru a závažnosti.

Za vady systému se nepovažují poruchy funkčnosti nebo odchylky od zadávací dokumentace, které jsou důsledkem:

• Použití systému či jeho části pro jiné účely, než pro jaké je určen dle dokumentace a použití systému či jeho části v rozporu s příslušnou dokumentací, která se váže k systému či jeho části.

• Provedení změny systému či jeho části anebo jiný neoprávněný zásah Zadavatele nebo třetí strany bez vědomí a souhlasu Dodavatel.

• Změny v SW nebo HW, na kterých systém pracuje nebo je s nimi propojen, nebo na kterých je jinak závislý, pokud tyto změny provedl Zadavatel nebo třetí strana bez vědomí a souhlasu Dodavatele.

Vada nebo porucha SW nebo HW, které nebyly předmětem dodávky, a na kterých systém pracuje nebo je s nimi propojen, nebo na kterých je systém závislý.

Technická specifikace Strana 1