Smlouva na upgrade systému SD a HD

Smlouva na upgrade systému SD a HD č. 2021/07998

Smlouva na upgrade systému SD a HD

Číslo 2021/07998

Česká pošta, s.p.
se sídlem:	Politických vězňů 909/4, 225 99 Praha 1
IČO:	47114983
DIČ:	CZ47114983
zastoupen:	Ing. Xxxxxxxxxx Xxxxxxxx, ředitelem úseku ICT a eGovernment
zapsán v obchodním rejstříku u:	Městského soudu v Praze, oddíl A, vložka 7565
bankovní spojení:	xxx č. ú.: xxx
dále jen „Objednatel“ nebo „ČP“

a

INTEDO s.r.o.
se sídlem:		Ruská 215, 251 69 Velké Popovice
IČO:		27384373
DIČ:		CZ27384373
zastoupen:		Ing. Xxxxx Xxxxxxxxxxxx, jednatelem
zapsán v obchodním rejstříku u:		Městského soudu v Praze, oddíl C, vložka 115454
bankovní spojení:		xxx č. ú.: xxx
dále jako „Dodavatel“

dále jednotlivě jako „Smluvní strana“, nebo společně jako „Smluvní strany“ uzavírají v souladu s ustanovením § 1746 odst. 2 zákona č. 89/2012 Sb., občanského zákoníku, ve znění pozdějších předpisů (dále jen „Občanský zákoník“), tuto Smlouvu na upgrade systému SD a HD (dále jen „Smlouva“).

Preambule

Objednatel provedl dle interních předpisů výběrového řízení k veřejné zakázce „Upgrade systému SD a HD“ (dále jen „Výběrové řízení“) na uzavření této Smlouvy. Tato Smlouva je uzavřena s Dodavatelem na základě výsledku Výběrového řízení. Objednatel tímto ve smyslu ust. § 1740 odst. 3 Občanského zákoníku předem vylučuje přijetí nabídky na uzavření této Xxxxxxx s dodatkem nebo odchylkou.

1. Definice pojmů

Níže uvedené výrazy mají v jednotném i množném čísle v této Smlouvě následující význam:

1. Akceptačním testem – se rozumí test ověřující funkcionalitu plnění v rámci Díla na základě předem odsouhlasených testovacích scénářů tak, aby Objednatel mohl provést test bez detailní znalosti systému. O průběhu Akceptačního testu se pořizuje zápis dle čl. 17 Smlouvy.

2. Akceptačním protokolem – se rozumí písemný dokument „Protokol o předání a převzetí Upgradu“, kterým Smluvní strany potvrzují předání a převzetí Upgradu nebo sjednaného dílčího plnění v rámci Upgradu a jehož vzor je uveden v Příloze č. 4 Smlouvy.

3. Smlouva - znamená tento dokument se všemi přílohami ve znění všech písemně uzavřených dodatků.

4. Výrobce software - znamená osobu, která vykonává svým jménem a na svůj účet majetková práva k Software, bez ohledu na to, zda se jedná o Dodavatele nebo třetí osobu.

5. MD - man-day (člověkoden), osm hodin práce jedné fyzické osoby;

6. Objednávka – objednávka dle odst. 2.4 Smlouvy.

7. Oponentní řízení – znamená proces, při kterém je odbornými oponenty Objednatele posuzován předložený projekt dle odst. 2.2.2 této Smlouvy. Cílem oponentury je odhalení nedostatků, duplicit, skrytých problémů a možných rizik, objektivní zajištění správnosti, optimalizace a odstranění subjektivních vlivů autorů projektu, které projekt ve své počáteční nebo i finální podobě může obsahovat.

8. Vývojářské a konzultační služby – znamená poskytování vývojářských a konzultačních prací k software, zejména o úpravy nebo customizaci SW z hlediska potřeb vzniklých v čase s ohledem na rozvoj a změny souvisejících systémů ve smyslu odst. 2.2.6 této Smlouvy.

9. Vadou – se rozumí rozpor mezi skutečnými vlastnostmi poskytnutého plnění a vlastnostmi specifikovanými v Provozní či Uživatelské dokumentaci nebo v této Smlouvě.

1. Předmět a účel Smlouvy

   1. Účelem této Smlouvy je procesní a technický upgrade – tedy funkční i technické zhodnocení již existujícího troubleticketového systému SD (HP Service manager). V systému jsou centrálně řízeny procesy sloužící pro správu a evidenci veškerých IT technologií, eskalaci IT incidentů a požadavků. V systému jsou evidovány rovněž evidenční a eskalační záležitosti, například správa majetku.

   2. Předmětem této Smlouvy je

      1. zhotovení úvodní projektové dokumentace s popisem průběhu realizace řešení, podrobným harmonogramem a návrhem technického řešení v grafické podobě (Archimate) včetně vytvoření inovované metodiky procesů, pracovních postupů a směrnic;

      2. provedení konfigurace a parametrizace SW SD a integrace a implementace inovovaných procesů SD (dále jen „Dílo“);

      3. představení celkového funkčního stavu, seznámení uživatele jak se základy, tak s pokročilými možnosti práce se SW, včetně uživatelských dovedností. Předání dovedností proběhne v prostředí Objednatele na technické infrastruktuře Objednatele a jako podkladový materiál bude sloužit uživatelská dokumentace vytvořená pro tento účel Dodavatelem, seznámení proběhne minimálně v rolích: administrátor, správce, operátor, řešitel a uživatel v minimálním rozsahu 54 hodin;

(plnění dle odst. 2.2.1 – 2.2.3 dále jako „Upgrade“);

4. poskytování maintenance a technické podpory 2. úrovně Dodavatelem k software po dobu 12 měsíců ode dne nabytí účinnosti této Smlouvy (dále jen „Podpora a údržba“). V rámci této Podpory a údržby má Objednatel možnost samostatně si stahovat opravné balíčky vydávané Dodavatelem, respektive Výrobcem software. Bližší specifikace plnění je uvedena v Příloze č. 1 této Smlouvy;

5. poskytnutí dalších vývojářských a konzultačních služeb na Objednávku, které nejsou zahrnuty činnostech, podle odstavců 2.2.1, 2.2.2, 2.2.3 a 2.2.4 této Smlouvy v maximálním množství 12 MD;

(plnění dle odst. 2.2.1 – 2.2.5 dále jako „Plnění").

3. Objednatel se tímto zavazuje za řádně poskytnuté Plnění zaplatit dohodnutou cenu způsobem ve Smlouvě definovaným.

4. Dodavatel se zavazuje poskytovat v souladu s ustanoveními Smlouvy Objednateli Plnění po dobu účinnosti Smlouvy v co nejlepším provedení a jakosti odpovídající aktuálnímu stavu technologického vývoje a poznání, jakož i požadavkům Objednatele vymezeným v Příloze č. 1 Smlouvy.

5. Po uzavření Smlouvy sdělí Objednatel Dodavateli číslo evidenční objednávky pro účely fakturace Plnění dle odst. 2.2.1 – 2.2.4 Xxxxxxx. Evidenční objednávka je vystavena Objednatelem pro interní evidenční účely a není návrhem na uzavření smlouvy ve smyslu § 1731 Občanského zákoníku. Dodavateli je sděleno pouze číslo evidenční objednávky za účelem jeho uvedení na daňovém dokladu. Evidenční objednávka nemá vliv na plnění Smlouvy a povinnost Dodavatele dodat předmět plnění řádně a včas.

6. Další vývojářské a konzultační služby dle odst. 2.2.5 Smlouvy (dále jen „Služby na objednávku“), bude Dodavatel poskytovat na základě objednávky doručené Objednatelem Dodavateli (dále jen „Objednávka“) a následně uzavřené dílčí smlouvy. Objednávka musí obsahovat minimálně tyto náležitosti:

1. identifikační údaje Dodavatele a Objednatele;

2. číslo a datum vystavení Objednávky;

3. číslo Smlouvy;

4. název Plnění, jeho rozsah a popis;

5. Cenu;

6. dobu a místo poskytnutí Plnění; a

7. podpis oprávněné osoby Objednatele.

1. Objednatel je oprávněn, avšak nikoli povinen, vystavovat dle svého uvážení Objednávky ode dne účinnosti této Smlouvy. Každá takto vystavená Objednávka se považuje za návrh na uzavření dílčí smlouvy o poskytování služeb za podmínek stanovených touto Smlouvou. Dodavatel je povinen písemně potvrdit Objednávku ve lhůtě jednoho (1) Pracovního dne od jejího doručení Objednatelem. Doručením potvrzení Objednávky Objednateli dojde k uzavření dílčí smlouvy o poskytování služeb (dále jen „Dílčí smlouva“), přičemž práva a povinnosti Smluvních stran dle Dílčí smlouvy odpovídají v celém rozsahu právům a povinnostem Objednatele a Dodavatele stanoveným touto Smlouvou.

2. Potvrzení Objednávky musí obsahovat minimálně tyto náležitosti:

1. identifikační údaje Objednatele a Dodavatele;

2. číslo Objednávky, která je potvrzována;

3. podpis oprávněné osoby Dodavatele.

1. V případě, že Objednávka nebude splňovat uvedené minimální náležitosti, má Dodavatel povinnost na tuto skutečnost neprodleně upozornit Objednatele. Objednatel je poté povinen vystavit novou Objednávku a Dodavatel je povinen ji ve lhůtě jednoho (1) Pracovního dne od jejího doručení písemně potvrdit. Dodací lhůta běží od okamžiku doručení této nové Objednávky.

2. Potvrzení Objednávky, které obsahuje dodatky, výhrady, omezení nebo jiné změny se považuje za odmítnutí Objednávky a tvoří nový návrh Dodavatele na uzavření Dílčí smlouvy, a to i v případě takového dodatku, výhrady, omezení nebo jiné změny, které podstatně nemění podmínky Objednávky. Dílčí smlouva je v takovém případě uzavřena pouze tehdy, pokud tento nový návrh Objednatel písemně potvrdí a doručí zpět Dodavateli.

3. Počet Objednávek vystavených Objednatelem není omezený. Současně platí, že Objednatel není povinen Objednávku vystavit.

4. Dodavatel se zavazuje poskytnout Služby na objednávku ve sjednaném rozsahu a sjednaným způsobem, prosté faktických a právních vad, dle časových požadavků Objednatele.

5. Objednatel se tímto zavazuje řádně poskytnuté Služby na objednávku převzít a zaplatit za něj dohodnutou cenu způsobem ve Smlouvě definovaným.

1. Cena

   1. Celková cena za poskytnutí Upgradu činí 1.287.100,-- Kč bez DPH (slovy: jedenmiliondvěstěosmdesátsedmtisícjednosto korun českých). Bližší cenová specifikace je uvedena v Příloze č. 3 Smlouvy.

   2. Roční cena za poskytování Podpory a údržby činí 3.512.160,-- Kč bez DPH (slovy: třimilionypětsettřicetsedmtisícšestset korun českých).

   3. Cena za 1 MD Služeb na objednávku činí 13.760,-- Kč bez DPH (slovy: třinácttisícsedmsetšedesát korun českých).

   4. Všechny ceny jsou uváděny v české měně (Kč) a bez DPH, která bude připočítána v souladu s příslušnými ustanoveními zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů (dále jen „zákon o DPH“).

   5. Uvedené ceny, včetně cen jednotkových, jsou konečné a nejvýše přípustné a jsou v nich zahrnuty veškeré náklady Dodavatele související s poskytováním všech plnění dle čl. 2 Smlouvy, zahrnují veškeré odměny za využití SW ve sjednaném rozsahu.

2. Platební a fakturační podmínky

   1. Cena za poskytnutí Upgradu včetně DPH bude uhrazena jednorázově po poskytnutí všech plnění dle odst. 2.2.1 – 2.2.3 Smlouvy na základě daňového dokladu (faktury) vystaveného Dodavatelem. Nedílnou součástí daňového dokladu je Objednatelem potvrzený Akceptační protokol dle odst. 5.6 této Smlouvy. Dodavatel je povinen vystavit daňový doklad nejpozději do sedmi (7) kalendářních dnů od data podpisu Akceptačního protokolu Objednatelem.

   2. Roční cena za poskytování Podpory a údržby včetně DPH bude Objednatelem hrazena ročně předem na základě daňového dokladu (faktury) vystaveného Dodavatelem. Dodavatel vystaví první daňový doklad ke dni zahájení poskytování tohoto plnění, tento den vystavení daňového dokladu bude zároveň dnem uskutečnění zdanitelného plnění. Přílohou daňového dokladu bude písemný zápis dle odst. 5.7 Smlouvy.

   3. Cena Služeb na objednávku řádně poskytnutých v příslušném kalendářním měsíci bude Objednatelem hrazena měsíčně na základě daňového dokladu (faktury) vystaveného Dodavatelem. Nedílnou součástí daňového dokladu je Objednatelem potvrzený Akceptační protokol stvrzující řádné poskytnutí Služby na objednávku. Dnem uskutečnění zdanitelného plnění je poslední den příslušného kalendářního měsíce.

   4. Dodavatel zašle daňový doklad / daňové doklady spolu s veškerými požadovanými dokumenty Objednateli:

1. doporučeným dopisem na adresu: Česká pošta, s.p., skenovací centrum, Poštovní 1368/20, 701 06 Ostrava 1; nebo

2. elektronicky, je-li elektronický způsob zasílání výslovně odsouhlasen Objednatelem na základě žádosti Dodavatele zaslané do technologické schránky xxxxxxxxxx.xx@xxxxx.xx; nebo

3. na výzvu Objednatele způsobem uvedeným v odst. 4.9 Xxxxxxx.

1. Daňový doklad musí obsahovat náležitosti řádného daňového dokladu podle příslušných právních předpisů, zejména pak zákona o DPH, a níže uvedené údaje:

   1. číslo Smlouvy;

   2. číslo evidenční objednávky dle odst. 2.5 Smlouvy nebo číslo Objednávky;

   3. platební podmínky v souladu se Smlouvou;

   4. místo a datum poskytnutí předmětu plnění;

   5. popis fakturovaného plnění, množství, jednotkovou cenu a celkovou cenu;

   6. přílohou daňového dokladu bude Akceptační protokol/písemný zápis o zahájení poskytování Podpory a údržby potvrzený Objednatelem.

2. Doba splatnosti daňového dokladu vystaveného na základě této Smlouvy je šedesát (60) kalendářních dnů ode dne jeho vystavení Dodavatelem.

3. Objednatel je oprávněn, před uplynutím doby splatnosti, bez uhrazení vrátit daňový doklad, pokud neobsahuje uvedené zákonné náležitosti nebo nebude vystaven v souladu s touto Smlouvou. Vrácením daňového dokladu s uvedením důvodu pro jeho neproplacení přestává běžet doba splatnosti. Opravený/nový daňový doklad bude opatřen novou dobou splatnosti v délce šedesát (60) kalendářních dnů ode dne vystavení opraveného/nového daňového dokladu.

4. Objednatel neposkytuje Dodavateli jakékoliv zálohy na cenu plnění.

5. Dodavatel se zavazuje, že na výzvu Objednatele bude akceptovat oboustranné elektronické zasílání dokladů spojených s realizací plnění dle Smlouvy (zejména Objednávek a jejich potvrzení, daňových dokladů) prostřednictvím portálu SAP Ariba Network. Dodavatel se zavazuje v takovém případě zaregistrovat na portále SAP Ariba Network. Objednatele iniciuje registraci Dodavatele k portálu SAP Ariba Network zasláním elektronické výzvy na kontaktní e-mail Dodavatele dle čl. 15 Smlouvy. Objednatel prohlašuje, že pro požadované aktivity Dodavatele v rámci plnění dle Smlouvy je postačující registrace Dodavatele se standardním účtem Ariba Network. Je-li Dodavatel již v SAP Ariba Network registrován, pak lze pro elektronickou komunikaci využít existující AN-ID.

6. Smluvní strany se dohodly, že pokud bude v okamžiku uskutečnění zdanitelného plnění správcem daně zveřejněna způsobem umožňujícím dálkový přístup skutečnost, že poskytovatel zdanitelného plnění (dále jen „Dodavatel“) je nespolehlivým plátcem ve smyslu § 106a zákona o DPH, nebo má-li být platba za zdanitelné plnění uskutečněné Dodavatelem v tuzemsku zcela nebo z části poukázána na bankovní účet vedený provozovatelem platebních služeb mimo tuzemsko, nebo nastane některá ze skutečností uvedených v § 109 odst. 1 písm. a), b), c), případně odst. 2 písm. a) zákona o DPH, je příjemce zdanitelného plnění (dále jen „Objednatel“) oprávněn část ceny odpovídající dani z přidané hodnoty zaplatit přímo na bankovní účet správce daně ve smyslu § 109a zákona o DPH. Na bankovní účet Dodavatele bude v tomto případě uhrazena část ceny odpovídající výši základu daně z přidané hodnoty. Úhrada ceny plnění (základu daně) provedená Objednatelem v souladu s ustanovením tohoto odstavce Smlouvy bude považována za řádnou úhradu ceny plnění poskytnutého dle této Smlouvy.

7. Bankovní účet uvedený na daňovém dokladu, na který bude ze strany Dodavatele požadována úhrada ceny za poskytnuté zdanitelné plnění, musí být Dodavatelem zveřejněn způsobem umožňujícím dálkový přístup ve smyslu § 96 zákona o DPH. Smluvní strany se výslovně dohodly, že pokud číslo bankovního účtu Dodavatele, na který bude ze strany Dodavatele požadována úhrada ceny za poskytnuté zdanitelné plnění dle příslušného daňového dokladu, nebude zveřejněno způsobem umožňujícím dálkový přístup ve smyslu § 96 zákona o DPH a cena za poskytnuté zdanitelné plnění dle příslušného daňového dokladu přesahuje limit uvedený v § 109 odst. 2 písm. c) zákona o DPH, je Objednatel oprávněn zaslat daňový doklad zpět Dodavateli k opravě. V takovém případě se doba splatnosti zastavuje a nová doba splatnosti počíná běžet dnem vystavení opraveného daňového dokladu s uvedením správného bankovního účtu Dodavatele, tj. bankovního účtu zveřejněného správcem daně.

1. Termín, místo a podmínky plnění

   1. Dodavatel je povinen poskytnout Upgrade do 31. 12. 2021 (v tomto termínu musí být všechna plnění dle odst. 2.2.1 – 2.2.3 akceptována Objednatelem). Nabude-li tato Smlouva účinnosti později, než 1. 12. 2021, posouvá se termín pro poskytnutí Upgradu tak, aby činil 30 kalendářních dnů od nabytí účinnosti Smlouvy.

   2. Místem plnění jsou:

• Olšanská 38/9 Praha 3;

• Sazečská 598/7 Praha 10 – Malešice;

• Heršpická 875/6a Brno 02;

• Bohumíra Četyny 1047/12 Ostrava - Xxxxxx les; a

• Opavská 130 Vítkov,

není-li Smluvními stranami sjednáno jinak.

3. Jednotlivá plnění Upgradu budou Objednateli poskytnuta následovně:

   1. Předmět plnění dle odst. 2.2.1 Smlouvy bude poskytnut Objednateli způsobem/ve formě dokumentu zaslaného elektronickou poštou a v českém jazyce. Spolu s předmětem plnění bude předána také veškerá dokumentace (např. produktová, uživatelská) vztahující se k předmětu plnění, bez níž by nemohlo ke vniku dokumentu dojít, v českém jazyce, která bude předána spolu s předmětem plnění v elektronické podobě.

   2. Předmět plnění dle odst. 2.2.2 a 2.2.3 Smlouvy bude poskytnut Objednateli způsobem formou služby. Spolu s předmětem plnění bude předána také veškerá dokumentace (např. produktová, uživatelská) vztahující se k předmětu plnění, bez níž by nemohlo ke vniku dokumentu dojít, v českém jazyce, která bude předána spolu s předmětem plnění v elektronické podobě.

4. Objednatel potvrdí svým podpisem převzetí předmětu plnění do písemného protokolu o předání a převzetí předmětu plnění (akceptační protokol). Objednatel je oprávněn odmítnout převzetí předmětu plnění, není-li dodán včas a řádně (bez vad). Neodmítnutí převzetí předmětu plnění však nezbavuje Objednatele jeho nároků z odpovědnosti Xxxxxxxxxx za vady.

5. Předmět plnění dle odst. 2.2.1 a 2.2.2 Smlouvy bude akceptován způsobem dle čl. 17 této Smlouvy. O každém poskytnutém plnění bude vyhotoven dílčí akceptační protokol.

6. Upgrade bude poskytnut na základě finálního akceptačního protokolu, který stvrdí poskytnutá jednotlivá plnění dle odst. 2.2.1 – 2.2.3 Xxxxxxx. O datu předání hotového Upgradu (včetně provedení seznámení dle odst. 2.2.3 Smlouvy) je Dodavatel povinen Objednatele informovat nejméně tři (3) pracovní dny předem e-mailem nebo telefonicky na spojení uvedené v odst. 15.2 Smlouvy (osoba odpovědná za technické náležitosti), nebude-li Smluvními stranami ujednáno jinak.

7. Poskytování Podpory a údržby je Dodavatel povinen zahájit ke dni nabytí účinnosti této Smlouvy. O zahájení poskytování Podpory a údržby bude Smluvními stranami podepsán písemný zápis.

1. Práva duševního vlastnictví

   1. Vznikne-li v souvislosti s poskytováním Plnění Dodavatelem Objednateli autorské dílo, zejména v rámci Plnění dle odst. 2.2.2 nebo 2.2.5 této Smlouvy, které podléhá ochraně podle zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, ve znění pozdějších předpisů (dále jen „Autorský zákon“), poskytuje Dodavatel Objednateli ke dni podpisu Akceptačního protokolu k takovému autorskému dílu výhradní, množstevně a územně neomezenou volně převoditelnou licenci na celou dobu trvání majetkových autorských práv k takovému dílu a ke všem způsobům a formám užití za jakýmkoli účelem, nebude-li v daném případě dohodnuto jinak (např. z důvodu dodání standardního software třetí strany, který neumožňuje udělení takovýchto licenčních práv). V případě předávání Plnění po částech pak vždy ke každé jednotlivé části okamžikem podpisu Akceptačního protokolu této části Plnění.

   2. Současně s licencí uděluje Dodavatel Objednateli souhlas k provádění jakýchkoliv modifikací, úprav, změn díla včetně práva do něj dle svého uvážení zasahovat, zapracovávat do dalších autorských děl a spojovat jej s jinými autorskými díly, případně zařazovat do databází, a to včetně oprávnění Objednatele takovými zásahy do díla pověřit třetí osoby. Objednatel je oprávněn provádět servis, údržbu či podporu díla sám nebo prostřednictvím třetích osob, k čemuž Dodavatel poskytuje výslovný souhlas.

   3. Objednatel je oprávněn poskytovat neomezený počet podlicencí ve stejném nebo omezeném rozsahu, ve kterém je dílo oprávněn užívat dle této Smlouvy. Objednatel je oprávněn převést, respektive postoupit právo užívat dílo na třetí osobu ve stejném nebo omezeném rozsahu, ve kterém je dílo oprávněn užívat dle této Smlouvy.

   4. Dodavatel prohlašuje, že Plnění ani jeho části, které jsou autorským dílem, nemá žádné právní vady, že není zatíženo právy třetích osob a že Dodavatel je zcela oprávněn vykonávat veškerá majetková autorská práva a poskytnout výše uvedená oprávnění a souhlasy Objednateli v celém rozsahu, s dílem disponovat a uzavřít s Objednatelem Smlouvu na celý rozsah předmětu plnění. V případě, že se uvedené prohlášení Dodavatele nezakládá na pravdě, Dodavatel odpovídá Objednateli za vyplývající důsledky v plném rozsahu včetně odpovědnosti za majetkovou i nemajetkovou újmu. Sankční ujednání dle této Smlouvy tímto nejsou dotčena. Uplatní-li třetí osoba své právo k dílu nebo jeho části, zavazuje se Dodavatel bez zbytečného odkladu a na vlastní náklady učinit potřebná opatření k ochraně výkonu práv Objednatele, pokud jej k tomu Objednatel zmocní, a nahradit veškerou majetkovou i nemajetkovou újmu vzniklou tím Objednateli.

   5. Veškeré odměny za poskytnutí či zajištění všech licencí dle tohoto článku Smlouvy jsou již zahrnuty v ceně Plnění. Objednatel není povinen žádnou z licencí nabytých na základě této Smlouvy využít.

   6. Vlastnictví k hmotnému nosiči dat, na němž je Plnění nebo jeho část zaznamenána, a k materiálům včetně veškeré dokumentace přechází na Objednatele okamžikem podpisu Akceptačního protokolu.

   7. Licence dle tohoto článku Xxxxxxx je udělena Dodavatelem Objednateli v souvislosti s realizací Plnění a Dodavatel není oprávněn tuto licenci vypovědět ani ukončit jiným způsobem, než jak předpokládá tato Smlouva. Smluvní strany výslovně uvádějí, že bez ohledu na důvod a způsob ukončení této Smlouvy nejsou dotčena ustanovení tohoto článku Smlouvy.

   8. V souvislosti s těmito ujednáními o licenční smlouvě ve smyslu tohoto článku Smlouvy Smluvní strany výslovně vylučují ustanovení občanského zákoníku § 2378, § 2379, § 2380, § 2381 a § 2382.

   9. V případě, že jsou součástí Plnění realizovaného Dodavatelem dle této Smlouvy databáze (ve smyslu ustanovení § 88 autorského zákona), jejichž pořizovatelem je Dodavatel, převádí tímto Dodavatel právo pořizovatele databáze ve smyslu § 90 autorského zákona na Objednatele. Objednatel je oprávněn databáze zužitkovat a vytěžovat libovolně dle svého uvážení, k čemuž Dodavatel poskytuje výslovný souhlas.

   10. Bude-li Dodavatel plnit předmět této Smlouvy s využitím dalších informačních systémů či jiných nástrojů a technických pomůcek, které nejsou autorským dílem, které mají sloužit ke zlepšení, urychlení či zkvalitnění Plnění dle této Smlouvy (dále jen „Pomocný nástroj“), nabývá Objednatel právo užívat Pomocný nástroj v rozsahu a za podmínek stanovených tímto článkem Smlouvy obdobně, jako je tomu pro autorská díla.

   11. Bude-li autorské dílo vytvořeno činností Dodavatele pro Objednatele dle této Smlouvy, Smluvní strany činí nesporným, že jakékoliv takovéto autorské dílo vzniklo z podnětu a pod vedením Objednatele.

2. Záruka

   1. Dodavatel poskytuje Objednateli záruku na Dílo po dobu dvanácti (12) měsíců ode dne podpisu Protokolu o předání a převzetí Díla.

   2. Vady Díla, které vzniknou nebo se projeví v záruční době, je Dodavatel povinen odstranit na své náklady (jsou zahrnuty v ceně Plnění).

   3. Na Vady Díla v záruční době se vztahuje obdobně kategorizace Vad dle odst. 17.5 Smlouvy. Zařazení do kategorie záručních Vad provádí Objednatel.

   4. Vady Díla vzniklé nebo odhalené v záruční době bude Dodavateli oznamovat Objednatel bez zbytečného odkladu jako servisní incident dle Přílohy č. 1 Smlouvy a budou jako servisní incident řešeny. Vada kategorie A představuje servisní incident kritičnosti 1, Vada kategorie B představuje servisní incident kritičnosti 2 a Vada kategorie C představuje servisní incident kritičnosti 3.

   5. Dodavatel garantuje nepřetržitou práci na odstranění Vady až do jejího úplného odstranění, pokud se Smluvní strany nedohodnou jinak. Dodavatel se zavazuje průběžně informovat Objednatele o stavu řešení Vad až do jejich odstranění.

   6. Záruka Dodavatele se nevztahuje na Vady té části Díla, která byla užívána v rozporu s jejím funkčním určením a písemnými doporučeními Dodavatele a/nebo způsobené neoprávněným nebo neodborným zásahem Objednatele nebo třetí osobou, která není ve smluvním vztahu k Dodavateli. Funkční určení je specifikováno v Dokumentaci, která bude předána v rámci předání a převzetí Díla.

   7. Termíny pro odstranění Vad se řídí odst. 17.8 Smlouvy obdobně. Pokud bude Vada kategorie A Objednatelem přeřazena do kategorie B nebo C, popřípadě Vada kategorie B přeřazena do kategorie C, mění se příslušná lhůta k odstranění Vady na tu, jež se vztahuje k nové kategorii Vady. To neplatí, byl-li Dodavatel v okamžiku převedení Vady do nižší kategorie již v prodlení s odstraňováním Vady.

   8. Zjistí-li Dodavatel v průběhu odstraňování Vady, že Xxxx je neodstranitelná, je povinen nepřetržitě pracovat na náhradním řešení problému a informovat o tomto stavu Objednatele. Výskyt neodstranitelné Vady, pokud je zapříčiněna Dodavatelem může být ze strany Objednatele považován za podstatné porušení této Smlouvy.

   9. Pokud považuje Dodavatel Vadu za odstraněnou, předá předmětnou část Díla Objednateli, který je oprávněn ověřovat všechny funkce Díla ve smyslu jeho specifikace. Odstranění Vady potvrdí Objednatel písemně.

   10. Vadami nejsou vady Software/hardware, které nejsou součástí dodávky v rámci plnění této Smlouvy. Dodavatel poskytne nezbytnou součinnost pro odstranění takovýchto vad Objednatelem nebo třetími stranami, které Objednatel k odstranění vady Díla povolá.

8. Nemožnost plnění

   1. Jestliže vznikne na straně Dodavatele nemožnost plnění ve smyslu § 2006 a § 2007 Občanského zákoníku, Dodavatel písemně uvědomí bez zbytečného odkladu, nejpozději však do pěti (5) kalendářních dnů od jejího vzniku, o této skutečnosti a její příčině Objednatele. Pokud není jinak stanoveno písemně Objednatelem, bude Dodavatel pokračovat v realizaci svých povinností vyplývajících ze smluvního vztahu v rozsahu svých nejlepších možností a schopností a bude hledat alternativní prostředky pro realizaci té části plnění, kde není možné plnit. Pokud by podmínky nemožnosti plnění trvaly déle než devadesát (90) kalendářních dní, je Objednatel oprávněn od Smlouvy odstoupit.

   2. Ustanovení tohoto článku Smlouvy nezbavuje žádnou ze Smluvních stran její povinnosti k úhradě plateb v té době již splatných.

9. Oddělitelnost

   1. Pokud jakákoliv ustanovení nebo jakékoliv části ustanovení Smlouvy budou považovány za neplatné nebo nevymahatelné, nebude mít taková neplatnost nebo nevymahatelnost za následek neplatnost nebo nevymahatelnost celé Smlouvy, ale celá Smlouva se bude vykládat tak, jako kdyby neobsahovala příslušná neplatná nebo nevymahatelná ustanovení nebo části ustanovení a práva a povinnosti Smluvních stran se budou vykládat přiměřeně. Smluvní strany se dále zavazují, že budou navzájem spolupracovat s cílem nahradit takové neplatné nebo nevymahatelné ustanovení platným a vymahatelným ustanovením, jímž bude dosaženo stejného ekonomického výsledku (v maximálním možném rozsahu v souladu s právními předpisy), jako bylo zamýšleno ustanovením, jež bylo shledáno neplatným či nevymahatelným.

10. Obchodní tajemství a důvěrné informace

    1. Veškeré konkurenčně významné, určitelné, ocenitelné a v příslušných obchodních kruzích běžně nedostupné skutečnosti související se Smluvními stranami, a se kterými se Smluvní strany seznámí při realizaci předmětu Smlouvy nebo v souvislosti s touto Smlouvou přijdou do styku, a jejichž vlastník zajišťuje ve svém zájmu odpovídajícím způsobem jejich utajení, jsou obchodním tajemstvím. Smluvní strany se zavazují zachovat mlčenlivost o obchodním tajemství druhé Smluvní strany, a dále o skutečnostech a informacích, které označí jako důvěrné dle § 1730 Občanského zákoníku. Povinnost mlčenlivosti trvá až do doby, kdy se informace této povahy stanou obecně známými za předpokladu, že se tak nestane porušením povinnosti mlčenlivosti. Na povinnost mlčenlivosti nemá vliv forma sdělení informací (písemně nebo ústně) a jejich podoba (materializované nebo dematerializované).

    2. Smluvní strany se zavazují, že důvěrné informace a obchodní tajemství druhé Smluvní strany jiným subjektům nesdělí, nezpřístupní, ani nevyužijí pro sebe nebo pro jinou osobu. Zavazují se zachovat je v přísné tajnosti a sdělit je výlučně těm svým zaměstnancům nebo subdodavatelům, kteří jsou pověřeni plněním Smlouvy a za tímto účelem jsou oprávněni se s těmito informacemi v nezbytném rozsahu seznámit. Smluvní strany se zavazují zabezpečit, aby i tyto osoby považovaly uvedené informace za důvěrné a zachovávaly o nich mlčenlivost.

    3. V případě porušení obchodního tajemství ve smyslu § 2985 Občanského zákoníku, použijí Smluvní strany prostředky právní ochrany proti nekalé soutěži.

    4. Poškozená Smluvní strana má právo na náhradu újmy, která jí takovýmto jednáním druhé Smluvní strany vznikne.

    5. Povinnost plnit ustanovení dle tohoto článku Smlouvy se nevztahuje na informace, které:

       1. mohou být zveřejněny bez porušení této Smlouvy;

       2. byly písemným souhlasem obou Smluvních stran zproštěny těchto omezení;

       3. jsou známé nebo byly zveřejněny jinak, než následkem zanedbání povinnosti jedné ze Smluvních stran;

       4. příjemce je zná dříve, než mu je sdělí Smluvní strana;

       5. jsou vyžádány soudem, státním zastupitelstvím nebo příslušným správním orgánem v souladu a na základě zákona;

       6. Smluvní strana je sdělí osobě vázané zákonnou povinností mlčenlivosti (např. advokátovi nebo daňovému poradci) za účelem uplatňování svých práv nebo při plnění povinností stanovených právními předpisy;

       7. jsou zveřejněny v souladu a na základě právního předpisu (např. o svobodném přístupu k informacím, o registru smluv);

       8. je Objednatel povinen sdělit svému zakladateli.

    6. Povinnost mlčenlivosti trvá bez ohledu na ukončení účinnosti této Smlouvy.

    7. Smluvní strany berou na vědomí, že tato Xxxxxxx bude uveřejněna v registru smluv dle zákona č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv, ve znění pozdějších předpisů (dále jen „zákon o registru smluv“). Dle dohody Smluvních stran zajistí odeslání této Smlouvy správci registru smluv Objednatel. Objednatel je oprávněn před odesláním Xxxxxxx správci registru smluv ve Xxxxxxx znečitelnit informace, na něž se nevztahuje uveřejňovací povinnost podle zákona o registru smluv.

11. Pravidla bezpečnosti ICT systémů Objednatele

    1. Dodavatel je povinen zúčastnit se bezpečnostního školení organizovaného Objednatelem a dodržovat při výkonu své činnosti všechny bezpečnostními požadavky stanovené v Bezpečnostní příručce uživatele ICT ČP, jejíž znění aktuální ke dni provedení školení mu bude v rámci školení Objednatelem předáno. Objednatel je oprávněn provádět v Bezpečnostní příručce uživatele ICT ČP změny. O změnách bude Dodavatel Objednatelem informován. Dodavatel je povinen řídit se novým obsahem Bezpečnostní příručky uživatele ICT ČP od data stanoveného Objednatelem, nejdříve však ode dne, kdy byl o změně informován.

    2. Objednatel je oprávněn kdykoli prověřovat dodržování bezpečnostních požadavků stanovených v Bezpečnostní příručce uživatele ICT ČP Dodavatelem.

    3. Dodavatel je povinen hlásit vzniklé bezpečnostní incidenty definované Bezpečnostní příručkou uživatele ICT ČP případně i podezření na ně Objednateli prostřednictvím ServiceDesk ČP.

12. Pravidla compliance

    1. Smluvní strany se zavazují dodržovat právní předpisy a chovat se tak, aby jejich jednání nemohlo vzbudit důvodné podezření ze spáchání nebo páchání trestného činu přičitatelného jedné nebo oběma Smluvním stranám podle zákona č. 418/2011 Sb., o trestní odpovědnosti právnických osob a řízení proti nim, ve znění pozdějších předpisů.

    2. Smluvní strany se zavazují, že učiní všechna opatření k tomu, aby se nedopustily ony a ani nikdo z jejich zaměstnanců či zástupců jakékoliv formy korupčního jednání, zejména jednání, které by mohlo být vnímáno jako přijetí úplatku, podplácení nebo nepřímé úplatkářství či jiný trestný čin spojený s korupcí dle zákona č. 40/2009 Sb., trestní zákoník, ve znění pozdějších předpisů.

    3. Smluvní strany se zavazují, že neposkytnou, nenabídnou ani neslíbí úplatek jinému nebo pro jiného v souvislosti s obstaráváním věcí obecného zájmu anebo v souvislosti s podnikáním svým nebo jiného. Smluvní strany se rovněž zavazují, že úplatek nepřijmou, ani si jej nedají slíbit, ať už pro sebe nebo pro jiného v souvislosti s obstaráním věcí obecného zájmu nebo v souvislosti s podnikáním svým nebo jiného. Úplatkem se přitom rozumí neoprávněná výhoda spočívající v přímém majetkovém obohacení nebo jiném zvýhodnění, které se dostává nebo má dostat uplácené osobě nebo s jejím souhlasem jiné osobě, a na kterou není nárok.

    4. Smluvní strany nebudou ani u svých obchodních partnerů xxxxxxxxx jakoukoliv formu korupce či uplácení.

    5. V případě, že je zahájeno trestní stíhání Dodavatele, zavazuje se Dodavatel o tomto bez zbytečného odkladu Objednatele písemně informovat.

    6. Objednatel očekává, že se Dodavatel seznámí s „Kodexem dodavatele České pošty“, ve znění k datu účinnosti této Smlouvy, který je dostupný na webu Objednatele na adrese xxxxx://xxx.xxxxxxxxxx.xx/x-xxxxx-xxxxx/xxxxxx/xxxxxxxxxx-x-xx, a bude jej dodržovat.

13. Zpracování osobních údajů

    1. Předmětem této části Smlouvy je úprava vzájemných práv a povinností při zpracování osobních údajů ve smyslu nařízení Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů; dále jen „GDPR“) a zákona č. 110/2019 Sb., o zpracování osobních údajů, ve znění pozdějších předpisů (dále jen „ZZOÚ“). Osobní údaje jsou důvěrnými informacemi ve smyslu čl. 10 Smlouvy.

    2. Dodavatel bude za účelem poskytování Plnění zpracovávat osobní údaje zaměstnanců Objednatele (dále též jen „Subjekt údajů“ nebo „Subjekty údajů“), a to zejména v rozsahu: jméno, příjmení, zaměstnanecké číslo, telefonní číslo, e-mailová adresa.

    3. Dodavatel bude osobní údaje zpracovávat zejména nahlížením.

    4. Informační povinnost dle GDPR bude ve vztahu k Subjektům údajů plněna Objednatelem.

    5. Dodavatel zpracovává osobní údaje pouze na základě písemných pokynů Objednatele, včetně případného předání osobních údajů třetím subjektům, pokud mu toto zpracování již neukládají právní předpisy, které se na Dodavatele vztahují; v takovém případě Dodavatel Objednatele o takovém právním požadavku informuje ještě před samotným zpracováním, ledaže by právní předpisy toto informování zakazovaly z důležitých důvodů veřejného zájmu. Dodavatel zohledňuje povahu zpracování osobních údajů.

    6. Jakákoliv třetí osoba (vyjma zaměstnanců Xxxxxxxxxx), která jedná z pověření Dodavatele a má přístup k osobním údajům, může tyto osobní údaje zpracovávat pouze na základě pokynu Objednatele, ledaže jí zpracování osobních údajů ukládají právní předpisy. Dodavatel přijme opatření pro zajištění tohoto požadavku a zajistí, aby se osoby oprávněné zpracovávat osobní údaje zavázaly k mlčenlivosti, nevztahuje-li se na ně zákonná povinnost mlčenlivosti.

    7. Dodavatel odpovídá za to, že jeho zaměstnanci, kteří v rámci plnění stanovených oprávnění a povinností přicházejí do styku s osobními údaji, budou povinni zachovávat mlčenlivost o osobních údajích a o bezpečnostních opatřeních, jejichž zveřejnění by ohrozilo zabezpečení osobních údajů. Povinnost mlčenlivosti trvá i po skončení zaměstnání nebo příslušných prací. Dodavatel je povinen dohlížet na plnění uvedených povinností ze strany svých zaměstnanců.

    8. Pokud to dovolují obecně závazné právní předpisy, je Xxxxxxxxx oprávněn pověřit zpracováním dalšího zpracovatele, pouze však jen s předchozím písemným souhlasem Objednatele. Pokud Dodavatel zapojí dalšího zpracovatele, aby jménem Objednatele provedl určité činnosti zpracování osobních údajů, musí být tomuto dalšímu zpracovateli uloženy na základě smlouvy nebo jiného právního aktu minimálně stejné povinnosti na ochranu osobních údajů, jaké jsou dohodnuty mezi Objednatelem a Dodavatelem; jedná se zejména o poskytnutí dostatečných záruk, pokud jde o zavedení vhodných technických a organizačních opatření tak, aby zpracování osobních údajů splňovalo požadavky právních předpisů a pravidla a podmínky nakládání s osobními údaji, které se Smluvní strany zavázaly dodržovat. Splnění povinností stanovených v tomto odstavci je Xxxxxxxxx povinen Objednateli na jeho výzvu kdykoliv prokázat.

    9. S přihlédnutím ke stavu techniky, nákladům na provedení, povaze, rozsahu, kontextu a účelům zpracování osobních údajů i k různě pravděpodobným a různě závažným rizikům pro práva a svobody fyzických osob, zavede Dodavatel vhodná technická a organizační opatření, aby zajistil úroveň zabezpečení odpovídající danému riziku, zejména přijme veškerá opatření, aby nemohlo dojít k neoprávněnému nebo nahodilému přístupu k osobním údajům, jejich změně, zničení či ztrátě, jinému neoprávněnému zpracování, jakož i jejich jinému zneužití. Dodavatel zavede alespoň následující bezpečnostní opatření:

       1. zpracované postupy sloužící k ochraně osobních údajů;

       2. zpracované postupy sloužící ke zjištění, zda nedošlo k porušení ochrany osobních údajů (například ke ztrátě nebo modifikaci dat);

       3. zajištěna integrita a dostupnost informací;

       4. uzavírání smluv o zpracování osobních údajů s externími subjekty/dalšími zpracovateli vč. prověření každého takového externího subjektu/dalšího zpracovatele, zda poskytuje dostatečné záruky zavedení vhodných technických a organizačních opatření tak, aby jím prováděné zpracování splňovalo požadavky GDPR, ZZOÚ a aby byla zajištěna ochrana práv Subjektů údajů;

       5. monitoring a kontrola procesů zpracování osobních údajů;

       6. pravidelné školení zaměstnanců v metodách a postupech týkajících se bezpečnosti a ochrany osobních údajů;

       7. systém hlášení, upozorňování a vyšetřování mimořádných událostí a případů prolomení bezpečnosti.

    10. Ve vztahu k ICT systémům, které Dodavatel využívá pro účely poskytování Plnění, má Objednatel z hlediska jejich zabezpečení zejména následující minimální požadavky:

        1. zajištění pseudonymizace a šifrování osobních údajů při užívání systému uživateli, kteří nejsou oprávněni k jejich zpracování;

        2. zajištění automatizované anonymizace či výmazu osobních údajů po uplynutí nastavené doby zpracování pro nastavené účely zpracování;

        3. schopnost zajistit neustálou důvěrnost, integritu, dostupnost a odolnost systémů a služeb pro zpracování osobních údajů;

        4. schopnost obnovit dostupnost osobních údajů a přístup k nim v případě fyzických či technických incidentů;

        5. zajištění procesu pravidelného testování, posuzování a hodnocení účinnosti zavedených technických a organizačních opatření pro zajištění bezpečnosti zpracovávaných osobních údajů;

        6. zajištění, aby systémy pro zpracování osobních údajů používaly pouze oprávněné osoby;

        7. zajištění, aby fyzické osoby oprávněné k používání systémů pro zpracování osobních údajů měly přístup pouze k osobním údajům odpovídajícím oprávnění těchto osob, a to na základě zvláštních uživatelských oprávnění zřízených výlučně pro tyto osoby;

        8. pořizování elektronických záznamů, které umožní určit a ověřit kdy, kým a z jakého důvodu byly osobní údaje zaznamenány nebo jinak zpracovány;

        9. přijetí opatření k zajištění ochrany před škodlivým programovým vybavením; a

        10. zajištění zákazu ukládat osobní údaje na veřejná úložiště.

    11. Smluvní strany se zavazují vzájemně si neprodleně ohlašovat všechny jim známé skutečnosti, které by mohly nepříznivě ovlivnit řádné a včasné plnění závazků vyplývajících z tohoto článku Smlouvy a poskytovat si součinnost nezbytnou pro plnění tohoto článku Smlouvy a pro legitimní a legální zpracování osobních údajů.

    12. Dojde-li z jakéhokoli důvodu (např. z důvodu legislativních změn, rozhodnutí státního orgánu atp.) k nutnosti změny dohodnutých pravidel při plnění tohoto článku Smlouvy, zavazují se Smluvní strany neprodleně se o této skutečnosti informovat. Smluvní strany jsou povinny v takovém případě zahájit jednání o změně této Smlouvy.

    13. Dodavatel se zavazuje Objednateli poskytnout součinnost při zajišťování souladu s povinnostmi k zabezpečení osobních údajů, ohlašování případů porušení zabezpečení, zpracování posouzení vlivu na ochranu osobních údajů, plnění informační povinnosti a případně též konzultacím s dozorovým úřadem, a to vše při zohlednění povahy zpracování a informací, jež má Dodavatel k dispozici.

    14. Dodavatel se zavazuje Objednatele informovat o jakémkoli incidentu, a to nejpozději do dvaceti čtyř (24) hodin od okamžiku, kdy se dozvěděl o takovém incidentu, který vedl nebo by mohl vést k narušení integrity nebo zabezpečení zpracovávaných osobních údajů. Dodavatel je povinen stejným způsobem hlásit také podezření na incident, a to bez ohledu na to, kde a kdy k takovému incidentu může nebo mohlo dojít. V oznámení o incidentu Dodavatel zejména uvede:

        1. popis povahy daného incidentu včetně, pokud je to možné, kategorií a přibližného počtu dotčených Subjektů údajů a kategorií a přibližného počtu dotčených záznamů osobních údajů;

        2. popis pravděpodobných důsledků incidentu; a

        3. popis opatření, která Dodavatel přijal nebo navrhuje přijmout s cílem vyřešit daný incident, včetně případných opatření ke zmírnění možných nepříznivých dopadů.

Není-li možné poskytnout informace podle písm. a) – c) současně, mohou být poskytnuty Dodavatelem postupně bez dalšího zbytečného odkladu. Veškeré informace dle tohoto odstavce bude Dodavatel Objednateli sdělovat e-mailem na adresu xxx.

15. Dodavatel se zavazuje bez zbytečného odkladu informovat Objednatele o tom, že ve vztahu k němu bylo ze strany dozorového úřadu zahájeno šetření či řízení související se zpracováním osobních údajů dle této Smlouvy, o průběhu takového šetření či řízení a o výsledku takového šetření či řízení. Dodavatel na výzvu Objednatele též Objednateli zpřístupní veškeré dokumenty, které budou součástí spisu vedeného k předmětnému šetření či řízení.

16. Dodavatel poskytne Objednateli veškeré informace potřebné k doložení toho, že byly splněny jeho povinnosti dle této Smlouvy a předpisů na ochranu osobních údajů (zejména GDPR a ZZOÚ) a umožní audity včetně inspekcí, prováděné Objednatelem nebo jiným auditorem, kterého Objednatel pověřil, a k těmto auditům, je-li to nezbytné pro řádný výkon auditu, přispěje. Audity je Objednatel oprávněn provádět u Dodavatele (v jeho sídle, provozovně atd.), resp. na jakémkoli jiném místě, kde dochází ke zpracování osobních údajů. Audit je Objednatel povinen oznámit Dodavateli minimálně s předstihem pěti (5) pracovních dnů. V průběhu auditu má Objednatel přístup k interním předpisům a systémům vztahujícím se ke zpracování osobních údajů podle této Smlouvy. Objednatel se zavazuje, že ve vztahu k informacím, se kterými se v průběhu auditu či inspekce seznámí, zachová mlčenlivost.

17. Dodavatel bude osobní údaje zpracovávat po dobu plnění Smlouvy. Nejpozději do patnácti (15) kalendářních dní ode dne skončení účinnosti této Smlouvy je Xxxxxxxxx povinen ukončit zpracovávání osobních údajů. Dodavatel v souladu s rozhodnutím Objednatele všechny osobní údaje buď vymaže či jinak technicky odstraní, nebo je vrátí Objednateli a vymaže existující kopie, pokud právní předpisy nepožadují uložení (archivaci) daných osobních údajů nebo jejich uložení není nezbytné k ochraně práv a oprávněných zájmů Dodavatele; o tomto vyhotoví Dodavatel písemný protokol, který předá Objednateli. Dodavatel se dále zavazuje, že na žádost Objednatele nebo dozorového úřadu zpřístupní svá zařízení na zpracování osobních údajů za účelem přezkoumání opatření uvedených v tomto odstavci.

18. Dodavatel prohlašuje, že nebude využívat osobní údaje k jiným účelům než k účelům stanoveným touto Smlouvou.

19. Dodavatel nesmí sdružovat osobní údaje zpracovávané na základě této Smlouvy s jakýmikoli dalšími osobními údaji, získanými nebo zpracovávanými pro jiný účel.

20. V případě, že v důsledku porušení některé povinnosti Dodavatele dle tohoto článku Smlouvy či v důsledku jednání dalšího zpracovatele vznikne Objednateli povinnost na základě rozhodnutí či výzvy orgánu veřejné moci zaplatit peněžitou částku jako pokutu, sankci, penále, náhradu či jinou platbu obdobného charakteru (dále jen „Sankce“), zavazuje se Dodavatel uhradit Sankci namísto Objednatele, a to nejpozději do pěti (5) pracovních dní od doručení výzvy k zaplacení. Pokud Objednatel Sankci uhradí sám, zavazuje se Dodavatel uhradit Sankci Objednateli do pěti (5) pracovních dnů od doručení výzvy k zaplacení.

21. Obě Smluvní strany jako správci zpracovávají osobní údaje kontaktních zástupců Smluvních stran a dalších osob podílejících se na plnění této Smlouvy, a to výhradně pro účely související s plněním této Smlouvy, v nezbytně nutném rozsahu a po dobu trvání Smlouvy; případně po dobu delší, je-li to důvodné dle příslušných právních předpisů. Informační povinnost ve vztahu k těmto osobám plní každá ze Smluvních stran samostatně.

1. Další práva a povinnosti Smluvních stran

   1. Plnění musí být poskytnuto bez jakýchkoli vad, ať již faktických či právních, v souladu s veškerými právními předpisy, technickými požadavky a technickými a bezpečnostními normami, které se na Plnění vztahují, a to jak normami závaznými, tak doporučujícími.

   2. V rámci realizace předmětu Smlouvy má každá Smluvní strana zejména následující povinnosti:

      1. vzájemně spolupracovat a poskytovat druhé Smluvní straně veškeré informace potřebné pro řádné plnění svých povinností vyplývajících ze Smlouvy;

      2. poskytovat druhé Smluvní straně úplné, pravdivé a včasné informace o veškerých skutečnostech, které jsou nebo mohou být důležité pro řádné plnění dle Smlouvy;

      3. plnit své povinnosti vyplývající ze Smlouvy tak, aby nedocházelo k prodlení s plněním povinností vázaných k jednotlivým termínům a úhradě splatných jednotlivých peněžních dluhů.

   3. Objednatel se zavazuje v termínech stanovených touto Smlouvou, jinak v termínech odpovídajících postupu realizace Plnění, poskytnout Dodavateli potřebnou součinnost v následujícím rozsahu:

      1. poskytovat Xxxxxxxxxx potřebné dokumenty a informace, je-li povinnost k jejich poskytnutí uvedena ve Smlouvě (včetně příloh) nebo bylo-li tak dohodnuto v rámci jednání Smluvních stran;

      2. umožnit pracovníkům Dodavatele uvedeným v písemném seznamu předloženém Dodavatelem v předem dohodnutém termínu přístup na pracoviště Objednatele, je-li to nezbytné pro realizaci předmětu Smlouvy, a umožnit Dodavateli vzdálený přístup do informačních systémů Objednatele, je-li to pro realizaci předmětu Smlouvy nezbytné;

      3. seznámit Xxxxxxxxxx s interními pravidly a předpisy Objednatele v oblasti bezpečnosti ICT systémů a BOZP, které bude Dodavatel povinen dodržovat, podrobné podmínky bezpečnosti ICT systémů jsou uvedeny v Příloze č. 1 Smlouvy;

      4. dle potřeby a řešeného tématu zajistit účast a součinnost odpovědných pracovníků Objednatele při schvalování, analýzách, testování, akceptaci, seminářích, školeních apod.;

      5. poskytovat informace o ostatních projektech v daném prostředí, pokud budou mít jakýkoli vliv na plnění povinností Dodavatele z této Smlouvy;

      6. zajistit součinnost třetích stran, které nejsou v přímém smluvním vztahu s Dodavatelem, avšak jejichž činnost se přímo i nepřímo může dotýkat plnění dle této Smlouvy, pokud bude tato součinnost nezbytná pro plnění povinností Dodavatele;

      7. zajistit datovou a internetovou konektivitu, tj. komunikační kanál poskytující připojení k dílčím systémům Objednatele.

   4. Dodavatel se v souvislosti s realizací předmětu této Smlouvy zavazuje zejména:

      1. poskytovat Plnění v souladu se Smlouvou, řádně a včas, s řádnou a odbornou péčí a potřebnými odbornými schopnostmi pro poskytování plnění, které je předmětem této Smlouvy tak, aby bylo dosaženo účelu Smlouvy;

      2. poskytovat Plnění v souladu s obecně závaznými právními předpisy a pokyny Objednatele, pokud tyto nejsou v rozporu s těmito normami nebo zájmy Objednatele. Dodavatel je povinen při výkonu své činnosti včas písemně upozornit Objednatele na zřejmou nevhodnost jeho pokynů, jejichž následkem může vzniknout újma nebo nesoulad s obecně závaznými právními předpisy. Pokud Objednatel navzdory tomuto upozornění trvá na svých pokynech, Dodavatel neodpovídá za jakoukoli újmu vzniklou v této příčinné souvislosti;

      3. při poskytování Plnění brát na zřetel provozní potřeby Objednatele, postupovat podle pravidel obvyklých pro zpracování dat a v úzké součinnosti s Objednatelem provádět jednotlivá plnění této Smlouvy;

      4. pokud v průběhu plnění povinností vznikne na straně Dodavatele potřeba využít služeb třetí strany – poddodavatele, je oprávněn tak učinit jen po předchozím souhlasu Objednatele a jen tehdy, pokud bude nový poddodavatel splňovat potřebnou kvalifikaci. V případě, že Objednatel souhlas k využití poddodavatele neudělí, není Dodavatel oprávněn takovou poddodávku udělit. V případě souhlasu Objednatele a následného využití služeb třetí strany bude Xxxxxxxxx odpovídat za třetí stranu, jako by plnil sám, včetně odpovědnosti za způsobenou újmu. Dodavatel je povinen zajistit, aby jeho poddodavatel poskytoval Plnění v souladu s touto Smlouvou a dodržoval veškerá ujednání mezi Smluvními stranami;

      5. informovat bezodkladně Objednatele o jakýchkoliv zjištěných překážkách Plnění, byť by za ně Dodavatel neodpovídal a o uplatněných nárocích třetích osob, které by mohly plnění této Smlouvy ovlivnit;

      6. dbát, aby nebyla poškozena dobrá obchodní pověst a dobré jméno Objednatele. Při poskytování Plnění musí Dodavatel vždy sledovat zájmy Objednatele;

      7. činit všechna potřebná opatření k tomu, aby jeho činností nedošlo ke škodám na majetku Objednatele, jeho zaměstnanců nebo třetích stran, anebo k poškození zdraví zaměstnanců Objednatele nebo třetích osob, jimž by Objednatel za takto způsobenou újmu odpovídal;

      8. odčinit majetkovou i nemajetkovou újmu vzniklou Objednateli činností, nečinností nebo opomenutím Dodavatele;

      9. pro poskytování Plnění neužívat zaměstnance Objednatele, ani s nimi v této souvislosti neuzavírat jakýkoliv právní vztah s výjimkou potřebné a přiměřené součinnosti, není-li v této Smlouvě stanoveno jinak;

      10. na vyžádání Objednatele se zúčastnit osobní schůzky (mimo jednání realizačního týmu), pokud Objednatel požádá o schůzku nejpozději dva (2) pracovní dny předem. V mimořádně naléhavých případech je možno tento termín po dohodě obou Smluvních stran zkrátit;

      11. dodržovat veškerá interní pravidla a předpisy Objednatele týkající se bezpečnosti ICT systémů, BOZP a požární ochrany, byl-li s nimi Objednatelem seznámen, a účastnit se na výzvu Objednatele školení v oblasti bezpečnosti ICT systémů, pravidel BOZP a požární ochrany Objednatele;

      12. poskytovat součinnost při provozních úpravách Služeb s tím, že součinnost poskytovaná nad rámec požadavků Objednatele na poskytování Služeb dle Přílohy č. 1 Smlouvy bude poskytována jako Služba na objednávku;

      13. plnit v kvalitě potřebné pro dosažení parametrů stanovených v Příloze č. 1 Smlouvy a odpovídat za to, že případné vady Plnění poskytnutého dle Smlouvy řádně odstraní, případně nahradí plněním bezvadným, v souladu se Smlouvou;

      14. umožnit Objednateli kontrolovat, zda Dodavatel poskytuje Plnění řádně;

      15. mít po celou dobu trvání Smlouvy sjednáno pojištění odpovědnosti za majetkové i nemajetkové újmy způsobené v souvislosti s plněním Smlouvy Dodavatelem nebo osobou, za niž odpovídá, s pojistnou částkou nejméně 25 000 000,- Kč. Při vzniku pojistné události zabezpečuje ihned po jejím vzniku veškeré úkony vůči pojistiteli Dodavatel. Objednatel je povinen poskytnout v souvislosti s pojistnou událostí Dodavatele veškerou součinnost, která je v jeho možnostech.

      16. Systém musí představovat řešení, které je navrženo jako robustní a spolehlivé, bez „Single point of failure“, tedy tak, aby výpadek jediné komponenty nezpůsobil výpadek celého systému. Při návrhu architektury řešení budou využity postupy a technologie umožňující budoucí škálovatelnost aplikace. Systém musí být připravený na dodatečná rozšíření a úpravy funkcionality, datových struktur a dalších prvků dle požadavků Objednatele. Systém bude co nejvíce využívat ověřené technologie a otevřené standardy. Dodavatel odpovídá za to, že Systém bude splňovat požadavky uvedené v tomto odstavci.

   5. Objednatel je oprávněn započíst jakoukoliv svoji pohledávku, byť i nesplatnou, vůči Dodavateli proti jakékoliv pohledávce, byť i nesplatné, kterou má Dodavatel vůči Objednateli. Dodavatel je oprávněn jednostranně započíst své splatné či nesplatné pohledávky vůči Objednateli pouze s předchozím písemným souhlasem Objednatele.

2. Odpovědné osoby

   1. Odpovědnými osobami Dodavatele a Objednatele ve věcech obchodních pro účely této Smlouvy jsou:

      1. Za Objednatele:

xxx

Tel.: xxx

e-mail: xxx

2. Za Dodavatele:

xxx

Mob.: xxx

emailxxx

2. Odpovědnými osobami Dodavatele a Objednatele ve věcech technických pro účely této Smlouvy jsou:

   1. Za Objednatele:

xxx

Tel.: xxx

emailxxx

2. Za Dodavatele:

xxx

Mob.: xxx

emailxxx

16. Realizační tým

    1. Dodavatel je povinen za účelem poskytování Plnění zajistit dostatečnou kapacitu svých pracovníků s odpovídající kvalifikací a zkušenostmi.

    2. Dodavatel je povinen za účelem poskytování plnění dle této Smlouvy ustavit členy realizačního týmu pro realizaci této Smlouvy a určit jejich pravomoci (dále jen „Realizační tým“). Seznam členů Realizačního týmu je uveden v Příloze č. 3 Smlouvy. Dodavatel zajistí kontinuitu členů Realizačního týmu v průběhu trvání Smlouvy. Bude-li ze závažných důvodů vzniklých na straně Dodavatele nutné nahradit kteréhokoliv člena Realizačního týmu či rozšířit Realizační tým, bude po předchozím projednání s Objednatelem nahrazen/doplněn novým členem týmu s odpovídající nebo vyšší kvalifikací, a to do pěti (5) Pracovních dní od oznámení důvodů pro nahrazení Objednateli. Změny Realizačního týmu nevyžadují vyhotovení dodatku ke Smlouvě. O změně člena Realizačního týmu bude proveden zápis odsouhlasený oběma Smluvními stranami. Členové Realizačního týmu musí být schopni komunikovat v českém nebo slovenském jazyce, a to buď sami nebo prostřednictvím překladatele/tlumočníka; náklady na případné využití překladatele/tlumočníka nese Dodavatel.

    3. Jednotlivé činnosti prováděné v rámci Plnění nespadající do činností členů Realizačního týmu uvedeného v Příloze č. 3 Smlouvy, mohou být prováděny i jinými osobami, než členy Realizačního týmu. Tím však není dotčena odpovědnost členů Realizačního týmu dle jejich pozic i za takto provedené činnosti.

    4. Dodavatel je povinen předložit Objednateli před zahájením Služeb seznam pracovníků, pro které bude požadovat přístup na pracoviště Objednatele a vzdálený přístup do informačního systému Objednatele, je-li to pro plnění Smlouvy nezbytné.

    5. Dodavatelův Realizační tým se zúčastní realizační schůzky, která bude svolána nejpozději do deseti (10) dnů od podpisu smlouvy, a to v místě Plnění. Na této schůzi naplánují realizační týmy jednotlivé kroky realizace (návrh řešení, realizaci řešení a implementaci řešení – s názvem „projekt realizace díla“), které zanesou do zápisu a budou podkladem pro akceptační protokol.

17. Kontrola a akceptace Plnění

    1. Kontrola Plnění probíhá podle parametrů uvedených ve Smlouvě.

    2. Akceptace Plnění dle odst. 2.2.1 Smlouvy probíhá následujícím způsobem:

       1. Dodavatel představí dokument Objednateli v Oponentním řízení. Dokument bude obsahovat návrh na konfiguraci a parametrizaci SW SD a návrh inovované metodiky procesů, pracovních postupů a směrnic, včetně návrhu na jejich integraci a implementaci.

       2. Dodavatel zpracuje dílčí návrh akceptačního protokolu a předkládá jej Objednateli.

       3. Objednatel podrobí dokument posouzení, zda uvedené řešení vyhovuje požadavkům Objednatele uvedených ve Smlouvě.

       4. V případě, že má Objednatel k uvedenému řešení výhrady, předá je maximálně do pěti (5) pracovních dnů Dodavateli a ten jej ve lhůtě maximálně pěti (5) pracovních dnů zapracuje a znovu předloží k Oponentnímu posouzení Objednatelem.

    3. Akceptace Plnění dle odst. 2.2.2 Smlouvy probíhá následujícím způsobem:

       1. Dodavatel zpracuje dílčí návrh akceptačního protokolu a předkládá jej Objednateli.

       2. Dílo bude poskytnuto k provedení Akceptačních testů Objednateli takovým způsobem, aby bylo zajištěno splnění časových termínů dle harmonogramu uvedeného v úvodní projektové dokumentaci dle odst. 2.2.1 Xxxxxxx. Obsah a průběh Akceptačních testů určují testovací scénáře schválené Smluvními stranami. Testovací scénáře připraví Dodavatel za součinnosti Objednatele. V případě sporu Smluvních stran o obsah testovacích scénářů je rozhodující stanovisko Objednatele. Objednatel je povinen bez zbytečného odkladu zahájit Akceptační testy, a v případě, že tyto ukončí s výsledkem „Dílo vyhovuje“, je povinen Dílo převzít. Dílo se však považuje za dokončené až poté, co budou Dodavatelem odstraněny všechny vady zjištěné při Akceptačních testech uvedené v zápise o průběhu Akceptačních testů nebo v Akceptačním protokolu, odstraněny všechny Vady zjištěné, a úspěšně dokončeny všechny fáze realizace dle harmonogramu včetně úspěšného nasazení Díla do rutinního (produkčního) provozu. Ustanovení § 2605 Občanského zákoníku se ve smluvním vztahu založeném touto Smlouvou nepoužije. Tímto ujednáním není dotčena odpovědnost Dodavatele za později zjištěné Vady ani poskytnutá záruka za jakost. K převzetí Díla dojde podpisem Akceptačního protokolu odpovědnými pracovníky (nebo jejich zástupci) obou Smluvních stran. Dodavatel je povinen Dílo předat Objednateli plně v souladu s výše uvedeným harmonogramem, ust. § 2590 odst. 2 Občanského zákoníku se neužije.

       3. Pokud Akceptační testy Díla neukončí Objednatel ve sjednaném termínu s výsledkem „Dílo vyhovuje“, ocitá se Dodavatel v prodlení s plněním Díla, stejně tak, pokud Dodavatel neodstraní Vady zjištěné při Akceptačních testech ve sjednané lhůtě.

       4. Dodavatel je povinen Dílo poskytnout Objednateli k Akceptačním testům protokolárně nejpozději v termínech stanovených touto Smlouvou, přičemž součástí předávaného Plnění budou:

       5. Kompletní aktuální dokumentace Díla v českém jazyce v elektronické podobě zahrnující:

1. Provozní dokumentaci s popisem veškeré funkčnosti;

2. Technickou dokumentaci, kterou se rozumí:

• detailní návrh architektury – hardware (dále jen „HW“), datové toky, síťová propojení, popis procesu, vztahy s ostatními systémy a aplikacemi, návrh architektury bude v UML diagramech s jasným textovým popisem s vysvětlením

• technicko - realizační dokumentace (musí obsahovat popis instalace, příslušné instalační skripty s popisem, podmínky spouštění, informaci o nutných právech a účtech, které jsou potřeba pro instalaci a informace o nutných propojeních s ostatními systémy nebo dalších předpokladů pro správnou instalaci)

• požadavky na HW (procesory, paměť, diskový prostor, síťové prvky, periférie, operační systém včetně nutných updatů, další Software třetích stran, databáze apod.)

• dokumentace skutečného provedení

1. Uživatelskou a školící dokumentaci, jejíž součástí ve vztahu k softwarové části Díla určené pro práci uživatelů bude:

• popis SW (aplikace) z pohledu koncového uživatele

• referenční popis uživatelského rozhraní, včetně všech základních objektů a ovládacích prvků, jejich významu a způsobu použití

• popis uživatelských postupů, jenž provede uživatele (dle rolí) všemi základními postupy a procesy v SW (aplikaci)

• seznam klíčových pojmů a výrazů použitých v SW (např. uživatel, oprávnění, menu,…)

• uživatelský manuál

1. Administrátorskou dokumentaci předávanou v rámci Plnění ke všem komponentám s popisem všech nástrojů a úkonů, nutných k provozu aplikace, včetně zdrojových kódů dokumentace a postupu generování a aktualizace dokumentace. Součástí administrátorské dokumentace bude:

• dokument popisující reinstalaci všech komponent (on site)

• dokument popisující kompletní potřebné nastavení operačního systému a dodaných komponent. Dle této dokumentace musí být možné kompletně nainstalovat a zprovoznit produkty a komponenty aplikace včetně jejich customizací

• popis autentizace a autorizace – způsob ověřování (např.: integrované na LDAP nebo vlastní), seznam všech oprávnění (rolí), uživatelů a autorizačních skupin. Detailní popis rozdělení uživatelů do skupin a všechny ostatní autorizační údaje potřebné k provozu aplikace z hlediska autorizace

• seznam všech nainstalovaných komponent včetně verzí a prostředí (pokud je součástí akceptace více prostředí) a licencí

• komponentový diagram popisující závislost a propojení jednotlivých komponent

• dokumentace integračních vazeb

• detailní popis technologických procesů a činností probíhajících v aplikaci

• doporučení pro monitoring běhu a zdraví aplikace, včetně seznamu všech chybových záznamů a popisů jejich významu

• informace a postupy nutné k zálohování a obnově

• popis mechanismu zabezpečení jednotlivých částí systému a způsob logování přístupů

1. seznámení členů testovacího týmu Objednatele se všemi funkcemi Díla včetně praktického předvedení; podpora a součinnost při provádění Akceptačních testů

2. kompletní informace o zadání, průběhu a výsledcích testování Xxxx provedeného Dodavatelem před předáním Díla k Akceptačním testům

3. Nastavení všech potřebných parametrů a další náležitosti dle požadavků dle specifikace uvedené v Příloze č. 1 Smlouvy. V případě, že nebudou splněny náležitosti uvedené v tomto odstavci Smlouvy k datu plnění uvedenému v této Smlouvě, jde o porušení povinností vyplývajících ze Smlouvy a Objednatel je oprávněn odmítnout zahájení Akceptačních testů Plnění.

1. Objednatel má právo při Akceptačním testu ověřovat všechny funkce Díla ve smyslu jeho specifikace.

2. Kategorizace Vad zjištěných v průběhu Akceptačních testů:

   1. Vadou kategorie A se rozumí taková Vada, která způsobuje tak závažné problémy, že další vývoj ani dodržení dohodnutého časového plánu nejsou možné. Za Vadu kategorie A se považuje i případ, kdy Objednatel z důvodů na straně Dodavatele nemůže Dílo nebo jakoukoli jeho část používat nebo ovládat, případně nemůže být dostatečně zaručeno další fungování Díla nebo jeho části. Mezi Vady kategorie A se počítají i takové Vady, které by úplně znemožnily samotnou podstatu obchodního užití Díla, nebo by zapříčinily, že by Xxxx bylo nebezpečné nebo že by se Xxxx zastavilo. Vadou kategorie A je i to, že Xxxx není schopno zpracovat Objednatelem specifikovanou provozní zátěž. Za Vadu kategorie A se považuje i Vada s výše uvedenými dopady na funkčnost Díla, která se projevuje občas nebo náhodně. Vadou kategorie A jsou i právní vady Díla bránící jeho užívání v souladu s touto Smlouvou.

   2. Vadou kategorie B se rozumí taková Vada, která ohrozí další pokračování Akceptačních testů, jestliže nebude odstraněna, anebo provoz dalších částí Díla. Za Vadu kategorie B se považuje také taková Vada, která zapříčiní, že by nebyly podporovány některé části Díla bez přiměřené náhrady. Mezi Vady kategorie B patří i neschopnost zpracovat maximální provozní zátěž. Vadou kategorie B je i Vada s výše uvedenými dopady na funkčnost Díla, která se projevuje občas nebo náhodně.

   3. Vadou kategorie C se rozumí taková Vada, která způsobí částečný neúspěch Akceptačních testů. V případě existence Vady kategorie C nesmí dojít za provozních podmínek ke ztrátě žádné závažné funkce Díla, anebo je možné pro její překonání nalézt odpovídající alternativu. Mezi Vady kategorie C nepatří Vady způsobené drobnými konstrukčními nedostatky anebo ty, které jsou pouze „kosmetické“ povahy. Vady této kategorie nesmí ohrozit další provoz Díla se skutečnými provozními daty. Vadou kategorie C je i Vada s výše uvedenými dopady na funkčnost Díla, která se projevuje občas nebo náhodně.

3. Kategorizaci Vad provádí Objednatel. Vadami nemohou být označovány vady Software/hardware jehož není Dodavatel dodavatelem, pro odstranění takovýchto vad poskytne Dodavatel součinnost. Za Vady se však považují nefunkčnost, omezená funkčnost a jiné vady ve fungování Software/hardware, jehož dodavatelem není Dodavatel, vzniklé v důsledku nebo v souvislosti s jakýmkoli jednáním Dodavatele, zejména vlivem jakéhokoli zásahu Dodavatele do takového Software/hardware či jeho nastavení. O Vadách a jejich zařazení Objednatel písemně informuje Xxxxxxxxxx formou reportů o Vadě (viz Příloha č. 6 Smlouvy). O námitkách Dodavatele proti zařazení kterékoliv Vady do určité kategorie rozhoduje s konečnou platností odpovědný pracovník za Objednatele a v jeho nepřítomnosti jeho zástupce. Námitku proti zařazení zjištěné Vady do některé z kategorií může Dodavatel podat v písemné formě do konce druhého (2.) pracovního dne následujícího po doručení oznámení Objednatele o zjištění Vady Dodavateli, jinak se k ní nepřihlíží. Objednatel je povinen na tuto žádost odpovědět do konce pátého (5.) pracovního dne následujícího po obdržení námitky. Neučiní-li tak, má se za to, že námitce Xxxxxxxxxx vyhovuje.

4. Oznamování Vad:

   1. Vady kategorie A nebo B zjištěné v průběhu Akceptačních testů Díla bude Objednatel oznamovat Dodavateli v písemné formě nebo na Service Desk Objednatele ihned po jejich zjištění;

   2. Vady kategorie C zjištěné v průběhu Akceptačních testů bude Objednatel oznamovat Dodavateli písemně v týdenní periodě (vždy nejpozději do 15. hodiny posledního pracovního dne v příslušném kalendářním týdnu), nebude-li písemně dohodnuto jinak.

5. Termíny odstranění Vad:

   1. Vadu kategorie A je Dodavatel povinen odstranit nejpozději do dvou (2) pracovních dnů následujících od jejího písemného nahlášení Objednatelem, pokud se Smluvní strany nedohodnou jinak. Neodstranění Vad kategorie A ve stanovené lhůtě má za následek zastavení Akceptačních testů, pokud se Smluvní strany nedohodnou jinak. Pokud Dodavatel neodstraní ve shora uvedené lhůtě všechny zjištěné Vady kategorie A, pak bude Objednatel oprávněn požadovat úhradu smluvní pokuty dle čl. 18 Smlouvy. Po odstranění Vady kategorie A je Dodavatel povinen Objednateli na jeho žádost předvést, že Xxxx byla úspěšně odstraněna.

   2. Vadu kategorie B je Dodavatel povinen odstranit do dvou (2) pracovních dnů následujících od jejího písemného nahlášení Objednatelem, pokud se Smluvní strany nedohodnou jinak. Neodstranění Vad kategorie B tak, aby jejich počet byl menší než tři (3), má za následek zastavení Akceptačních testů, pokud se Smluvní strany nedohodnou jinak. Pokud Dodavatel neodstraní ve shora uvedené lhůtě Vadu kategorie B, pak bude Objednatel oprávněn požadovat úhradu smluvní pokuty dle čl. 18 Smlouvy.

   3. Vadu kategorie C je Dodavatel povinen odstranit nejpozději do pěti (5) pracovních dnů následujících od jejího písemného nahlášení Objednatelem, pokud se Smluvní strany nedohodnou jinak. Neodstranění Vad kategorie C tak, aby jejich počet byl menší než deset (10), má za následek zastavení Akceptačních testů, pokud se Smluvní strany nedohodnou jinak. Pokud Dodavatel neodstraní ve shora uvedené lhůtě Vadu kategorie C, pak bude Objednatel oprávněn požadovat úhradu smluvní pokuty dle čl. 18 Smlouvy.

   4. Dodavatel může písemně požádat Objednatele o prodloužení lhůty pro odstranění Vad, a to nejméně dva (2) pracovní dny před uplynutím běžné lhůty pro odstranění Vad. Objednatel je povinen na tuto žádost odpovědět do konce prvního pracovního dne následujícího po obdržení žádosti. Neučiní-li tak, má se za to, že žádosti Xxxxxxxxxx nevyhovuje.

6. Zastavení Akceptačních testů:

Pokud počet zjištěných, nahlášených a v jednom okamžiku neopravených Vad dosáhne jakéhokoli z těchto limitů:

• jedna (1) Vada kategorie A

• tři (3) Vady kategorie B

• deset (10) Vad kategorie C

má Objednatel právo zastavit Akceptační testy a to až do doby, než počet neopravených Vad bude nižší, než tyto limity, a o této skutečnosti neprodleně písemně uvědomí Dodavatele. Zastavení Akceptačních testů nemá vliv na případné prodlení Dodavatele ani na nároky Objednatele podle čl. 18 Smlouvy.

10. Obnovení Akceptačních testů po jejich zastavení:

Objednatel je povinen neprodleně zahájit zastavené Akceptační testy na základě písemného sdělení Dodavatele o odstranění Vady kategorie A / snížení počtu Vad kategorie B na dvě (2) a méně / snížení počtu Vad kategorie C na devět (9) a méně. Lhůta pro dokončení Akceptačních testů Objednatelem se v takovém případě prodlužuje o dobu, po kterou bylo zastaveno testování. Lhůta pro předání Díla zůstává nezměněna, stejně jako případné nároky Objednatele dle čl. 18 Smlouvy.

11. Neúspěšné ukončení Akceptačních testů z důvodů Vad:

    1. Pokud nedojde k obnovení zastavených Akceptačních testů z důvodů ležících na straně Dodavatele do pěti (5) pracovních dnů následujících po oznámení Objednatele o zastavení Akceptačních testů, jsou Akceptační testy považovány za ukončené s výsledkem „Dílo nevyhovuje“, pokud se Smluvní strany nedohodnou jinak. Dodavatel může písemně požádat Objednatele o prodloužení této lhůty, a to nejméně dva (2) pracovní dny před jejím uplynutím. Objednatel je povinen na tuto žádost odpovědět do konce prvního (1.) pracovního dne následujícího po obdržení žádosti. Neučiní‑li tak, má se za to, že žádosti Xxxxxxxxxx nevyhovuje.

    2. Pokud nedojde k obnovení Akceptačních testů z  důvodů na straně Objednatele, bude vzniklá situace řešena dohodou Smluvních stran. O dobu trvání řešení takové situace se prodlužují lhůty k předání a převzetí Díla.

12. O ukončení Akceptačních testů informuje Objednatel Dodavatele vždy písemně do pěti (5) pracovních dnů od jejich ukončení. Výsledkem Akceptačních testů bude výrok:

    1. Dílo vyhovuje, jestliže Akceptační testy byly ukončeny úspěšně, nebyla zjištěna žádná Vada kategorie A, více než dvě (2) Vady kategorie B a/nebo více než devět (9) Vad kategorie C, anebo byly všechny Vady, jejichž počet překračuje tyto stanovené limity, odstraněny a jejich odstranění bylo prokazatelně ověřeno před ukončením Akceptačních testů (tyto skutečnosti se uvedou v zápisu o průběhu Akceptačních testů). V takovém případě se Objednatel se Dodavatelem písemně dohodnou na termínu odstranění všech zbývajících Vad s tím, že maximální lhůta na odstranění Vad kategorie B a C nepřesáhne dvacet jedna (21) kalendářních dnů od data podpisu Akceptačního protokolu. Nedodržení této maximální lhůty bude považováno za podstatné porušení Smlouvy ze strany Dodavatele.

    2. Dílo nevyhovuje, jestliže Akceptační testy nebyly ukončeny úspěšně, byla zjištěna Vada či Vady kategorie A, více než dvě (2) Vady kategorie B a/nebo více než devět (9) Vad kategorie C s tím, že Vady, jejichž počet překračuje tyto limity, nebyly odstraněny nebo jejich odstranění nebylo prokazatelně ověřeno do konce Akceptačních testů z důvodů neležících na straně Objednatele (tyto skutečnosti se uvedou v zápisu o průběhu Akceptačních testů). Ukončení Akceptačních testů s odůvodněným výrokem „Dílo nevyhovuje“ je považováno za podstatné porušení Smlouvy ze strany Dodavatele, pokud se Smluvní strany nedohodnou jinak.

13. Dojde-li v průběhu Akceptačních testů k zjištění neodstranitelné Vady jakékoli kategorie, může to být ze strany Objednatele považováno za podstatné porušení této Smlouvy, jestliže taková Vada vážným způsobem narušuje užívání Díla.

14. V případě výroku „Dílo nevyhovuje“ je Dodavatel nadále povinen pracovat na řádném odstranění zjištěných Vad, přičemž je povinen po jejich odstranění bez zbytečného odkladu vyzvat Objednatele k opakování Akceptačních testů v takovém termínu, aby bylo možné je provést a zároveň nebyla zmařena možnost splnění termínu pro předání celého Díla, uvedeného ve Smlouvě.

15. Nevyzve-li Dodavatel Objednatele k opakování Akceptačních testů po odstranění Vady kategorie A / snížení počtu Vad kategorie B na dvě (2) a méně / snížení počtu Vad kategorie C na devět (9) a méně do doby patnácti (15) kalendářních dnů od doručení výroku „Dílo nevyhovuje“ Dodavateli, je toto považováno za podstatné porušení Smlouvy ze strany Dodavatele.

16. Pro podstatné porušení Xxxxxxx Dodavatelem popsané v tomto článku Smlouvy bude Objednatel oprávněn od Smlouvy odstoupit. Neučiní-li tak, prodlužuje se doba pro převzetí Díla o dobu dohodnutou oběma Smluvními stranami, která nebude kratší než pět (5) a delší než patnáct (15) kalendářních dní. Po marném uplynutí této lhůty je Objednatel opět oprávněn s okamžitou platností odstoupit od Smlouvy.

17. Dodavatel není oprávněn ve smyslu ust. § 2609 Občanského zákoníku Dílo na účet Objednatele vhodným způsobem prodat, nepřevezme-li Objednatel Dílo bez zbytečného odkladu poté, co Dílo mělo být dokončeno, a bylo-li dokončeno později, tak bez zbytečného odkladu po vyrozumění o dokončení Díla.

18. Akceptace Služeb na objednávku dle odst. 2.2.5 Smlouvy probíhá vždy za kalendářní měsíc, a to následujícím způsobem:

    1. Dodavatel bude u Služeb na objednávku evidovat svou práci počtem MD ve výkazu práce (dále jen „Výkaz práce“). Výkaz práce předkládaný Objednateli bude obsahovat počet MD za všechny pracovníky Dodavatele. Výkaz práce bude součástí Akceptačního protokolu ke Službám na objednávku poskytnutým v daném měsíci.

    2. Dodavatel zpracuje návrh Akceptačního protokolu a předkládá jej Objednateli současně s Výkazem práce. Předání a akceptace příslušné Služby na objednávku Objednatelem bude potvrzena podpisem zástupce Objednatele ve věcech technických na Akceptačním protokolu.

    3. Objednatel může akceptaci odmítnout v případě, že předaná Služba na objednávku vykazuje na základě vyhodnocení akceptačních kritérií natolik vážné vady, že nemůže sloužit svému účelu vůbec nebo s výraznými omezeními. V případě méně vážných vad
       se použije akceptace s výhradami.

    4. V případě, že akceptace byla provedena s výhradami Objednatele, je Dodavatel povinen zjednat nápravu do pěti (5) kalendářních dnů, nebude-li dohodou Smluvních stran stanoveno jinak.

    5. Byla-li Služba na objednávku akceptována, Dodavatel může fakturovat Objednateli plnou výši ceny této Služby na objednávku. Byla-li Služba na objednávku akceptována s výhradou, je Služba na objednávku řádně poskytnuta a Dodavateli vznikne právo na zaplacení ceny a vystavení daňového dokladu (faktury) až po zjednání nápravy a bezvýhradné akceptaci Služby na objednávku.

1. Sankce

   1. V případě, že je Dodavatel v prodlení s poskytnutím předmětu plnění v termínu dle odst. 5.1 Xxxxxxx, je Objednatel oprávněn vyúčtovat a Dodavatel povinen zaplatit smluvní pokutu ve výši 0,5 % z celkové ceny předmětu plnění dle odst. 3.1 Smlouvy za každý započatý den prodlení.

   2. Bude-li Objednatel v prodlení s úhradou ceny předmětu plnění, má Dodavatel právo žádat na Objednateli úrok z prodlení v souladu s nařízením vlády č. 351/2013 Sb., kterým se určuje výše úroků z prodlení a nákladů spojených s uplatněním pohledávky, určuje odměnu likvidátora, likvidačního správce a člena orgánu právnické osoby jmenovaného soudem a upravují některé otázky Obchodního věstníku a veřejných rejstříků právnických a fyzických osob, ve znění pozdějších předpisů.

   3. V případě porušení kterékoli povinnosti nebo nepravdivosti prohlášení Dodavatele dle čl. 6, čl. 10 nebo čl. 13 Smlouvy je Objednatel oprávněn vyúčtovat a Dodavatel povinen zaplatit Objednateli smluvní pokutu ve výši 500.000,- Kč (slovy: pět set tisíc korun českých) za každé jednotlivé porušení povinnosti/každý jednotlivý případ nepravdivosti prohlášení.

   4. V případě nedodržení sjednané doby odezvy při poskytování Podpory a údržby dle Přílohy č. 1 Smlouvy je Objednatel oprávněn vyúčtovat a Dodavatel povinen zaplatit smluvní pokutu ve výši 1.000,- Kč (slovy: tisíc korun českých) za každou započatou hodinu prodlení.

   5. V případě prodlení s odstraněním Vad ve lhůtách dle čl. 17 Smlouvy je Objednatel oprávněn požadovat a Dodavatel povinen zaplatit smluvní pokutu ve výši 2.000,- Kč (slovy: dva tisíce korun českých), a to za každý započatý kalendářní den tohoto prodlení a každou Vadu.

   6. V případě porušení závazku Dodavatele mít po celou dobu trvání Smlouvy sjednáno pojištění odpovědnosti za majetkové i nemajetkové újmy dle odst. 14.4.15 je Objednatel oprávněn požadovat od Dodavatele zaplacení smluvní pokuty ve výši 100.000 Kč (slovy: sto tisíc korun českých). Nedoloží-li Dodavatel do 7 kalendářních dnů ode dne písemného vyzvání Objednateli doklad o pojištění dle odst. 14.4.15 Xxxxxxx, je Objednatel oprávněn požadovat od Dodavatele zaplacení smluvní pokuty ve výši 10.000,- Kč (slovy: deset tisíc korun českých) za každý započatý kalendářní den prodlení.

   7. Uplatněním jakékoliv smluvní pokuty není nijak dotčeno právo na náhradu vzniklé újmy v celém rozsahu.

   8. Vyúčtování smluvní pokuty musí být zasláno doporučeně s dodejkou. V případě zaslání v elektronické podobě musí být vyúčtování smluvní pokuty zasláno do datové schránky. Smluvní pokuta je splatná v době třiceti (30) kalendářních dnů ode dne doručení vyúčtování o smluvní pokutě druhé Smluvní straně.

   9. Objednatel je v případě uplatnění smluvní pokuty vůči Dodavateli dle této Smlouvy a neuhrazení smluvní pokuty ze strany Dodavatele oprávněn využít jednostranné započtení vzájemných pohledávek, a to i v případě, že kterákoli ze započítávaných pohledávek ještě není splatnou.

2. Doba trvání Smlouvy

   1. Tato Xxxxxxx nabývá platnosti dnem jejího podpisu Smluvními stranami a účinnosti dnem zveřejnění v registru smluv podle zákona o registru smluv. Plnění předmětu této Smlouvy v době od platnosti Xxxxxxx do její účinnosti se považuje za plnění podle této Smlouvy a práva a povinnosti z něj vzniklé se řídí touto Smlouvou.

   2. Tato Xxxxxxx se uzavírá na dobu určitou, a to na dobu 12 měsíců ode dne nabytí účinnosti Smlouvy.

   3. Tato Smlouva může být předčasně ukončena, a to pouze:

      1. písemnou dohodou Smluvních stran; nebo

      2. odstoupením jedné ze Smluvních stran od této Smlouvy z důvodu podstatného porušení Smlouvy druhou stranou za podmínek uvedených v následujících odstavcích tohoto článku Smlouvy, nebo z jiných důvodů ve Smlouvě výslovně sjednaných nebo stanovených zákonem.

   4. Za podstatné porušení této Smlouvy se považuje:

      1. Objednatel je v prodlení s úhradou ceny předmětu plnění delším než dvacet (20) kalendářních dnů od písemného upozornění Dodavatele;

      2. Dodavatel je v prodlení s plněním jakékoliv povinnosti z této Smlouvy déle než patnáct (15) kalendářních dnů;

      3. Smluvní strana se dopustila vůči druhé Smluvní straně jednání vykazující znaky nekalé soutěže a toto porušení Xxxxxxx nenapravila ani přes písemnou výzvu poškozené strany v přiměřené, k tomu stanovené lhůtě;

      4. je-li Dodavatel v likvidaci nebo vůči jeho majetku probíhá insolvenční řízení, v němž bylo vydáno rozhodnutí o úpadku, nebo byl konkurs zrušen proto, že majetek byl zcela nepostačující nebo byla zavedena nucená správa podle zvláštních právních předpisů;

      5. pravomocné odsouzení Dodavatele za trestný čin.

   5. Odstoupení je účinné od okamžiku, kdy je doručeno písemné prohlášení jedné Smluvní strany o odstoupení od Smlouvy druhé Smluvní straně.

   6. Odstoupením od Smlouvy nebo její části nejsou dotčena ustanovení týkající se smluvní pokuty, záruky, náhrady újmy, licencí a jiných ze své povahy přetrvávajících nároků či závazků.

   7. Plnění řádně (bez vad) poskytnutá a převzatá před odstoupením od Xxxxxxx se nevrací, není-li v této Smlouvě ujednáno jinak nebo nedohodnou-li se Smluvní strany jinak. V případě vracení plnění jsou Smluvní strany povinny vzájemnou písemnou dohodou vypořádat dosavadní přijatá smluvní plnění nejpozději do jednoho (1) měsíce od účinnosti odstoupení od Smlouvy.

3. Závěrečná ustanovení

   1. Tato Smlouva a vztahy z ní vyplývající se řídí právním řádem České republiky, zejména příslušnými ustanoveními Občanského zákoníku a Autorského zákona. V případě rozporu mezi vlastním textem Xxxxxxx a přílohami má přednost vlastní text Xxxxxxx.

   2. Smluvní strany si ve smyslu ust. § 1765 odst. 2 Občanského zákoníku ujednaly, že Dodavatel na sebe přebírá nebezpečí změny okolností.

   3. Smluvní strany se dohodly, že ustanovení § 1799 a 1800 Občanského zákoníku se nepoužijí.

   4. Smluvní strany se zavazují vyvinout maximální úsilí k odstranění vzájemných sporů, vzniklých na základě této Smlouvy nebo v souvislosti s touto Smlouvou, a k jejich vyřešení zejména prostřednictvím jednání odpovědných pracovníků nebo jiných pověřených subjektů. Nedohodnou-li se Smluvní strany na způsobu řešení vzájemného sporu, má každá ze Smluvních stran právo uplatnit svůj nárok u soudu České republiky příslušného dle platných právních předpisů. Smluvní strany se dohodly, že místně příslušným soudem pro řešení případných sporů bude soud příslušný dle místa sídla Objednatele.

   5. Smlouvu lze měnit pouze výslovným písemným ujednáním Smluvních stran, podepsaným oprávněnými zástupci Smluvních stran. Tato ujednání budou nazývána „Dodatek“ a budou číslována vzestupnou číselnou řadou. Jakákoliv Smluvní strana je oprávněna vyvolat jednání k doplnění či změně této Smlouvy. Změna kontaktních osob a spojení uvedených v čl. 15 Smlouvy je účinná v okamžiku doručení oznámení o této změně druhé Smluvní straně, aniž by bylo nutno vyhotovovat dodatek k této Smlouvě.

   6. Dnem doručení písemností odeslaných na základě této Smlouvy nebo v souvislosti s touto Smlouvou, pokud není prokázán jiný den doručení, se rozumí poslední den lhůty, ve které byla písemnost pro adresáta uložena u provozovatele poštovních služeb a to i tehdy, jestliže se adresát o jejím uložení nedověděl. Smluvní strany tímto výslovně vylučují ust. § 573 Občanského zákoníku.

   7. Tato Smlouva je vyhotovena ve dvou (2) rovnocenných vyhotoveních, z nichž každé má platnost originálu. Každá ze Smluvních stran obdrží jedno (1) vyhotovení.

   8. Dodavatel tímto prohlašuje, že mu byly ze strany Objednatele sděleny veškeré skutkové a právní okolnosti související s uzavřením této Smlouvy a že Dodavatel je v tomto ohledu přesvědčen o jeho schopnosti uzavřít a plnit tuto Smlouvu, má zájem tuto Smlouvu uzavřít a je schopen plnit veškeré povinnosti z této Smlouvy plynoucí.

   9. Smluvní strany tímto prohlašují, že neexistuje žádné ústní ujednání, Smlouva či řízení některé Smluvní strany, které by nepříznivě ovlivnilo výkon jakýchkoliv práv a povinností dle této Smlouvy. Zároveň potvrzují svým podpisem, že veškerá ujištění a dokumenty dle této Smlouvy jsou pravdivé, platné a právně vymahatelné.

   10. Pro případ, že tato Xxxxxxx není uzavírána za přítomnosti obou Smluvních stran, platí, že Smlouva nebude uzavřena, pokud ji Dodavatel podepíše s jakoukoliv změnou či odchylkou, byť nepodstatnou, nebo dodatkem, ledaže Objednatel takovou změnu či odchylku nebo dodatek následně schválí. To platí i v případě připojení obchodních podmínek Dodavatele, které budou odporovat svým obsahem jakýmkoliv způsobem textu této Smlouvy.

   11. Nedílnou součástí Smlouvy jsou následující přílohy:

Příloha č. 1 - Specifikace předmětu plnění

Příloha č. 2 - Cena plnění

Příloha č. 3 - Realizační tým

Příloha č. 4 - Protokol o předání a převzetí – Akceptační protokol

Příloha č. 5 - Tabulka technických požadavků

Příloha č. 6 - Report o Vadě

NA DŮKAZ TOHO, že Smluvní strany s obsahem Xxxxxxx souhlasí, rozumí ji a zavazují se k jejímu plnění, připojují své podpisy a prohlašují, že tato Xxxxxxx byla uzavřena podle jejich svobodné a vážné vůle prosté tísně, zejména tísně finanční.

V Praze	V Praze
___________________________	___________________________
Xxx. Xxxxxxxx Xxxxxxx ředitelem úseku ICT a eGovernment Česká pošta, s.p.	Xxx. Xxxx Xxxxxxxxxxx jednatel INTEDO s.r.o.

Za formální správnost a dodržení všech interních postupů a pravidel ČP:

xxx

Příloha č. 1 - Specifikace předmětu plnění

1 Úvod 29

2 Procesní vymezení 29

3 Popis stavu procesů 30

3.1 Service Desk 30

3.2 Incident Management 30

3.3 Service Asset and Configuration Management 32

3.4 Request Management 34

3.5 Change Management 35

3.6 Service Level Management / Service Catalogue 35

3.7 Problem Management 36

3.8 Mobilní řešení 36

4 Popis stavu technické platformy 37

4.1 Infrastruktura 37

4.2 Technické rozšíření HPSM 38

4.2.1 CfgM portál 38

4.2.2 RECO DB 38

4.3 Integrace 38

4.3.1 Příchozí a odchozí mailové zprávy 38

4.3.2 Podpora požadavků externě dodávaných služeb je zajištěna integracemi s externími ITSM systémySpráva uživatelů a jejich oprávnění 38

4.3.3 Dohledy 38

4.3.4 Integrace prostřednictvím webových služeb 38

5 Požadavky na nové řešení 38

5.1 Procesní upgrade 38

5.2 Specifické požadavky 39

5.2.1 Service Desk 39

5.2.2 Incident Management 39

5.2.3 Service Asset and Configuration Management 39

5.2.4 Change Management 39

5.2.5 Service Level Management / Service Catalogue 40

5.2.6 Problem Management 40

5.3 Obecné požadavky řešení 40

5.3.1 Uživatelské rozhraní 40

5.3.2 Základ řešení 41

5.3.3 Podpora procesů ITSM 41

5.3.4 Integrace 43

5.3.5 Role a přístupová práva 44

5.3.6 Automatizace 44

5.3.7 Bezpečnost 44

5.4 Minimální požadované atributy pro osamostatňované entity 45

1. Úvod

V minulých letech byla implementována centrální ITSM platforma, která tvoří klíčovou součást správy ICT služeb, nikoliv pouze úseku ICT a eGovernment. Tento systém, založený na produktu HP Service Manager verze 9, byl během projektu procesně a technicky přizpůsoben potřebám Objednatele. Dynamické změny posledních let se odráží nejen v celé společnosti, ale také v požadavcích na úroveň vyspělosti jednotlivých procesů. Pro dosažení další úrovně spolehlivosti provozních i taktických procesů bylo vypsáno toto výběrové řízení na procesní upgrade.

Celá aktivita má několik strategických cílů:

• dosažení vyšší úrovně vyspělosti procesů (process maturity)

• ochrana investic do současného řešení a využití znalosti pracovníků Objednatele

• technické povýšení stávajícího řešení

Pro dosažení těchto cílů je poptáváno řešení procesního upgrade ITIL platformy. K tomu je zapotřebí:

• splnit (procesně) obecné i specifické požadavky tohoto zadání

• zachovat stávající konfigurační položky včetně vazeb mezi nimi

• zachovat stávající funkčnost, zejména Incident management

• zachovat stávající integrace

• zlepšit uživatelské rozhraní a portál

• zlepšit možnosti nových integrací – jak dávkové, tak procesní/událostní integrace.

Součástí řešení musí být migrace do nové infrastruktury (zajišťuje Objednatel) provozované buď na virtuálních serverech nebo v kontejnerizovaném prostředí Docker/Kuberenetes.

Celkový počet tiketů (interakcí, incidentů), které byly zpracovány ve stávajícím systému v roce 2020, ukazuje následující přehledová tabulka po jednotlivých měsících:

Měsíc	1	2	3	4	5	6	7	8	9	10	11	12	celkem
interakce	78623	62536	67732	71974	69218	71843	64879	59919	61131	71791	72348	77772	829766
incidenty	17569	16159	12964	11435	14927	18366	15141	14755	15490	15830	13529	11591	177756
celkem	96192	78695	80696	83409	84145	90209	80020	74674	76621	87621	85877	89363	1007522

2. Procesní vymezení

Objednatel poptává procesní upgrade – tedy funkční i technické zhodnocení již existujícího informačního systému, ve kterém jsou centrálně řízeny procesy (užity anglické termíny):

• Service Desk (Call centrum),

• Incident Management,

• Problem Management, Není nasazen je předmětem projektu

• Request Management,

• Change Management, Není nasazen je předmětem projektu

• Service Level Management

• Service Asset and Configuration Management.

Procesní vyspělost jednotlivých procesů je rozdílná, aktuální stav je popsán v kapitolách výchozího stavu procesů.

3. Popis stavu procesů

V následujících kapitolách je uveden popis současného stavu jednotlivých procesů.

1. Service Desk

Service Desk je implementován v centrální platformě HPSM, jeho další rozvoj je omezen technickými prostředky aplikace. Podpora interních i externích zákazníků je poskytována centralizovaně do jednoho unifikovaného procesu. Na vykonávání tohoto procesu se aktuálně podílí 8 servicedeskových skupin (pracovních týmů), na které jsou jednotlivé požadavky zákazníků směřovány, a to dle charakteru nebo kategorizace dotazu/požadavku:

Řešitelská skupina	Kompetence	Poznámka
ICT	Podpora požadavků týkajících se IT – HelpDesk ICT v rámci útvaru ITC provoz, úsek ICT a eGovernment
APOST, INFO, HR	Oddělení call centrum, útvar poštovní technologie
BICT	Kybernetické události a incidenty – útvar ICT bezpečnost, úsek ICT a eGovernment
BPP	Požadavky na specializovaný útvar bezpečnosti poštovního provozu, útvar bezpečnost
TSM	Požadavky na údržbu majetku ČP – v kompetenci útvaru správa majetku, úsek správa majetku a strategických investic
SLDB	Podpora projektu SLDB 2021	externí skupina

2. Incident Management

Proces Incident Management obsahuje jak podporu interních, tak i externích zákazníků a je implementován ve stejnojmenném modulu HPSM. Procesní nastavení obsahuje velké množství customizací a specifických úprav, které jsou zčásti řešeny technickou instrumentací v produktu, zčásti zajištěny metodickými pokyny.

Z hlediska implementovaných funkcí má modul IM velký přesah do procesů Request Fulfilment, Change Management a Problem Management. Z různých důvodů jsou části těchto procesů podporovány úpravou nastavení a workflow právě v modulu IM.

Ve vztahu k tomuto modulu jsou následující požadavky, detailně také v kapitole 5. požadavky na nové řešení

Revize a přizpůsobení změnám po upgrade

• Systém umožní definovat workflow incidentu - průchody fázemi a stavy, nastavení povinnosti atributů a notifikací v různých fázích a stavech, kontroly konzistence a automatizované přechody do dalších fází nebo stavů. Existující workflow bude možné dále upravovat.

• Systém umožní automaticky přiřadit skupinu nebo řešitele incidentu podle různých atributů na vlastním tiketu (např. služby, konfigurační položky, kategorie a priority)

• Systém umožní definovat povinnost atributů v různých stavech a v závislosti na jiných atributech (služba, KP apod.)

• Pro incidenty bude stanoven algoritmus výpočtu priority, který umožní zohlednit naléhavost a dopad incidentu .

• Systém umožní pozastavit řešení incidentu z důvodů čekání na uživatele nebo čekání na dodavatele, na změnu, z jiného důvodu.

• Incidenty mohou být navázány na službu a na konfigurační položku.

• Pro incidenty bude možné nastavit platná SLA/OLA a systém bude poskytovat měření, jak jsou dané parametry SLA/OLA plněny a kdy jsou překročeny.

• Systém umožní automaticky nebo operátorem vyvolanou akcí vytvářet incidenty na základě událostí detekovaných v monitoringu. Integrace bude udržovat vazbu mezi původní událostí a vzniklým incidentem a umožní v definovaných bodech provádět aktualizace události nebo incidentu.

Definuje:

• Revize kompetencí a odpovědnosti rolí – zejména role Incident Managera, koordinátorů napříč odpovědnými útvary ICT a formalizace vztahů procesních rolí vůči vedoucím oddělení.

• Návrh a implementace vazeb mezi incidenty a konfiguračními položkami, využití synergických efektů propojených procesů Incident a Configuration Managementu.

• Vyčlenění ticketů (záznamů) patřících do Request Managementu a jejich migrace do samostatného modulu.

• Vyčlenění ticketů (záznamů) patřících do Change Managementu a jejich migrace do samostatného modulu.

• Vyčlenění ticketů (záznamů) patřících do Problem Managementu a jejich migrace do samostatného modulu.

• Spolupráce při vytváření koncepce vazeb na Katalog služeb a Správu úrovně služeb, přebírání a sledování dílčího plnění jednotlivých SLA, OLA, UC parametrů SLM služeb.

Průběh procesu Incident management je uveden na následujícím obrázku:

3. Service Asset and Configuration Management

Proces Service Asset and Configuration Management je implementován pouze částečně, a to s důrazem na provozní postupy. – Bylo realizováno nasazením procesu CfgM a implementace CMS/CMDB”, který obsahoval:

• implementaci procesu a jeho zavedení v rámci celém úseku ICTG

• určení kompetencí, oprávnění i zodpovědností za správu jednotlivých konfiguračních položek

• zprovoznění jednotného CMS jako zdroje informací o všech konfiguračních položkách a jejich vazbách

• propojení a vytěžení CMDB s ostatními ITSM procesy (incidenty, změny, problémy, requesty)

Provozní postupy Service Asset and Configuration Managementu zahrnují:

• údržbu a rozvoj datového modelu CMDB,

• identifikaci, řízení změn, sledování stavu a audit konfiguračních položek během jejich životního cyklu – každodenní spolupráce s ostatními útvary Objednatele při konsolidaci a zajištění aktuálnosti konfiguračních položek v CMDB

• řešení disproporcí mezi aktuálním stavem evidence a skutečností.

Kromě ICT zdrojů jsou v CMDB spravovány další konfigurační položky, mezi které patří:

• správa majetku – Areály, Budovy, Adresy

• lidské zdroje – organizační struktura, nákladová střediska, business členění a personální data zaměstnanců

• podpora ostatních úseků – vlastnosti služeb, aplikací, infrastruktury apod.

• V CMDB jsou tedy spravovány CI typu contact, operator, oddělení, lokality, aplikace, role, řešitelské týmy atd. včetně vazeb mezi nimi.

• Aby bylo možné zajistit definici problému, jsou v CMDB spravovány také generické CI typu HW i SW pro identifikaci dotčeného zařízení.

• Vzhledem k tomu, že není nasazena CMDB, jsou vytvořeny generické položky typu objekt, který je složen z lokality a oddělení příjemce služby, a tento objekt je přidělen konkrétnímu řešitelskému týmu

Jako budoucí klíčový zdroj dat CMDB je provozována (aktuálně v testovacím prostředí) Universal CMDB (uCMDB).

• Aktuální interní CMDB neobsahuje CI evidované v Asset nástroji AWC (AWCaesar)

• CI evidované v AWC jsou integrací přenášeny do SM_RECO

Obrázek ukazuje stav testovacího prostředí, kde je:

• Funkční instance uCMDB

• Potvrzení technické realizovatelnosti původní FTS

• Byly odstraněny funkční překážky pro integraci s AWC

• Zkonsolidované informace z AWC a SAPu

• Funkční test nasazení Universal Discovery pro Centrální systémy

Ve vztahu k tomuto modulu jsou následující požadavky, detailně také v kapitole 5. požadavky na nové řešení

• Podpora při interní propagaci procesu Service Asset and Configuration Management.

• Návrh postupů sledování průběžného zvyšování správnosti a aktuálnosti konfigurační databáze.

• Revize implementace automatického plnění CMDB z dostupných prostředků, je minimálně požadováno MS SCCM.

• Návrh a nastavení rekonciliace mezi produkčním systém uCMDB a CMDB.

• Podpora revize a zefektivnění údržby CMDB vč. revize rolí.

• Vyhodnocování dopadu změn (RFC impact analysis) na poskytování služeb prostřednictvím vazeb mezi RfC a CI.

4. Request Management

Request management odpovídá za řízení a realizaci tzv. standardních změn v podobě předem známých a rutinních typů požadavků RFC a RFI (Request for Change, Request for Information). Jedná se zejména o:

• požadavky na přidělení oprávnění/rolí v systémech ČP

• požadavky na nákup/obnovu HW, SW, mobilních telefonů apod.

• požadavky na ICT službu (oprava, konfigurace, stěhování VT apod.)

Dále do kompetence Request managementu patří:

• kompletování podkladů pro realizaci požadavku (schválená žádost, převod prostředků)

• komunikace mezi klientem a interními útvary ICT (PKU, PICT, VICT, BICT, AICT atd.)

• řízení životního cyklu požadavků, revize historie otevřených požadavků, delegace požadavků

• revize účinnosti a výkonnosti a dodržování procesu

• monitorování ICT služeb a ICT produktů dodávaných koncovým uživatelům

Odlišení RfC požadavků od incidentů je řešeno pomocnou kategorizací „Požadavek“. Životní cyklus „Požadavku“ je řízen manuálně, protože IM modul neposkytuje potřebnou instrumentaci – např. schvalování, podřízené úkoly atd. Pro každý druh změn je samostatný metodický pokyn. Hromadné požadavky jsou řešeny manuálním několika úrovňovým klonování incidentů.

Ve vztahu k tomuto modulu jsou následující požadavky, detailně také v kapitole 5. požadavky na nové řešení

• Systém umožní definovat workflow požadavku - průchody fázemi a stavy, nastavení povinnosti atributů a notifikací v různých fázích a stavech, kontroly konzistence a automatizované přechody do dalších fází nebo stavů. Existující workflow bude možné dále upravovat.

• Bude zcela vyčleněn z procesu IM

• Systém poskytne workflow - prostředek pro schvalování požadavků - s možností hierarchie více schvalování, delegace schvalování na jinou osobu, s různými politikami schvalování (celá skupina, aspoň jeden za skupinu...).

• K realizaci požadavků bude možné navázat na daný tiket jeden nebo více pracovních příkazů (tasků), řídit je v jejich workflow a podle jejich stavu (dokončení) umožnit pokračování ve workflow původního požadavku.

• Systém umožní definovat povinnost atributů požadavků v různých stavech a v závislosti na jiných atributech (služba, KP, schvalovatel apod.)

• Návrh procesu a nasazení modulu ReqM

• Pro požadavky bude možné nastavit platná SLA/OLA a systém bude poskytovat měření, jak jsou dané parametry SLA/OLA plněny a kdy jsou překročeny.

• požadavky mohou být navázány na službu a na konfigurační položku.

5. Change Management

Pro podporu procesu Change Managementu je využíván modul IM (viz kapitola Incident Management). Modul ChM není implementován. V rámci DICTG slouží proces Change Management primárně pro oblast rozvoje služeb a centrálních aplikací a je přímo svázán s nástroji pro kapacitní plánování Pro evidenci a řízení Request for Change slouží mailový kanál (e – mailová schránka Change Managera), jednotlivé změny nejsou provázány s Konfigurační databází.

Odlišení změnového řízení od incidentů je řešeno pomocnou kategorizací „Požadavek“. Životní cyklus „Požadavku“ je řízen manuálně, protože IM modul neposkytuje potřebnou instrumentaci – např. schvalování, podřízené úkoly atd. Pro každý druh změn je samostatný metodický pokyn. Hromadné změny jsou řešeny manuálním několika úrovňovým klonování incidentů.

Ve vztahu k tomuto modulu jsou následující požadavky, detailně také v kapitole 5. požadavky na nové řešení

• Konfigurace datového modelu operativních skladů výpočetní techniky a náhradních dílů. Naplnění dat zajišťují pracovníci Objednatele.

• Návrh, implementace a podpora pilotního provozu samostatného Change Management procesu – tedy nastavení funkcionality do příslušného modulu, návrh a konfigurace vytvoření příslušných workflow.

• Implementovat podporu hromadných požadavků na změnu (realizující 1 druh změny např. na více koncových stanicích), a to prostřednictvím příslušných change tasků a následnou aktualizací CMDB.

• Návrh a provedení vazby změn do CMDB (viz požadavky SACM), standardizované podklady pro schvalování, relevantní informace o KP k vyhodnocování dopadů změn, audit schválených / autorizovaných změn a jejich promítnutí do CMDB.

6. Service Level Management / Service Catalogue

Proces SLM je implementován tak, aby poskytoval podporu pro dojednávání, dohlížení a vysvětlování úrovní ICT služeb. Úroveň ICT služeb je sledována na úrovni dílčích komponent. Aktuálně je měřeno a vyhodnocováno 15 služeb PKU, a dále služby dle balíčků (partner, standardní pošta, DEPO/SPU, pošta 24/7, administrativa)

Katalog služeb není formalizován, schválen, ani publikován. Služby koncovým uživatelům jsou řízeny na úrovni jednotlivých vstupů (viz Incident Management), celkové garance v podobě SLA parametrů nejsou formalizovány ani sledovány. Konfigurace systému je v SLM generická, univerzální pro všechny oblasti ITSM a slouží pro navázání (pracovních) interních OLA parametrů pro vybrané ICT služby (např. podpora výpočetní techniky na pracovištích koncových uživatelů).

Aktuálně je SLA měřeno dle požadavků konkrétních služby. Katalog ZS služeb obsahuje 15 měřených služeb podle definovaných parametrů

Dále probíhají dílčí měření dle CI (aplikace x priorita), stavu (otevření - převzetí, otevření - vyřešení apod.), např. tikety konkrétních aplikací,.

7. Problem Management

Proces Problem Managementu není formalizován, jeho provádění je intuitivní bez implementace příslušného systémového modulu.

Základní podpora životního cyklu, jak reaktivního, tak proaktivního Problem managementu je řešena v modulu Incident management (obdobně jako v případě Change Managementu). Vzhledem k zásadně rozdílné časové ose incidentu a problému způsobuje toto řešení problémy při reportingu Incident Managementu (časové normativy pro incidenty nejsou dosažitelné v rámci problému).

Základní procesní role nejsou obsazeny, ani formálně definovány, odpovědnost a dokumentace řešených problémů, známých chyb a návazných změn je prováděno „ad-hoc“ na základě zkušenosti jednotlivých pracovníků.

Ve vztahu k tomuto modulu jsou následující požadavky, detailně také v kapitole 5. požadavky na nové řešení

• Systém umožní definovat workflow problému - průchody fázemi a stavy, nastavení povinnosti atributů a notifikací v různých fázích a stavech, kontroly konzistence a automatizované přechody do dalších fází nebo stavů. Existující workflow bude možné dále upravovat.

• Úplné vyčlenění z procesu IM

• Problémy mohou být navázány na službu a na konfigurační položku

• Návrh procesu a nasazení modulu PM

• Systém umožní evidovat známé chyby a poskytne náhled na známé chyby pro stejnou službu a náhled na známé chyby pro stejnou konfigurační položku, řešiteli incidentu

8. Mobilní řešení

Aktuálně existuje, ale je v nevyhovujícím stavu, který neumožňuje technikům v poli adekvátní reakce. Je tedy pro svoji nepřehlednost a nemožnost některých úkonů, nepoužitelný. Ve stavu po upgrade Objednatel požaduje jeho plné nasazení pro cca 400 pracovníků tak, aby byli schopni přijímat, řešit a administrovat veškerou přidělenou práci. To má zásadní dopad na časovou evidenci řešení, ale i na efektivitu vlastní činnosti.

Požadavkem je nasazení plně funkčního mobilního řešení, které bude možno využívat technikem v poli tak, aby dokázal on-line reagovat na přicházející případy a také je dokázal v reálném čase zachytit jejich řešení a měnit jejich stavy příslušných tiketů, podle vzniklé situace. Tyto změny budou zapsány, v reálném čase, do TT systému. Tato funkcionalita bude technikovi dostupná na obrazovce mobilního zařízení tak, aby ji mohl efektivně a bez potíží ovládat. (zobrazení přizpůsobené obrazovce mobilního zařízení)

4. Popis stavu technické platformy

Objednatel provozuje v současné době centrální ITIL platformu. Základní charakteristiky prostředí jsou popsány v následujících tabulkách:

ITIL platforma	Verze
HP Service Manager	9.31.0022

Licence	P/N	Počet
Service Management Automation Suite Express Edition 5 Concurrent Users Software E-LTU	P8E44AAE	130
Service Management Automation Suite Express Edition 5 Named Users Software E-LTU	P8E43AAE	40
Connector for Web Service Server Software Electronic License To use	T4526AAE	1
Universal CMDB Third Party Integration 1 Managed Data Repository Software E-LTU	SWAA031P9

Objednatel nemá zakoupenou podporu výše uvedených licencí. Není tedy možný jejich bezplatný upgrade na poslední verzi SMA-SM 9.70.

Uživatelé	Typ licencí
Každý zaměstnanec Objednatele může prostřednictvím HPSM zadávat svoje incidenty (poruchy) a / nebo požadavky (dotazy, reklamace a stížnosti)	--

Řešitelé	Typ užití	Počet
Aktuální konfigurace umožňuje pokrýt potřeby Objednatele	souběžní řešitelé	380-420
	jmenní řešitelé	40

1. Infrastruktura

Systém HPSM je provozován na této infrastruktuře:

2. Technické rozšíření HPSM

   1. CfgM portál

Pro rychlou informaci o konfiguračních položkách byl vytvořen CfgM portál, který umožňuje uživatelsky přívětivé zobrazení informací z konfigurační databáze (xxxxx://xxxx.xxxxx.xx/xxxxxx, náhled pouze pro řešitele).

2. RECO DB

Dalším rozšířením je tzv. RECO DB, které slouží pro výměnu dat, zejména o integraci primárních zdrojů aplikace AWCaesar, CORG a SAP do CMDB. Jedná se o tyto kategorie údajů:

• Lokality,( Přenáší se integrací z Network inventory přímo do database ITSM)

• Uzly (CI1),

• Objekty (CI2),

• Okresní razítka,

• Organizační strukturu (CORG),

• a data z AWCaesar

3. Integrace

V současném systému HPSM jsou konfigurovány tyto integrace (s částečným využitím Connect-IT):

1. Příchozí a odchozí mailové zprávy

2. Podpora požadavků externě dodávaných služeb je zajištěna integracemi s externími ITSM systémySpráva uživatelů a jejich oprávnění

Z IDM jsou (prostřednictvím LDAP) načítány a aktualizovány údaje o uživatelích, uživatelských účtech a jejich kontaktních údajích.

Pro single-sign-on autentizaci (SSO) je využito centrální Active Directory.

Na základě požadavků/dat v IDM jsou kontaktům (operátorům) v HP SM (uživatelům a řešitelům) automaticky přidělovány uživatelské/řešitelské role (nutná manuální dokonfigurace v HPSM).

3. Dohledy

Z dohledového systému Zabbix jsou (prostřednictvím webových služeb) registrovány incidenty.

4. Integrace prostřednictvím webových služeb

Webovými službami jsou a mohou být připojeny troubleticketové systémy společností třetích stran,.

5. Požadavky na nové řešení

V následujících kapitolách jsou uvedeny požadavky na procesní upgrade, které musí být v rámci projektu vypořádány.

1. Procesní upgrade

S ohledem na ochranu investic do současného řešení a využití znalostí pracovníků Objednatele je poptáváno řešení, které bude obsahovat:

1. upgrade na poslední podporovanou verzi MicroFocus SMA-SM, včetně maitenance na období 12 měsíců

2. Pokrytí funkčních a technických požadavků.

Funkční a technické požadavky jsou rozděleny do hlavních oblastí:

• specifické požadavky založené na potřebách Objednatele a aktuálním stavu vyspělosti daného procesu a

• obecné požadavky na proces vycházející z „best practice“ a norem v dané oblasti

• minimální požadované atributy pro osamostatňované entity

2. Specifické požadavky

V této kapitole jsou uvedeny specifické požadavky založené na potřebách Objednatele a aktuálním stavu vyspělosti daného procesu.

1. Service Desk

Specifické požadavky na upgrade a rozvoj ServiceDesk:

1. Rozvoj podpory ICT i non ICT požadavků (např. správa majetku).

2. Rozvoj řízení oprávnění prostřednictvím bezpečnostních složek.

3. Návrh implementace chatbot systému pro podporu automatizovaného řešení známých chyb a požadavků.

1. Incident Management

1. V případě IM Objednatel požaduje v upgrade řešení zejména narovnání, respektive oddělení skutečných incidentů od ostatních případů, které jsou v tomto procesu řešeny pouze náhradně, a jejich převedení do příslušných, procesně správných modulů požadavků a změn tím, že jejich řešení a schvalovací workflow bude převedeno do odpovídajícího modulu pro správu požadavků či změn.

3. Service Asset and Configuration Management

Specifické požadavky na upgrade a rozvoj Service Asset and Configuration Management jsou:

1. Podpora při interní propagaci procesu Service Asset and Configuration Management.

2. Podpora revize a zefektivnění údržby CMDB vč. revize rolí.

3.  Zachování a rozvoj stávajících integrací

4. Návrh postupů sledování průběžného zvyšování správnosti a aktuálnosti konfigurační databáze.

5. Návrh, implementace a pilotní podpora technické vazby mezi procesy SACM a Change Managementu.

6. Revize implementace automatického plnění CMDB z dostupných prostředků, je minimálně požadováno MS SCCM.

7.  Návrh a nastavení rekonciliace mezi produkčním systém uCMDB a CMDB. Specifické požadavky na integrace jsou:

• možnost systémového propojení mezi SM a uCMDB – integrace v budoucnu zajistí plně aktuální seznam CI a informací o nich u dalších typů CI nad rámec současných.

• jedná se hlavně o data evidovaná v AWC - centrální systémy, další vybavení poboček (např. tiskárny, kopírky, menší IT zařízení), síťovou infrastrukturu, datové okruhy a příslušná zařízení.

• pracovníci Objednatele zde poskytnou součinnost za stranu CMDB.

8. Vyhodnocování dopadu změn (RFC impact analysis) na poskytování služeb prostřednictvím vazeb mezi RfC a CI.

9. Rozšíření databáze CMDB o VT koncových uživatelů a spolupráce se správci ICT aktiv a Change Managementem ve stávajícím IT asset management nástroji.

10. Součinnost při zavedení procesu sledování oprav výpočetní techniky – řízení a sledování procesu opravy výpočetní techniky koncových uživatelů s vazbou mezi požadavkem koncového uživatele a konkrétní dotčenou konfigurační položkou.

4. Change Management

Aktuálně není vůbec v systému nasazen (modul existuje, ale není provozován).

Požadujeme zajistit evidenci životního cyklu případu typu požadavek na změnu v systému v příslušném ChM modulu namísto zasílání požadavků na změnu e-mailem, přičemž vlastní proces řízení změny bude probíhat ve stávajícím nástroji:

1. Umožnit budoucí rozvoj v oblasti kapacitního plánování, kdy bude možné řešené změny předávat k řízení do stávajících a průběžně či po jejich dokončení zpětně vracet do ChM modulu. Zde bude zajištěna změna příslušné CI v CMDB, uzavření případných navazujících tasků, ukončení příslušné interakce ze strany Service Desku a další nezbytná automatizace. Vlastní implementace kapacitního plánování, respektive nahrazení aktuálního systému.

5. Service Level Management / Service Catalogue

Aktuálně je SLA měřeno dle požadavků konkrétních služby. Katalog ZS služeb obsahuje 15 měřených služeb podle definovaných parametrů. Specifické požadavky na upgrade a rozvoj Service Level Management / Service Catalogue jsou:

1. Návrh popisu ICT služeb a veřejně publikovaného Katalogu obchodních a ICT služeb.

2. Návrh, provedení a pilotní podpora procesu pro zřízení, aktualizaci a zrušení ICT služby.

6. Problem Management

S ohledem na to, že Problém management není v nástroji nasazen (modul existuje, ale není provozován) je požadováno zprovoznění modulu ve standardní konfiguraci tak, aby po vnitřním definování procesu a odpovědností PM bylo možno interními silami modul pro podporu procesu nasadit.

3. Obecné požadavky řešení

V této kapitole jsou uvedeny obecné požadavky vycházející z „best practice“ a norem v dané oblasti.

1. Uživatelské rozhraní

Obecné požadavky v oblasti uživatelského rozhraní jsou:

1. GUI koncového uživatele – uživatelsky příjemné rozhraní pro koncového uživatele umožňující zadávat požadavky na službu nebo podporu, zobrazit stav zadaných požadavků, hodnotit realizaci požadavku a hledat ve znalostní bázi.

2. Přístup koncového uživatele bez potřeby licence – koncový uživatel má přístup nevyžadující placenou licenci.

3. GUI řešitele – uživatelsky příjemné rozhraní pro řešitele s možností nastavení vlastních pohledů a reportů, s přehledem o přidělené práci a prioritách.

4. Funkce portálu – konfigurovatelný portál SM poskytující přehledně na jednom místě všechny požadované funkce pro koncového uživatele včetně nabídky Katalogu.

5. Založení požadavku webem – systém umožní snadno zakládat požadavky přes webové rozhraní.

6. Dotazníky pro služby – systém umožní definovat dotazníky pro získání zpětné vazby – na řešení incidentů, podporu služeb, implementaci změn.

7. Povinné atributy – systém umožní definovat povinné atributy při zadávání a následné zpracování tiketů.

8. Spolupráce řešitelů (chat) – řešitelům bude k dispozici chat pro komunikaci při řešení.

9. Zobrazení seznamů/front tiketů – systém umožní definovat pohledy na data s možností filtrace, specificky umožní definovat fronty tiketů čekajících na zpracování (podle definovaných kritérií – úkoly na konkrétního řešitele nebo skupinu, tikety v daném stavu, tikety zadané externím firmám a podobně.

10. Zobrazení formulářů tiketů – systém poskytne flexibilní formuláře pro zobrazení všech objektů (tiketů, uživatelů, skupin, konfiguračních položek a podobně)

11. Vyhledávání – systém poskytne možnost vyhledávání ve všech datových entitách a možnost fulltextového vyhledávání v entitách, které obsahují textové atributy.

12. Systém umožní vytvářet šablony pro jednodušší zadání/vyřešení známého typu požadavku/incidentu

1. Základ řešení

1. Platformy, na kterých lze řešení provozovat – virtuální servery nebo prostředí Docker/Kuberenetes

2. Požadovaná databáze – uveďte, jakou databázi vyžaduje řešení (MSSQL, PostgreSQL, …)

3. Flexibilní reporting – systém musí umožňovat flexibilně definovat různé druhy reportů nad datovými entitami v něm obsaženými – tabulkové výpisy a grafy, ad-hoc reporty a pravidelně generované a distribuované reporty

4. Vazba na konfigurační položky – incidenty, požadavky, problémy a změny bude možné vázat na konfigurační položky.

5. Vazba na SLA/OLA – pro veškeré tikety bude možné definovat a následně pak měřit a reportovat SLA/OLA.

6. Centrální správa číselníků – systém umožní definovat a spravovat použité číselníky.

7. Notifikace – systém umožní definovat spouštění notifikací na základě událostí detekovaných na tiketech (například založení, aktualizace tiketu, přidělení na novou skupinu, upozornění - expirace SLA, …)

8. Řešitelské skupiny – systém umožní definovat řešitelské skupiny pro přidělování a plánování práce. Jeden uživatel může být přidělen do více řešitelských skupin.

9. Základní datové entity podporující všechny oblasti – uživatel, řešitel, řešitelská skupina, oddělení, lokalita, služba, konfigurační položka (KP), role, sdílené číselníky

10. Podpora logování (auditu) změn vybraných záznamů/atributů – v systému bude nastavitelné, jaké změny atributů se budou zapisovat do logu/historie tiketů.

11. Archivace dat – systém poskytne prostředky pro archivaci a následné mazání dat podle definovaných kritérií - např. archivace incidentů starších více než 4 roky.

12. Možnost hromadné aktualizace – systém umožní administrátorovi provádět hromadné operace nad tikety a dalšími záznamy (např. hromadné uzavření tiketů, operace nad uživateli, skupinami, konfiguračními položkami).

13. TT není potřeba migrovat do nového systému, respektive, otevřené budou dořešeny ve starém a nově zadané budou řešeny v novém.

14. Přílohy – systém umožní přikládání příloh k tiketům

1. Podpora procesů ITSM

1. Jedno centrální místo pro hlášení požadavků/poruch – Systém poskytne jednotné místo pro hlášení poruch a zadávání požadavků

2. Přístup koncového uživatele přes portál SD – Koncový uživatel bude mít přístup na zadávání požadavků/incidentů a jejich následnou kontrolu s možností hodnocení přes portál SM

3. Podpora 1. linie SD – 1. linie Service Desku bude mít přehled o zadaných tiketech a požadavcích a bude mít k dispozici reporty o plnění požadovaných lhůt pro řešení tiketů.

4. Eskalace na další úrovně podpory – Tikety umožní provádět eskalaci na další úrovně podpory.

5. Podpora workflow Incidentu – Systém umožní definovat workflow incidentu – průchody fázemi a stavy, nastavení povinnosti atributů a notifikací v různých fázích a stavech, kontroly konzistence a automatizované přechody do dalších fází nebo stavů. Existující workflow bude možné dále upravovat.

6. Grafické zobrazení workflow – Workflow bude možné vizualizovat – graficky znázornit.

7. Automatické přiřazení řešitele/skupiny – Systém umožní automaticky přiřadit skupinu nebo řešitele incidentu podle různých atributů na vlastním tiketu (např. služby, konfigurační položky, kategorie a priority).

8. Povinné atributy incidentu – Systém umožní definovat povinnost atributů v různých stavech a v závislosti na jiných atributech (služba, KP apod.)

9. Priorita – Pro incidenty bude stanoven algoritmu výpočtu priority, který umožní zohlednit naléhavost a dopad incidentu a podle potřeby také další parametry incidentu (například služba, lokalita).

10. Pozastavení řešení incidentu – Systém umožní pozastavit řešení incidentu z důvodů čekání na uživatele nebo čekání na dodavatele, změnu či z jiného důvodu.

11. Vazba incidentu na KP a na službu – Incidenty musí být navázány na službu, a na konfigurační položku.

12. Sledování časů podle SLA/OLA – Pro incidenty bude možné nastavit platná SLA/OLA a systém bude poskytovat měření, jak jsou dané parametry SLA/OLA plněny a kdy jsou překročeny. Parametry SLA/OLA musí umožnit měření časů mezi stavy nebo fázemi na konkrétním incidentu (minimálně reakční doba a doba vyřešení) a dále celkové plnění nad všemi incidenty podle definovaných kritérií (např. pro danou službu nebo lokalitu, pro danou prioritu).

13. Žurnál aktivit nad incidentem – Aktivity provádění nad incidentem budou zaznamenány v žurnálu, bude možné rozlišit, zda má být daná položka žurnálu viditelná koncovému uživateli či nikoli.

14. Vazba na problem management – Bude možné navazovat jeden nebo více incidentů na problem tiket.

15. Podpora workflow Problému – Systém umožní definovat workflow problému - průchody fázemi a stavy, nastavení povinnosti atributů a notifikací v různých fázích a stavech, kontroly konzistence a automatizované přechody do dalších fází nebo stavů. Existující workflow bude možné dále upravovat.

16. Povinné atributy problému – Systém umožní definovat povinnost atributů problému v různých stavech a v závislosti na jiných atributech (služba, KP apod.)

17. Vazba problému na KP a službu – Problémy musí být navázány na službu a na konfigurační položku.

18. Podpora známých chyb – Systém umožní evidovat známé chyby a poskytne náhled na známé chyby pro stejnou službu a náhled na známé chyby pro stejnou konfigurační položku řešiteli incidentu.

19. Správa konfiguračních položek v CMDB – Systém umožní spravovat různé typy konfiguračních položek v centrální konfigurační databázi (CMDB)

20. Vazby Konfiguračních položek – Systém umožní zaznamenávat vazby mezi konfiguračními položkami – orientované vazby různých typů, s možností definice závislostí mezi KP (například jak ovlivňuje výpadek podřízené KP funkčnost nadřízené KP).

21. Životní cyklus konfigurační položky – Systém umožní sledovat konfigurační položky v jejich životním cyklu (pomocí atributu Stav a případně dalších atributů) včetně logování změn konfiguračních položek

22. Business služby – Systém umožní definovat business služby jako speciální typ konfiguračních položek

23. Vazby KP na tikety – Systém umožní evidovat vazby KP na různé typy tiketů (incidenty, problémy, požadavky, změny…).

24. Evidence změn – Systém umožní evidovat změny v rámci definovaného procesu a řídit je jejich životním cyklu

25. Podpora workflow změn – Systému umožní definovat různé typy workflow pro různé typy změn (fáze a stavy, schopnost definovat povinnost atributů v různých částech workflow, přiřazení na řešitele/skupinu).

26. Povinné atributy změn – Systém umožní definovat povinnost atributů změn v různých stavech a v závislosti na jiných atributech (služba, KP apod.)

27. Schvalování změn – Systém poskytne prostředek pro definici schvalování změn - s možností hierarchie více schvalování, delegace schvalování na jinou osobu, s různými politikami schvalování (celá skupina, aspoň jeden za skupinu ...)

28. Vazba změn na KP – Změny musí být navázány na službu a mohou být navázány i na několik konfiguračních položek.

29. Pracovní příkazy ve změnách – K provádění změn bude možné navázat na změnový tiket jeden nebo více pracovních příkazů (tasků), řídit je v jejich workflow a podle jejich stavu (dokončení) umožnit pokračování ve workflow původní změny.

30. SLA – Systém umožní definovat SLA, které se skládají z měřitelných SLR (Service Level Requirements) a vázat je na Služby, Incidenty, Requesty a další tikety. SLR je měřitelná podmínka v rámci SM nástroje, například doba mezi dvěma stavy tiketu je menší než x hodin.

31. SLO – Systém umožní definovat SLO, které se skládají z měřitelných SLR (Service Level Requirements) a vázat je na služby, Incidenty, requesty a další tikety. SLO na rozdíl od SLA měří interně dodávané služby.

32. Měření SLA/SLO – Systém umožní měřit plnění SLA/SLO přiřazených podle služeb a dalších kritérií k tiketům.

33. Notifikace SLA/SLO – Systém umožní nastavit zasílání notifikací v případě překročení SLA/SLO nebo v případě definované uplynuté doby měřené v SLA/SLO (stanovené jako časový údaj, anebo procento definovaného intervalu v SLR)

34. Workflow požadavku – Systém umožní definovat workflow požadavku - průchody fázemi a stavy, nastavení povinnosti atributů a notifikací v různých fázích a stavech, kontroly konzistence a automatizované přechody do dalších fází nebo stavů. Existující workflow bude možné dále upravovat.

35. Schvalování požadavku – Systém poskytne prostředek pro schvalování požadavků - s možností hierarchie více schvalování, delegace schvalování na jinou osobu, s různými politikami schvalování (celá skupina, aspoň jeden za skupinu ...).

36. Pracovní příkazy požadavku – K realizaci požadavků bude možné navázat na daný tiket jeden nebo více pracovních příkazů (tasků), řídit je v jejich workflow a podle jejich stavu (dokončení) umožnit pokračování ve workflow původního požadavku.

37. Povinné atributy požadavku – Systém umožní definovat povinnost atributů požadavků v různých stavech a v závislosti na jiných atributech (služba, KP, schvalovatel apod.)

38. Vazba požadavku na SLA/SLO – Pro požadavky bude možné nastavit platná SLA/OLA a systém bude poskytovat měření, jak jsou dané parametry SLA/OLA plněny a kdy jsou překročeny.

39. Vazba požadavku na službu a KP – požadavky mohou být navázány na službu a na konfigurační položku.

40. Struktura katalogu – V rámci projektu bude navržena aktualizovaná struktura Katalogu služeb, která bude vycházet z existujícího Katalogu. Takto navržená struktura bude podporována v novém SM nástroji.

41. Definice položek katalogu – Bude možné doplňovat, upravovat a aktualizovat definice položek v Katalogu služeb.

42. Vazba na workflow dodavatelů/řešitelů – Katalog bude provázán na workflow v procesu Request Fulfilment a přes API na workflow dodavatelů položek Katalogu nebo jejich dílčích částí.

43. Vyhledávání v katalogu – Výběr položek v Katalogu bude přehledný a bude doplněn možností vyhledávání podle definovaných kritérií.

44. Dostupnost katalogu na Portálu SM – Katalog bude dostupný z Portálu SM.

45. Podpora znalostní báze – Systém umožní vytvářet znalostní bázi na základě řešení incidentů a problémů.

46. Poskytování znalostí koncovému uživateli – Definované (vybrané) části znalostní báze bude k dispozici koncovému uživateli.

47. Životní cyklus znalostí – Systém umožní definovat životní cyklus znalostí (například V přípravě, Aktivní, Zrušeno).

1. Integrace

1. IDM (uživatelské účty) – Systém umožní synchronizovat uživatelské účty z IDM řešení (Active Directory) a použít SSO pro přihlašování.

2. IDM (role) – systém umožní synchronizovat role z IDM (aplikační, byznys…) do CMDB

3. NI (lokality, síťová zařízení) – systém umožní synchronizovat lokality a síťová zařízení (objekty, datové okruhy, routery, porty) do CMDB

4. Dohledové systémy – Systém umožní automaticky nebo operátorem vyvolanou akcí vytvářet incidenty na základě událostí detekovaných v monitoringu. Integrace bude udržovat vazbu mezi původní událostí a vzniklým incidentem a umožní v definovaných bodech provádět aktualizace události nebo incidentu (například uzavření incidentu při uzavření navázané události).

5. uCMDB nebo alternativní zdroj infrastrukturních KP – Systém umožní naplnit CMDB na základě dat z uCMDB (získaných pomocí discovery), anebo z jiného strukturovaného zdroje dat o prvcích infrastruktury.

6. Rozhraní pro externí řešitele/vazba na ITSM nástroje dodavatelů – Systém umožní práci externích dodavatelů nebo podpory prostřednictví integrace SM systému dodavatele přes API.

7. Rozhraní na dávkové přenosy dat – Systém poskytne flexibilní funkce pro dávkový přenos dat oběma směry pro všechny definované datové entity. Bude možné sledovat průběh přenosu, vkládání bude možné kontrolovat aplikační logikou, chyby budou zaznamenány a v případě potřeby bude spuštěna automatická akce na jejich korekci. Budou podporovány všechny běžné formáty dat a protokoly (SQL, CSV, xml, ....)

8. Rozhraní na událostní přenosy dat – Systém poskytne API pro událostmi řízené integrace - například vkládání tiketů z jiných SM nástrojů, jejich párování na interní tikety a průběžná synchronizace podle definovaných pravidel.

9. Inbound e-mail – Systém umožní vkládat a kategorizovat incidenty na základě příjmu strukturovaných e-mailů.

10. Outbound e-mail – Systém umožní zasílání outbound e-mailů na základě událostí definovaných ve workflow.

1. Role a přístupová práva

1. S ohledem na to, že se jedná o UPGRADE, Objednatel požaduje zachování současné funkční podoby. Role a práva jsou dostatečně vymezeny.

1. Automatizace

1. Automatické akce podle workflow – Systém umožní definovat automatické akce spouštěné událostmi ve workflow (např. nový stav, vyřešení tiketu, překročení SLA, ...)

2. Automatické akce podle atributů tiketů – Systém umožní definovat automatické akce na základě detekce změny definovaných atributů (například stavu tiketu)

3. Automatické akce vyvolané integracemi – Systém umožní definovat automatické akce na základě vstupu z integrací (dávkových i událostních).

1. Bezpečnost ICT

1. Obecné požadavky na bezpečnost – Řešení se bude řídit požadavky plynoucími z vyhlášky č. 82/2018 Sb. o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních a o stanovení náležitostí podání v oblasti kybernetické bezpečnosti (vyhláška o kybernetické bezpečnosti).

2. Správa systému – Správa bude prováděna výhradně z technologické části interní datové sítě Objednatele.

3. Podpora šifrování komunikace – Systém v rámci řešení musí podporovat šifrování komunikace mezi jeho komponentami, a to minimálně na úrovni doporučení v oblasti kryptografických prostředků Národního úřadu pro kybernetickou a informační bezpečnost (NÚKIB).

4. Bezpečnost OS – "Všechny operační systémy použité v rámci řešení musí být certifikovány dle CC EAL 4 a výše (Common Criteria, resp. ISO/IEC 15408-1:2009, resp. aktuální verze). Dále musí být podporovány jejich výrobcem po dobu alespoň 5 let od integrace do prostředí Objednatele."

5. Zaznamenání činnosti uživatelů a administrátorů – "Nástroj musí umožňovat zaznamenávání činností informační infrastruktury, resp. informačních systémů, jejich uživatelů a administrátorů, který zajistí sběr informací o provozních a bezpečnostních činnostech, zejména:

• typ činnosti,

• datum a čas (SEČ/SELČ),

• identifikaci technického aktiva, které činnost zaznamenalo,

• identifikaci původce a

• identifikace místa činnosti (IP adresa),

• úspěšnost nebo neúspěšnost činnosti a

• zajistit ochranu získaných informací před neoprávněným čtením nebo změnou."

6. Rozsah zaznamenání činností – "Zaznamenáváno bude:

• přihlašování a odhlašování ke všem účtům, a to včetně neúspěšných pokusů,

• činnosti provedené administrátory,

• úspěšné i neúspěšné manipulace s účty, oprávněními a právy,

• neprovedení činností v důsledku nedostatku přístupových práv a oprávnění,

• činnosti uživatelů, které mohou mít vliv na bezpečnost informačního a komunikačního systému,

• zahájení a ukončení činností technických aktiv, kritických i chybových hlášení technických aktiv a přístupů k záznamům o událostech,

• pokusy o manipulaci se záznamy o událostech a změny nastavení nástrojů pro zaznamenávání událostí."

7. Minimální doba uložení zaznamenaných činností – Minimální doba uložení zaznamenaných činností je 48 měsíců.

8. Prostředí koncového uživatele, požadavky na prohlížeč – Řešení využívající jako uživatelské rozhraní webovou aplikaci musí být navrženo tak, aby ke své plné funkčnosti nevyžadovalo žádné doplňky prohlížeče (zejména nesmí používat Adobe Flash).

4. Minimální požadované atributy pro osamostatňované entity

V souladu s nezávislým standardem IT4IT (The Open Group IT4IT™ Reference Architecture) požadujeme, v rámci procesního upgrade podporovat všechny standardem doporučené atributy.

5. Mainentance a technická podpora podle odst. 2.2.4 Smlouvy zahrnuje:

1. přístup k technické podpoře to prostřednictvím WEB aplikace dostupné pro objednatele v režimu 24x7 na adrese: xxxxx://xxx.xxxxxxxxxx.xxx/xxxxxxx/xxxxxxxxx/, která umožní stahování opravných balíčků.

2. Možnost hlášení incidentů/nestandardů prostřednictvím servisního portálu na adrese xxxxx://xxx.xxxxxxxxxx.xxx/xxxxxxx/xxxxx/, a to on-line v režimu 24x7 a jejich řešení v režimu 9x5 (tedy v pracovní dny 08:00 – 17:00).

3. Zajištění úrovně podpory v režimu 9x5 (tedy v pracovní dny 08:00 – 17:00) s garancí evidence zaslaných případů.

4. Reakční doby pro zahájení řešení případů v níže uvedených časech v závislosti na kritičnosti požadavku. Reakční dobou se rozumí čas od nahlášení případu na servisní portál do doby potvrzení přijetí ze strany Dodavatele, přičemž do této doby se nezapočítává mimopracovní doba (tj. doba mimo rámec uvedený v předešlém bodě. Součástí řešení je i komunikace mezi Dodavatelem a Objednatelem, vedoucí k rychlejšímu řešení

Režim podpory	Kritičnost 1	Kritičnost 2	Kritičnost 3	Kritičnost 4
9x5	2hod	6hod	8hod	1den

Definice kritičnosti:

Kritičnost 1 systém je mimo provoz, produkt není použitelný. To vede ke kompletnímu narušení práce. Zároveň není k dispozici žádné náhradní řešení

Kritičnost 2 provoz je vážně omezen, je k dispozici náhradní řešení

Kritičnost 3 produkt nefunguje dle specifikace, problém má nižší dopad na fungování a je nasazeno náhradní řešení

Kritičnost 4 úroveň dopadu nestandardní situace je malá, problém lze klasifikovat jako žádost o dokumentaci, obecnou podporu nebo jde o žádost o vylepšení

Helpdesk zadávání ticketů:

Webové rozhraní: xxx

Emailové rozhraní: xxx

Telefonický kontakt: xxx

Příloha č. 2 - Cena plnění

Cena za Upgrade	Cena bez DPH
Úvodní projektová dokumentace včetně metodiky dle odst. 2.2.1 Smlouvy	xxx
Konfigurace a parametrizace dle odst. 2.2.2 Smlouvy	xxxx
Představení SW dle odst. 2.2.3 Smlouvy	xxx

Příloha č. 3 - Realizační tým

Pracovní pozice v realizačním týmu	Jméno a příjmení
Projektový manažer	xxx
Architekt	xxx
Procesní konzultant	xxx
Konzultant	xxx
Specialista	xxx
Specialista	xxx
Specialista	xxx
Specialista	xxx
Specialista	xxx
Specialista	xxx
Specialista	xxx
Specialista	xxx

Příloha č. 4 - Smlouvy Protokol o předání a převzetí – Akceptační protokol

Akceptační protokol o předání a převzetí

níže specifikované části předmětu Smlouvy

Název:

Popis:

Splnění akceptačních kritérií

Kritérium Splnění kritéria

Výsledek akceptace: AKCEPTOVÁNO BEZ VÝHRAD / AKCEPTOVÁNO S VÝHRADAMI / NEAKCEPTOVÁNO

Připomínky, výhrady, závady:

Předáno dne:

	Předal / Převzal	Role na projektu, funkce	Podpis
Za Dodavatele
Za Objednatele

Příloha č. 5 - Tabulka technických požadavků

(přiložený soubor v excelu)

Příloha č. 6 - Report o Vadě

Žadatel vyplní silně orámovanou část

Problém vyřešen:

ANO / NE

Přijal:

Přijato (datum a čas):

Potvrzeno (datum a čas):

Evidenční číslo:

Zákazník: Projekt:

Jméno žadatele:

Xxxxx Xxxxxxx: Evidenční číslo žádanky:

Místo:

Telefon:

Fax: Mail:

Datum a čas zjištění:

Je vada opakovatelná?

ANO/NE

Prohlížeč:

NN IE

Uživatel (role):

Označte

X

Popis požadavku:

Stav:

S

A

1

B

2

C

3

Běžný

4

5

Věc:

V

Vada

1

Nový požadavek

2

Změna

3

Dotaz

4

Služba

5

6

Lokalizace:

L

HW

1

OS

2

Síť

3

Databáze

4

Aplikace

5

6

Rozhraní

7

8

Jméno řešitele:

Datum:

Informace o stavu vyřizování

Přijal:

Odeslal:

dne:

dne:

Přílohy řešitele:

Strana 52 (celkem 52)