Příloha 2 smlouvy: Podrobná specifikace služeb servisní a technické podpory a maintenance

Příloha 2 smlouvy: Podrobná specifikace služeb servisní a technické podpory a maintenance

Obsah:

1. Seznam zkratek a pojmů 2

2. Maintenance 3

3. Service Desk 4

3.1. Oprávnění pracovníci Objednatele 4

3.2. Základní parametry služby 5

3.3. Komunikační kanály Service Desku 5

4. Řízení a řešení Incidentů 5

4.1. Závazná pravidla a postupy procesu řízení a řešení Incidentů 5

4.2. Klasifikace závažnosti Incidentu 6

4.2.1. Posouzení kritičnosti vzniklého problému 7

4.2.2. Posouzení kritičnosti části systému (subsystému), v němž problém vznikl 7

4.3. SLA pro Řízení a řešení Incidentů 9

5. Poskytování součinnosti při HW nebo SSW havárii 9

5.1. Závazná pravidla a postupy procesu Poskytování součinnosti při HW nebo SSW havárii 10

5.2. Klasifikace závažnosti požadavku 11

5.2.1. Posouzení kritičnosti vzniklého problému 11

5.2.2. Posouzení kritičnosti části systému (subsystému), v němž problém vznikl 11

5.3. SLA pro řešení Požadavků na součinnost při HW nebo SSW havárii 11

6. Řízení a řešení Změnových požadavků 12

6.1. Závazná pravidla a postupy procesu řízení a řešení Změnových požadavků 12

6.2. SLA pro Řízení a řešení Změnových požadavků 13

7. Service Management, reporting 13

7.1. Service Management 13

7.2. Reporting parametrů poskytovaných služeb 13

1. Seznam zkratek a pojmů

Zkratka či pojem	Vysvětlení zkratky či význam pojmu
SW = software; ASW = aplikační software, SSW = systémový software	Sada počítačových programů, které provádějí nějakou činnost. Software lze rozdělit na aplikační, se kterým pracuje uživatel, a na systémový software, který zajišťuje chod hardware (operační systém …) nebo prostředí nezbytné pro běh aplikačního software (databáze, midleware …).
HW = hardware	fyzicky existující technické vybavení.
Update SW	Aktualizace SW z důvodu opravy funkčních bezpečnostních či jiných chyb, prostřednictvím tzv. záplat (= patchů) aplikačního software.
Upgrade SW	Rozšíření SW, povýšení na novou verzi aplikačního software, s novými funkcemi.
Pracovní doba služby Service Desk	Doba, ve které jsou služby pro Objednatele dostupné. Je identická s pracovní dobou úřadu:
	• Po 7:00 - 12:00 a 12:30 - 18:00;
	• St 7:00 - 12:00 a 12:30 - 18:00;
	• Út 7:00 - 11:30 a 12:00 - 14:00;
	• Čt 7:00 - 11:30 a 12:00 - 14:00;
	• Pá 7:00 - 13:00 (není úředním dnem).
Požadavek na Service Desk (nebo také zkráceně Požadavek)	Každý Požadavek Objednatele typu: • Incident • Požadavek na poskytnutí součinnosti při HW nebo SSW havárii • Změnový požadavek
	Každý Požadavek je zaznamenán ve webové aplikaci Service Desk.
Incident	Indikovaná vada či jiný problém systému „Konsolidace IT“ či jeho části. Jelikož je systém „Konsolidace IT“ aplikačním softwarovým vybavením, které nezahrnuje systémový software (databáze, operační systémy…), je incidentem vada či chyba aplikačního software tvořícího systém „Konsolidace IT“.
Požadavek na poskytnutí součinnosti při HW nebo SSW havárii	Požadavek Objednatele na dodávku služeb Poskytovatele, které při HW nebo SSW havárii pomohou Objednateli obnovit provoz systému „Konsolidace IT“ či jeho části.
Změnový požadavek	Požadavek Objednatele na drobnou úpravu některé části systému „Konsolidace IT“. Drobnou úpravou se rozumí změna, respektive rozšíření programového kódu aplikačního software s pracností Poskytovatele v jednotkách člověkodnů.

Zkratka či pojem	Vysvětlení zkratky či význam pojmu
Příjem požadavku na Service Desk	Okamžik, kdy Objednatel nahlásí Požadavek na Service Desk Poskytovateli prostřednictvím Service Desku.
Odpověď na Požadavek na Service Desk	Je formulována Poskytovatelem na základě detailní analýzy Požadavku na Service Desk a obsahuje detailní informace nezbytné k vyřešení požadavku. Poskytovatel je oprávněn Požadavek odmítnout. Odpověď v takovém případě musí obsahovat odůvodnění odmítnutí. Pokud není Požadavek v Odpovědi odmítnut, má se za to, že Poskytovatel akceptoval přijetí Požadavku.
Odezva (Response Time)	Je časová lhůta, ve které je Poskytovatel povinen Objednateli poskytnout Odpověď na Požadavek na Service Desk.
Odstranění vady / Vyřízení požadavku (Fix Time)	Je časová lhůta, ve které je Poskytovatel povinen vyřešit Požadavek na Service Desk. • V případě požadavku typu Incident hovoříme o lhůtě pro Odstranění vady nebo Vyřešení Incidentu. • V případě požadavku typu Požadavek na poskytnutí součinnosti při HW nebo SSW havárii nebo Změnový požadavek hovoříme o lhůtě pro Vyřízení požadavku.
SLA = Service Level Agreement	Garantované parametry služby.
SLA pro řešení Požadavku na Service Desk	Response Time a Fix Time Požadavku.
NBD	Následující pracovní den od Příjmu Požadavku na Service Desk.
nNBD	N-tý následující pracovní den od Příjmu Požadavku na Service Desk.
Disponibilní kapacita	Kapacita Poskytovatele v rozsahu 2 člověkodnů za kvartál, kterou je Objednatel oprávněn využívat pro realizaci Změnových požadavků.

2. Maintenance

Maintenance je program průběžné úpravy softwarových produktů tvořících systém „Konsolidace IT“ definovaného jednotlivými Subsystémy uvedenými v kap. 4.2.2. Maintenance není poskytováno na níže uvedené Subsystémy a jejich související Rozhraní:

1. TS-ELDAX + DMS: Důvěryhodná archivace elektronických dokumentů

2. DMS: Elektronizace vnitřního systému pro řízení a oběh dokumentů;

3. Rozhraní: DMS – spisová služba

4. Portál občana

Průběžné úpravy aplikačního software realizuje Poskytovatel a jsou prováděny z důvodu aplikace legislativních změn do aplikačního software a z důvodu kontinuálního zlepšování aplikačního software spočívajícího v optimalizaci SW, doplňování a rozšiřování SW, zvyšování bezpečnosti SW a zlepšování provozních vlastností SW.

Poskytovatel služby Maintenance je povinen zajistit tyto činnosti:

• pravidelné informování Objednatele o plánu a realizaci úprav aplikačního software;

• vytváření nových verzí a patchů (záplat) v rámci upgrade a update aplikačního software z důvodu:

o aplikování legislativních změn;

o kontinuálního zlepšování aplikačního software;

• zpracování soupisu změn, který popisuje každý patch nebo novou verzi aplikačního software;

• zpracování instalačního postupu pro každý patch nebo novou verzi aplikačního software;

• zpracování doporučení dalšího postupu Objednatele, včetně doporučení zda instalovat patch nebo novou verzi aplikačního software.

Poskytovatel služby Maintenance je oprávněn označit patch nebo novou verzi aplikačního software za nezbytný (respektive nezbytnou).

Objednatel Maintenance je oprávněn všechny výše uvedené služby Poskytovatele využívat dle vlastního uvážení v míře a způsobem jemu vyhovujícím s jedinou výjimkou, kterou je případ, kdy poskytovatel označí patch nebo novou verzi aplikačního software za nezbytný (resp. nezbytnou).

Instalace patche nebo nové verze aplikačního software:

• instalaci patche nebo nové verze aplikačního software kromě dvou níže uvedených výjimek provádí Objednatel dle předaného instalačního postupu;

• pakliže nelze patch nebo novou verzi aplikačního software dle uvedeného postupu nainstalovat, jedná se o Incident a dále se postupuje dle pravidel níže popsaného procesu Řízení a řešení incidentů;

• Objednatel je oprávněn požádat o instalaci patche nebo nové verze aplikačního software prostřednictvím Změnového řízení. V takovém případě se dále se postupuje dle pravidel procesu řízení a řešení Změnových požadavků;

• Poskytovatel provádí instalaci patche nebo nové verze aplikačního software v případě, že:

o Objednatel bude chtít patch nebo novou verzi aplikačního software instalovat a Poskytovatel mu zároveň doporučí, aby instalaci provedl sám Poskytovatel;

o Poskytovatel označí patch nebo novou verzi aplikačního software jako nezbytný (resp. nezbytnou).

3. Service Desk

Předmětem služby Service Desk je poskytnutí jednotného kontaktního místa (SpoC = Single Point of Contact) pro oprávněné pracovníky Objednatele. Veškeré Požadavky týkající se konkrétních poskytovaných služeb Objednateli Poskytovatelem je nutné podávat a řešit prostřednictvím Service Desku.

3.1. Oprávnění pracovníci Objednatele

Pracovníci Objednatele určení k využívání služby Service Desk jsou:

•

•

3.2. Základní parametry služby

Služba Service Desk bude poskytována s těmito vlastnostmi, resp. parametry:

• Dostupnost služby Service Desk (SD): v pracovní době úřadu; pracovní doba úřadu = pracovní doba služby;

• Dostupnost operátora Service Desku (SD): povinnost obsluhy Service Desku potvrdit Příjem požadavku na Service Desk, pracovníkovi Objednatele, který požadavek zadal:

o do 30 min v čase Dostupnosti služby SD;

o mailem nebo SMS zprávou.

• Součástí potvrzení Příjmu požadavku na Service Desk je:

o jednoznačný identifikátor požadavku (ID požadavku);

o název požadavku;

o typ Požadavku

o subsystém respektive část systému „Konsolidace IT“, jež je předmětem Požadavku;

o uvedení času Příjmu požadavku na Service Desk.

• Plánované výluky: probíhají v termínech a v rozsahu po dohodě s Objednatelem. Mohou se realizovat i během pracovní doby služby. Během výluky není služba Service Desk dostupná.

3.3. Komunikační kanál Service Desku

Součástí služby je poskytnutí následujících komunikačních kanálů (prostředků komunikace):

• Elektronická pošta (e-mail):

o e-mailový kontakt na obsluhu Service Desku Poskytovatele:

o komunikace tímto kanálem může probíhat pouze s osobami, objednatele určení k využívání služby Service Desk

• Telefon:

o tento komunikační kanál je doplňkovým kanálem

o telefonní kontakt na Service Desk Poskytovatele:

o eskalační telefonní kontakt na servisního manažera: viz kapitola 7;

4. Řízení a řešení Incidentů

Předmětem poskytované služby je řešení Incidentů v provozním prostředí systému „Konsolidace IT“ s garantovaným časem Odezvy a Odstranění vady. Služba je poskytována prostřednictvím vzdáleného přístupu a/nebo on-site přítomností v datacentru Objednatele.

Služba je poskytována ve třech úrovních, resp. v kategoriích, v závislosti na závažnosti Incidentu. Klasifikaci Incidentu (zařazení do kategorie) provádí Objednatel. Poskytovatel je oprávněn Incident překvalifikovat. Poskytovatel je dále oprávněn Incident odmítnout, pouze však v případě, že se o Incident ve skutečnosti nejedná. V případě nesouhlasu Objednatele s odmítnutím Incidentu, s klasifikací Incidentu či se způsobem řešení Incidentu jsou obě strany povinny zahájit bez zbytečného odkladu eskalační jednání, jehož výsledkem bude konečné a závazné vyřešení nesouladu stanovisek obou stran.

4.1. Závazná pravidla a postupy procesu řízení a řešení Incidentů

1) Incidenty identifikované pracovníky Objednatele jsou hlášeny Poskytovateli výhradně prostřednictvím služby Service Desk, a to oprávněnými pracovníky Objednatele.

2) Objednatel při popisu Incidentu uvede:

a. typ požadavku = Incident;

b. subsystém respektive část systému „Konsolidace IT“, jež vykazuje vadu;

c. popis vady s uvedením informace o tom, jak se vada projevuje a jak lze závadu v produkčním prostředí Objednatele navodit;

d. jméno řešitele Incidentu na straně Objednatele;

e. kategorii Incidentu (závažnost Incidentu).

3) Poskytovatel zodpovídá za příjem Incidentů v Service Desku dle výše uvedené kapitoly 3, a to včetně povinnosti potvrdit Objednateli příjem Incidentu do 30 min od jeho nahlášení.

4) Poskytovatel určí řešitele Incidentu na své straně.

5) Řešitel Incidentu na straně Poskytovatele neprodleně:

a. provede předběžnou analýzu Incidentu;

b. spojí se s řešitelem na straně Objednatele za účelem:

i. Zjištění informací potřebných k provedení detailní analýzy, jejíž výstupem je Odpověď Poskytovatele na Incident;

ii. Sjednání dohody o klíčových závěrech Odpovědi na Incident.

6) Řešitel Incidentu na straně Poskytovatele provede detailní analýzu Incidentu a zpracuje pro

řešitele na straně Objednatele Odpověď na Incident ve lhůtě dané Odezvou (Response Time).

7) V případě Incidentu kategorie A nebo B lze Odpověď na Incident sdělit respektive dohodnout ústně s tím, že písemné zpracování Odpovědi na Incident lze do systému Service Desk doplnit dodatečně avšak neprodleně.

8) Poskytovatel je oprávněn Incident v Odpovědi na Incident odmítnout. Pokud je Odpovědí na Incident odmítnutí a pokud řešitel na straně Objednatele s odmítnutím nesouhlasí, eskaluje Incident na úroveň vedoucího IT (strana Objednatele) a Servisního manažera (strana Poskytovatele).

9) V opačném případě musí Odpověď obsahovat minimálně:

a. způsob a termín řešení Incidentu;

b. součinnost požadovanou po Objednateli, nezbytnou k vyřešení Incidentu včetně specifikace lhůty, ve které je nutno součinnost poskytnout;

c. způsob ověření vyřešení Incidentu;

d. výslednou klasifikaci Incidentu dle závažnosti.

10) Poskytovatel vyřeší Incident (= odstraní vadu) dle SLA uvedených v kapitole 4.3.

4.2. Klasifikace závažnosti Incidentu

Klasifikace závažnosti Incidentu se provede posouzením kritičnosti problému, který nastal a kritičnosti části systému „Konsolidace IT“ ve které problém nastal. Na základě posouzení těchto dvou kritérií se provede klasifikace Incidentu do kategorie A (nejzávažnější závada), B, nebo C (nejméně závažná závada), případně D, dle následujícího obrázku:

Méně důležitý systém	C
Důležitý systém	B
Kritický systém	A
	Kritický problém	Závažný problém	Minoritní problém

Kritičnost subsystému

Kritičnost problému

V subsystémech uvedených v kapitole 4.2.2. mohou vznikat incidenty Kategorie A, B nebo C. Přičemž u Méně důležitého systému, může nastat pouze Incident kategorie C. U Důležitého systému, může nastat Incident kategorie B nebo C. U Kritického systému může nastat Incident kategorie A, B nebo C.

Pakliže je daný Subsystém označen Kritičností – Nedůležitý systém, znamená to, že na daný Subsystém se nevztahuje Klasifikace závažnosti Incidentu v rozmezí A – C. Incidenty Nedůležitých systémů jsou kategorie D.

4.2.1. Posouzení kritičnosti vzniklého problému

Kritický problém: Subsystém (část systému „Konsolidace IT“) zcela selhal, v důsledku čehož je zcela nefunkční.

Závažný problém: Činnost subsystému (části systému „Konsolidace IT“) je podstatně omezena. Některé části selhaly a jsou zcela nefunkční nebo je jejich funkčnost omezena tak, že je zásadním způsobem ovlivněna činnost subsystému.

Minoritní problém: Subsystém (část systému „Konsolidace IT“) je operativní, závada nemá podstatný vliv na činnost subsystému. Vyskytují se nedostatky nepodstatné povahy, které způsobují například nekomfortní ovládání uživatelem ztěžující běžný provoz, resp. zvyšující pracnost činností v běžném provozu.

4.2.2. Posouzení kritičnosti části systému (subsystému), v němž problém vznikl

Pakliže je daný Subsystém označen Kritičností – Nedůležitý systém, znamená to, že na daný Subsystém se nevztahuje Klasifikace závažnosti Incidentu v rozmezí A – C dle kap. 4.2., ani termíny SLA dle kap.

4.3. Případné Incidenty těchto subsystémů budou řešeny v souladu s poskytovanou zárukou dle Kupní smlouvy. Incidenty subsystémů z kategorie – Nedůležitý systém, budou zadávány v souladu s kap. 4. 1

– a budou označeny příznakem „D“.

Ekonomické agendy a služby:

Subsystém	Kritičnost
Rozklikávací rozpočet = elektronizace procesu zveřejňování rozpočtu	Nedůležitý systém
Komunikace s občany = elektronizace agendy pohledávek	Nedůležitý systém

Subsystém	Kritičnost
Evidence poplatku ze psa = elektronizace agendy místních poplatků ze psa	Nedůležitý systém
Evidence veřejných zakázek = elektronizace agendy veřejných zakázek	Méně důležitý systém
Informační panel = elektronizace analytické a manažerské nadstavby	Nedůležitý systém

Formulářové služby pro styk občanů s úřadem:

Subsystém	Kritičnost
Formulářový server: elektronizace podání (žádostí) občanů v rámci vybraných životních situací s legislativní podporou	Méně důležitý systém
Formulářový server: elektronizace podání (žádostí) občanů v rámci vybraných životních situací bez jednoznačné legislativní podpory	Méně důležitý systém
Výherní hrací přístroje = elektronizace agendy výherních hracích přístrojů	Méně důležitý systém
Evidence poplatku ze psa = elektronizace agendy místních poplatků ze psa	Méně důležitý systém
Evidence veřejných zakázek = elektronizace agendy veřejných zakázek	Méně důležitý systém
Informační panel = elektronizace analytické a manažerské nadstavby	Nedůležitý systém

Vnitřní procesy úřadu:

Subsystém	Kritičnost
Formulářový server: Nepřítomnost na pracovišti/dovolenka	Méně důležitý systém
Formulářový server: Cestovní příkaz	Důležitý systém
Formulářový server: Docházka	Méně důležitý systém

Vnitřní systém pro evidenci, řízení a schvalování dokumentů:

Subsystém	Kritičnost
DMS: Elektronizace vnitřního systému pro řízení a oběh dokumentů	Nedůležitý systém
TS-ELDAX + DMS: Důvěryhodná archivace elektronických dokumentů	Nedůležitý systém
Formulářový server: Elektronizace agendy jednání Rady a zastupitelstva	Kritický systém
Formulářový server: Elektronizace oběhu a schvalování faktur	Kritický systém

Zajištění aplikační podpory nebo řešení podpůrných oblastí:

Subsystém	Kritičnost
IDM – Identity Management: SW řešení centrální správy uživatelských účtů	Nedůležitý systém
Rozhraní: evidence VHP – spisová služba	Nedůležitý systém

Subsystém	Kritičnost
Rozhraní: evidence VHP – ekonomika	Nedůležitý systém
Rozhraní: Evidence poplatku ze psa – spisová služba	Nedůležitý systém
Rozhraní: Formulářový server – spisová služba (pro agendy evidence veřejných zakázek, podání žádostí občana, oběh a schvalování faktur realizované v prostředí formulářového serveru	Nedůležitý systém
Rozhraní: DMS – spisová služba	Nedůležitý systém

4.3. SLA pro Řízení a řešení Incidentů

Pro službu Řízení a řešení incidentů garantuje Poskytovatel SLA dle následující tabulky:

Kategorie incidentu (jeho závažnost)	Response Time (Odezva)	Fix Time (Vyřešení)
A	4 hod	2NBD
B	8 hod	5NBD
C	24 hod	28 kalendářních dnů

Tato SLA se počítají od příjmu Incidentu na Service Desk, tedy od okamžiku nahlášení Požadavku na Service Desk. Termínem nNBD je označena lhůta trvající do konce n-tého následujícího pracovní dne. Odezva (Response Time) se počítá během pracovní doby služby Service Desk.

5. Poskytování součinnosti při HW nebo SSW havárii

Předmětem uvedené součinnosti Poskytovatele je poskytování služeb souvisejících s částí systému

„Konsolidace IT“, které pomohou Objednateli obnovit provoz části systému „Konsolidace IT“ při hardwarové (HW) havárii nebo při havárii systémového software (SSW). Služba je poskytována s garantovaným časem Odezvy a Provedení činnosti.

HW havárií se rozumí nefunkčnost HW zařízení, jejíž důsledkem je nefunkčnost systému „Konsolidace IT“ nebo jeho části. SSW havárii se rozumí narušení či poškození systémového software (operační systém, databáze,…) nebo jeho konfigurace, jehož důsledkem je opět nefunkčnost Systému nebo jeho části.

Tuto službu Poskytovatel poskytuje pouze v případě, že se jedná o HW nebo SSW tvořící provozní prostředí systému „Konsolidace IT“ či některé jeho části.

Za odstranění HW či SSW havárie zodpovídá Objednatel. Za účelem odstranění havárie Poskytovatel zajistí v rámci služby Poskytování součinnosti při HW nebo SSW haváriích služby, které po něm bude Objednatel požadovat. Jedná se o:

• konzultace;

• analytické práce (například analýza provozních logů);

• instalace aplikačního software včetně skriptů;

• nastavení parametrů aplikačního software;

• kontrola instalace aplikačního software.

Uvedené služby Poskytovatel poskytuje pouze ve vztahu k aplikačnímu software, nikoliv ve vztahu k HW či SSW a to prostřednictvím vzdáleného přístupu a/nebo on-site přítomností v datacentru Objednatele.

Služba je poskytována na základě Požadavku na poskytnutí součinnosti při HW nebo SSW havárii (dále v této kapitole jen Požadavek), který vznese Objednatel. Služba je poskytována ve třech úrovních, resp. v kategoriích, v závislosti na závažnosti Požadavku. Klasifikaci Požadavku (zařazení do kategorie) provádí Objednatel. Poskytovatel je oprávněn Požadavek překvalifikovat. Poskytovatel je dále oprávněn Požadavek odmítnout, pouze však v případě, že se o Požadavek ve skutečnosti nejedná. V případě nesouhlasu Objednatele s odmítnutím Požadavku, s klasifikací Požadavku či se způsobem řešení Požadavku jsou obě strany povinny zahájit bez zbytečného odkladu eskalační jednání, jehož výsledkem bude konečné a závazné vyřešení nesouladu stanovisek obou stran.

5.1. Závazná pravidla a postupy procesu Poskytování součinnosti při HW nebo SSW havárii

1) Požadavek vznáší Objednatel výhradně prostřednictvím služby Service Desk, a to oprávněnými pracovníky Objednatele.

2) Objednatel při popisu Požadavku uvede:

a. typ požadavku: Požadavek na poskytnutí součinnosti při HW nebo SSW havárii;

b. subsystém respektive část systému „Konsolidace IT“, k němuž se Požadavek vztahuje;

c. popis požadované služby;

d. jméno řešitele havárie na straně Objednatele;

e. kategorii Požadavku (závažnost Požadavku).

3) Poskytovatel zodpovídá za příjem Požadavků dle výše uvedené kapitoly 3, a to včetně povinnosti potvrdit Objednateli příjem Požadavku do 30 min od jeho nahlášení.

4) Poskytovatel určí řešitele Požadavku na své straně.

5) Řešitel Požadavku na straně Poskytovatele neprodleně:

a. Provede předběžnou analýzu Požadavku;

b. Spojí se s řešitelem havárie na straně Objednatele za účelem sjednání dohody o:

i. obsahu a náplni požadované služby;

ii. způsobu a termínu poskytnutí této služby;

iii. způsobu ověření poskytnutí služby.

6) Řešitel Požadavku na straně Poskytovatele provede detailní analýzu Požadavku a zpracuje pro

řešitele havárie na straně Objednatele Odpověď ve lhůtě dané Odezvou (Response Time).

7) V případě Požadavku kategorie A nebo B lze Odpověď sdělit respektive dohodnout ústně s tím, že písemné zpracování Odpovědi lze do systému Service Desk doplnit dodatečně avšak neprodleně.

8) Poskytovatel je oprávněn Požadavek v Odpovědi odmítnout. Pokud je Odpovědí na Požadavek odmítnutí a pokud řešitel na straně Objednatele s odmítnutím nesouhlasí, eskaluje Požadavek na úroveň vedoucího IT (strana Objednatele) a Servisního manažera (strana Poskytovatele).

9) V opačném případě musí Odpověď obsahovat minimálně:

a. specifikace poskytnutých služeb;

b. termín a předpoklady poskytnutí služeb;

c. způsob ověření poskytnutí služby;

d. výsledná klasifikace Požadavku dle závažnosti.

10) Poskytovatel poskytne požadované služby dle SLA uvedených v kapitole 5.3.

5.2. Klasifikace závažnosti požadavku

Kritičnost subsystému

Klasifikace Závažnosti havárie se provede stejně jako v případě Incidentu. Posoudí se tedy kritičnost problému, který nastal a kritičnost části systému „Konsolidace IT“ ve které problém nastal. Na základě posouzení těchto dvou kritérií se provede klasifikace havárie do kategorie A (nejzávažnější závada), B, nebo C (nejméně závažná závada) stejně jako v případě Incidentu, tedy dle následujícího obrázku:

Méně důležitý systém	C
Důležitý systém	B
Kritický systém	A
	Kritický problém	Závažný problém	Minoritní problém

Kritičnost problému

V subsystémech uvedených v kapitole 4.2.2. mohou vznikat Kategorie Závažnosti havárií A, B nebo C. Přičemž u Méně důležitého systému může nastat pouze Závažnost kategorie C. U Důležitého systému může nastat Závažnost kategorie B nebo C. U Kritického systému může nastat Závažnost kategorie A, B nebo C. Pakliže je daný Subsystém označen Kritičností – Nedůležitý systém, znamená to, že na daný Subsystém se nevztahuje Klasifikace závažnosti havárie v rozmezí A – C dle kap. 4.2., ani termíny SLA dle kap. 5.3. Objednatel může dle potřeby po předchozí dohodě s Poskytovatelem za předem stanovených a odsouhlasených podmínek objednat placenou součinnost Poskytovatele. V takovém případě bude poskytována tak, aby nebyla v rozporu s Kupní Xxxxxxxx a s Dokumentací skutečného provedení díla.

5.2.1. Posouzení kritičnosti vzniklého problému

Je stejné jako v případě Incidentu – viz kapitola 4.2.1.

5.2.2. Posouzení kritičnosti části systému (subsystému), v němž problém vznikl

Je stejné jako v případě Incidentu – viz kapitola 4.2.2.

5.3. SLA pro řešení Požadavků na součinnost při HW nebo SSW havárii

Pro službu poskytování součinnosti při HW nebo SSW havárii garantuje Poskytovatel SLA dle následující tabulky:

Kategorie havárie (její závažnost)	Response Time (Odezva)	Fix Time (Vyřešení)
A	4 hod	2NBD
B	8 hod	5NBD
C	24 hod	28 kalendářních dnů

Tato SLA se počítají od příjmu Požadavku na Service Desk, tedy od okamžiku nahlášení Požadavku na Service Desk. Termínem nNBD je označena lhůta trvající do konce n-tého následujícího pracovní dne. Odezva (Response Time) se počítá během pracovní doby služby Service Desk.

6. Řízení a řešení Změnových požadavků

Předmětem služby je realizace Změnových požadavků Poskytovatelem. Realizací se přitom rozumí drobná úprava / rozšíření některé části systému „Konsolidace IT“ a její implementace do testovacího a provozního prostředí Objednatele. Služba je poskytována prostřednictvím vzdáleného přístupu a/nebo on-site přítomností v datacentru Objednatele.

Poskytovatel se zavazuje poskytnout Objednateli dohodnutou Pracovní kapacitu určenou k realizaci Změnových požadavků. Pravidla pro realizaci Změnových požadavků jsou uvedeny v kapitole 6.1 níže.

V případě nesouhlasu Objednatele s řešením Změnového požadavku jsou obě strany povinny zahájit bez zbytečného odkladu eskalační jednání, jehož výsledkem bude konečné a závazné vyřešení nesouladu.

6.1. Závazná pravidla a postupy procesu řízení a řešení Změnových požadavků

1) Změnové požadavky zadává Objednatel Poskytovateli výhradně prostřednictvím služby Service Desk, a to oprávněnými pracovníky Objednatele.

2) Objednatel při popisu Změnového požadavku uvede:

a. typ požadavku = Změnový požadavek;

b. subsystém respektive část systému „Konsolidace IT“, který je předmětem požadované úpravy;

c. popis Změnového požadavku;

d. jméno řešitele Změnového požadavku na straně Objednatele.

3) Poskytovatel určí řešitele Změnového požadavku na své straně.

4) Řešitel Změnového požadavku na straně Poskytovatele se spojí se s řešitelem na straně Objednatele za účelem:

a. Zjištění informací potřebných ke zpracování návrhu řešení;

b. Sjednání dohody o termínu vypracování návrhu řešení.

5) Řešitel Požadavku na straně Poskytovatele zašle řešiteli na straně Objednatele písemný návrh

řešení Změnového požadavku, který bude obsahovat minimálně:

a. popis návrhu řešení;

b. Pracovní kapacitu pracovníků Poskytovatele (v člověkodnech) potřebnou k realizaci Změnového požadavku

c. harmonogram implementace Změnového požadavku (včetně instalace do testovacího a produkčního prostředí);

d. požadavky na součinnost Objednatele;

e. návrh testovacího scénáře k ověření funkčnosti Změnového požadavku.

6) Po písemném odsouhlasení a objednání návrhu řešení Změnového požadavku Objednatelem Poskytovatel zrealizuje Změnový požadavek v souladu s návrhem řešení Změnového požadavku.

7) Pokud v kterékoliv fázi procesu realizace Změnového požadavku nebude řešitel Změnového požadavku na straně Objednatele souhlasit s řešením Změnového požadavku, pak řešitel Změnového požadavku na straně Objednatele eskaluje Změnový požadavek na úroveň vedoucího útvaru IT (strana Objednatele) a Servisního manažera (strana Poskytovatele).

6.2. SLA pro Řízení a řešení Změnových požadavků

Pro službu Řízení a řešení Změnových požadavků neposkytuje Poskytovatel žádná SLA. Veškeré potřebné termíny a lhůty dohodnou obě strany v rámci analytické části procesu realizace Změnového požadavku. Tyto termíny se následně stanou pro Poskytovatele závazné.

7. Service Management, reporting

7.1. Service Management

Předmětem této služby je řízení procesů a koordinace činností nezbytných k zajištění všech výše uvedených služeb:

• Maintenance;

• Service Desk;

• Řízení a řešení Incidentů;

• Poskytování součinnosti při HW nebo SSW havárii;

• Řízení a řešení Změnových požadavků.

Předmětem této služby je dále zpracování kvartálních reportů pro Objednatele popsaných níže v kapitole 7.2, na jejichž základě vyhodnocována a řízena jakost poskytovaných služeb.

Za uvedenou službu Service Management zodpovídá servisní manažer Poskytovatele:

• Jméno:

• Kontakty

o o

7.2. Reporting parametrů poskytovaných služeb

Report o skutečně provedených činnostech servisní a technické podpory, který bude Poskytovatel Objednateli předkládat kvartálně za uplynulé období, bude obsahovat minimálně:

• Report ke službě Service Desk:

o Počet neposkytnutých služeb Dostupnost operátora Service Desku;

• Report ke službě Řízení a řešení Incidentů:

o Počet nevyřešených Incidentů v kategorii A v dané lhůtě Fix Time (Doba vyřešení Incidentu);

o Počet nevyřešených Incidentů v kategorii B v dané lhůtě Fix Time (Doba vyřešení Incidentu);

o Počet nevyřešených Incidentů v kategorii C v dané lhůtě Fix Time (Doba vyřešení Incidentu);

• Report ke službě Poskytování součinnosti při HW a SSW haváriích:

o Počet neposkytnutých součinností v kategorii A v dané lhůtě Fix Time (Doba vyřešení Požadavku);

o Počet neposkytnutých součinností v kategorii B v dané lhůtě Fix Time (Doba vyřešení Požadavku);

o Počet neposkytnutých součinností v kategorii C v dané lhůtě Fix Time (Doba vyřešení požadavku);

• Report ke službě Řízení a řešení Změnových požadavků:

o Disponibilní kapacita čerpaná v minulém kvartálu;

o Disponibilní kapacita vyčerpaná celkem;

o Disponibilní kapacita, kterou lze čerpat v nastávajícím kvartálu.

Uvedený report bude zpracován nejpozději do 10tého pracovního dne následujícího po ukončení reportovaného období.