Smlouva o dodání, implementaci a podpoře Konzultačního servisu IROP II

Smlouva o dodání, implementaci a podpoře Konzultačního servisu IROP II

uzavřená podle § 2586 a násl. zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších právních předpisů a 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ů (autorský zákon), ve znění pozdějších předpisů (dále jen „autorský zákon“) (dále jen: „Smlouva“)

Čl. 1. Smluvní strany

Objednatel: Centrum pro regionální rozvoj České republiky

se sídlem: U Nákladového nádraží 3144/4, 130 00 Praha 3

IČO: 04095316

zastoupen: Ing. Xxxxxxx Xxxxxxx, generálním ředitelem

zástupce pro věci technické: Xxx. Xxxxxxx Xxxxxx, ředitel odboru řízení administrace programů Telefon, e-mailové spojení:

(dále jen „objednatel“ nebo „smluvní strana“, v rámci příloh této Smlouvy rovně „zadavatel“ nebo

„CRR“)

a

Zhotovitel: InQool, a.s.

se sídlem: Svatopetrská 35/7, 617 00 Brno, Komárov

IČO: 29222389

DIČ: CZ29222389

Zapsán v obchodním rejstříku vedeném Krajským soudem v Brně, spisová značka B 6125 Zastoupen: Xxx. Xxxxx Xxxxx, předseda představenstva, v plné moci

Bankovní spojení: Komerční banka a.s., č. ú.:

zástupce pro věci technické:

Telefon, e-mailové spojení:

Adresa pro elektronické doručování korespondence smluvních stran: xxxx@xxxxxx.xx nebo datová schránka m5cre4f

(dále jen „zhotovitel“ nebo „smluvní strana“, rámci příloh této Smlouvy rovně „dodavatel“)

Čl. 2. Úvodní ustanovení a účel Smlouvy

2.1. Smluvní strany uzavřely tuto Smlouvu na základě výsledků zadávacího řízení na nadlimitní veřejnou zakázku s názvem „Konzultační servis IROP II“ (dále také „zadávací řízení“ a/nebo „veřejná zakázka“). Účelem této Smlouvy je prostřednictvím plnění specifikovaného dále v čl. 3 a Přílohách č. 1 až č. 5 této Smlouvy zajistit dodání, implementaci a následnou podporu provozu nového informačního systému – Konzultačního servisu IROP II v organizaci objednatele (dále také jen „Dílo“).

2.2. Xxxxxxxxxx bere na vědomí, že předmět Xxxxxxx je spolufinancován z finančních prostředků Evropské unie, prostřednictvím Integrovaného regionálního operačního programu (dále jen „IROP“), název a číslo projektu budou zhotoviteli objednatelem oznámeny, jakmile tyto budou stanoveny (dále

„Projekt“).

Čl. 3. Předmět Smlouvy – Předmět Díla

3.1. Zhotovitel se touto Smlouvou zavazuje, že pro objednatele zhotoví, dodá a do systémové infrastruktury objednatele implementuje komplexní informační systém Konzultační servis IROP II, který bude plně v souladu s podmínkami této Smlouvy (dále také jen „Systém“).

3.2. Systém musí splňovat veškeré věcné a funkční požadavky, které jsou podrobně specifikovány v Příloze č. 1 této Smlouvy – Věcný popis Konzultačního servisu – business plán, v Příloze č. 2 této Smlouvy - Technická specifikace Konzultačního servisu a v Příloze č. 3 této Smlouvy – Minimální požadavky na strukturu a dostupnost informací z Konzultačního servisu na webu CRR, s nimiž se zhotovitel seznámil již ve fázi zadávacího řízení na veřejnou zakázku, a které podáním nabídky na veřejnou zakázku akceptoval, a dále v Příloze č. 5 této Smlouvy – Technické řešení Konzultačního servisu, která je tvořena technickou částí nabídky zhotovitele na veřejnou zakázku. Zhotovitel podpisem této Smlouvy potvrzuje, že jím na základě této Xxxxxxx dodávaný Systém veškerým funkčním požadavkům obsaženým v Přílohách č. 1, 2, 3 a 5 této Smlouvy vyhovuje. Pro případ rozporů mezi Přílohami č. 1 až 3 na straně jedné a Přílohou č. 5 na straně druhé smluvní strany sjednávají, že přednost mají a pro plnění předmětu této Smlouvy se použijí podmínky stanovené v Přílohách č. 1 až 3 této Smlouvy.

3.3. Systém bude pracovat v českém jazyce.

3.4. Součástí Díla je dále servis a podpora Systému (dále také jen „Podpora“), jejíž bližší specifikace je uvedena Příloze č. 4 této Smlouvy.

3.5. Smluvní strany činí nesporným, že součástí předmětu Díla jsou i veškeré další v této Smlouvě výslovně nespecifikované dodávky a služby zhotovitele nezbytné k naplnění účelu této smlouvy, tedy zejména k tomu, aby objednatel mohl ve lhůtě stanovené v čl. 4.1.4. této Smlouvy začít využívat plně funkční Systém v souladu s touto Smlouvou. Dalšími dodávkami ve smyslu tohoto článku této Smlouvy jsou například i softwary či softwarové licence k programům třetích osob, jejichž využití je nezbytné k plné funkčnosti Systému v souladu s touto Smlouvou po neomezenou dobu.

Čl. 4. Lhůty a místo plnění

4.1. Zhotovitel se zavazuje, že uskuteční plnění předmětu této Smlouvy v následujících termínech:

4.1.1. zpracování a dodání detailní analýzy a technického projektu Systému, vycházejících z nabídky zhotovitele na veřejnou zakázku (dále také souhrnně „Analýza“) nejpozději do 30 kalendářních dnů od nabytí účinnosti této Smlouvy;

4.1.2. dodání finální podoby Analýzy s vypořádanými připomínkami objednatele nejpozději do 10 kalendářních dnů od obdržení připomínek objednatele k Analýze dodané v souladu s čl. 4.1.1. této Smlouvy;

4.1.3. dodání Systému, dodání souvisejícího SW a SW licencí a zahájení jeho testovacího, resp. pilotního provozu nejpozději do 5 měsíců od nabytí účinnosti této Smlouvy;

4.1.4. ukončení testovacího, resp. pilotního provozu Systému, ukončení implementace Systému, dodání veškeré dokumentace k systému (viz Příloha č. 2 této Smlouvy), proškolení administrátorů a uživatelů Systému (viz Příloha č. 2 této Smlouvy) a spuštění ostrého provozu Systému nejpozději do 4 měsíců od zahájení testovacího, resp. pilotního provozu Systému, přičemž pokud by tato lhůta měla uplynout před 1. 1. 2021, rozumí se požadovaným termínem dle tohoto článku právě 1. 1. 2021;

4.1.5. zahájení poskytování Podpory Systému ode dne uvedení Systému do ostrého provozu.

4.2. Jako místo plnění se sjednává sídlo objednatele v budově na adrese X Xxxxxxxxxxx xxxxxxx 0000/0, Xxxxx 0.

Čl. 5. Cena

5.1. Cena díla je stanovena následovně:

5.1.1. Cena za kompletní Analýzu v úplném rozsahu dle této Smlouvy, včetně vypořádání připomínek k Analýze, činí 112.000,- Kč bez DPH, k tomu DPH ve výši 21 % činí 23.520,- Kč, celkem 135.520,- Kč včetně DPH.

5.1.2. Cena za kompletní Systém vč. jeho implementace, v úplném rozsahu dle této Smlouvy, činí 800.000,- Kč bez DPH, k tomu DPH ve výši 21 % činí 168.000,- Kč, celkem 968.000,- Kč včetně DPH.

5.1.3. Cena za související software a softwarové licence dle této Smlouvy, činí souhrnně 0,- Kč bez DPH, k tomu DPH ve výši 21 % činí 0,- Kč, celkem 0,- Kč včetně DPH.

5.1.4. Cena za realizaci testovacího resp. pilotního provozu Systému v souladu s touto Smlouvou činí 90.000,- Kč bez DPH, k tomu DPH ve výši 21 % činí 18.900,- Kč, celkem 108.900,- Kč včetně DPH.

5.1.5. Cena za zpracování veškeré dokumentace dle této Smlouvy činí 40.000,- Kč bez DPH, k tomu DPH ve výši 21 % činí 8.400,- Kč, celkem 48.400,- Kč včetně DPH.

5.1.6. Cena za realizaci veškerých školení dle této Smlouvy činí 35.777,- Kč bez DPH, k tomu DPH ve výši 21 % činí 7.513,17 Kč, celkem 43.290,17 Kč včetně DPH.

5.1.7. Cena za kompletní Podporu v plném rozsahu dle této Smlouvy, činí za jeden kalendářní měsíc (měsíční paušál) 25.000,- Kč bez DPH, k tomu DPH ve výši 21 % činí 5.250,- Kč, celkem 30.250,- Kč včetně DPH.

5.2. Cena díla (kterákoliv z dílčích cen dle čl. 5.1. této Smlouvy) je sjednána jako nejvýše přípustná, zahrnující veškeré náklady (na dodávky i služby, poplatky i jakékoliv další platby) souvisejících s plněním předmětu Díla. Cenu (kteroukoliv z cen dle čl. 5.1. této Smlouvy) je možné překročit pouze v souvislosti se změnou daňových předpisů týkající se DPH, a to nejvýše o částku odpovídající této legislativní změně. Zhotovitel přebírá ve smyslu § 2620 odst. 2, resp. § 1765 odst. 2 občanského zákoníku nebezpečí změny okolností.

Čl. 6. Platební podmínky

6.1. Zaplacení ceny dle čl. 5.1.1., 5.1.3., 5.1.4., 5.1.5. a 5.1.6. této Smlouvy bude provedeno bezhotovostně vždy po řádném a úplném dokončení příslušných činností a uskutečnění plnění, za které je příslušná cena placena a předání odpovídajících výstupů dle této Smlouvy, a to na základě zhotovitelem vystaveného daňového dokladu (faktury), doručeného objednateli. Objednatel neposkytuje zálohy.

6.2. Zaplacení ceny dle čl. 5.1.2. této Smlouvy bude provedeno bezhotovostně po akceptaci a převzetí funkčního Systému do ostrého provozu, s přihlédnutím k podmínkám v čl. 9 této Smlouvy stanoveným, na základě zhotovitelem vystaveného daňového dokladu (faktury), doručeného objednateli. Objednatel neposkytuje zálohy.

6.3. Úhrada ceny za Podporu (dle čl. 5.1.7. této Smlouvy) bude prováděna bezhotovostně měsíčně zpětně na základě zhotovitelem vystaveného daňového dokladu (faktury), doručeného objednateli po skončení kalendářního měsíce, ve kterém byla Podpora v rozsahu a v souladu s touto Smlouvou řádně poskytována.

6.4. Zhotovitel doručí každý daňový doklad (fakturu) objednateli ve dvou výtiscích. Zhotovitel doručí daňový doklad (fakturu) na adresu objednatele uvedenou v záhlaví této Smlouvy, případně elektronicky na adresu xxxxxxxxx@xxx.xx. Objednatel zaplatí dle daňového dokladu (faktury) do třiceti

(30) kalendářních dnů ode dne jeho prokazatelného obdržení. Za den splnění platební povinnosti se považuje den odepsání placené částky (kupní ceny) z bankovního účtu objednatele.

6.5. Daňový doklad (faktura) musí obsahovat všechny náležitosti stanovené zákonem č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších právních předpisů, odkaz na tuto Smlouvu, odkaz na Projekt dle čl. 2.2. této Smlouvy (text „IROP“ a název a registrační číslo Projektu). Součástí daňového dokladu (faktury) vystaveného dle čl. 6.1. resp. 6.2. této Smlouvy, jako jeho příloha, bude předávací

protokol podepsaný při předání (dokončení – splnění) příslušného plnění, osobou oprávněnou jednat za objednatele ve věcech technických, případně jiným zástupcem objednatele pro tento účel zmocněným.

6.6. Objednatel je oprávněn před uplynutím lhůty splatnosti vrátit daňový doklad (fakturu), který neobsahuje požadované náležitosti, nebo není doložen požadovanými a úplnými doklady, nebo obsahuje nesprávné údaje.

6.7. V případě vrácení daňového dokladu (faktury) objednatel písemně sdělí důvod vrácení daňového dokladu (faktury). Po vrácení daňového dokladu (faktury) objednatelem je zhotovitel povinen vystavit a doručit objednateli nový daňový doklad (fakturu) s tím, že vrácením daňového dokladu (faktury) lhůta splatnosti vráceného daňového dokladu (faktury) zaniká. Nová lhůta splatnosti dle nového daňového dokladu (faktury) v délce dle odst. 6.4. této Smlouvy začne běžet po dni prokazatelného doručení řádného daňového dokladu (faktury) mající všechny náležitosti stanovené touto Smlouvou.

6.8. V případě, že v průběhu plnění této Smlouvy dojde ke změně registrace k dani z přidané hodnoty zhotovitele, je zhotovitel povinen nejpozději do 3 (tří) kalendářních dnů písemně informovat objednatele o změně registrace k dani z přidané hodnoty (tj. informovat o zrušení registrace k dani z přidané hodnoty, nebo o podání přihlášky k registraci).

Čl. 7. Licenční ujednání

7.1. Zhotovitel uděluje objednateli právo užívat Systém a ostatní softwarové produkty třetích stran (dále též „licence“) v souladu s jeho určením dle této Smlouvy a za podmínek této Smlouvy. Zhotovitel poskytuje objednateli tyto licence jako nevýhradní, časově neomezené a teritoriálně omezené na území České republiky, resp. na území států Evropské unie.

7.2. Povinnost týkající se poskytnutí licence v rozsahu podle předchozího odstavce platí pro zhotovitele i v případě zhotovení části Systému poddodavatelem.

7.3. Zhotovitel garantuje, že poskytuje počet licencí tak, aby nebyla narušena práce všech uživatelů (pracovníků) objednatele v rozsahu definovaném v Přílohách této Smlouvy. Pokud by se v době po dodání Systému ukázalo, že počet licencí není dostatečný a působí problémy při jeho provozování, rozšíří zhotovitel bezodkladně na vlastní náklady jejich počet na množství nezbytné pro řádný a plynulý provoz Systému v souladu s touto Smlouvou.

7.4. Zhotovitel garantuje, že veškeré jím dodávané nebo poskytované licence jsou v rozsahu nezbytném pro testovací a následně i pro ostrý (rutinní) provoz po neomezenou dobu.

7.5. Zhotovitel se zavazuje, že výsledkem jeho plnění nebo jakékoli jeho části nebudou porušena práva třetích osob. Pro případ, že užíváním Systému nebo jeho dílčí části nebo prostou existencí Systému nebo jeho dílčí části budou v důsledku porušení povinností či nepravdivostí prohlášení zhotovitele dotčena práva třetích osob, nese zhotovitel vedle odpovědnosti za takovéto vady plnění i odpovědnost za veškeré škody, které tím objednateli vzniknou.

7.6. Zhotovitel je povinen objednateli uhradit jakékoli majetkové a nemajetkové újmy vzniklé v důsledku toho, že objednatel nemohl předmět plnění užívat řádně a nerušeně. S nositeli chráněných práv duševního vlastnictví vzniklých v souvislosti s realizací plnění podle této Smlouvy je zhotovitel povinen vždy smluvně zajistit možnost nakládání s těmito právy objednatelem v rozsahu definovaném tímto článkem Smlouvy.

7.7. Zhotovitel výslovně prohlašuje, že je plně oprávněn disponovat právy k duševnímu vlastnictví, včetně práv autorských zahrnutých v předmětu plnění, a zavazuje se za tímto účelem zajistit řádné a nerušené užívání Díla objednatelem, včetně zajištění souhlasů autorů děl v souladu s autorským zákonem.

7.8. Licence poskytnutá podle této Smlouvy se vztahuje i na veškeré poskytnuté aktualizace (tj. update / upgrade / patch / hotfix atd.) Systému.

7.9. Objednatel není povinen kterékoliv licence využít.

7.10. Objednatel je v souladu s touto Smlouvou oprávněn provádět sám nebo prostřednictvím třetí osoby změny, úpravy a doplnění Systému, resp. tyto operace v dodaných oddělitelných doprogramovaných částech Systému a její dokumentaci, a to po ukončení poskytování Podpory.

Bude-li k tomu zapotřebí poskytnutí přístupových údajů k Systému (např. zdrojové kódy apod.), zavazuje se zhotovitel k jejich bezplatnému předání objednateli, a to nejpozději do 10 kalendářních dnů od výzvy k jejich poskytnutí ze strany objednatele. Objednatel je v takovém případě oprávněn tyto přístupové údaje a kódy použít výlučně k účelu vymezenému v tomto odstavci a pouze pro potřeby své organizace.

7.11. Dnem zahájení ostrého (rutinního) provozu (viz čl. 4.1.4. této Smlouvy) se objednatel stává nabyvatelem licence (licencí) v souladu s tímto článkem Smlouvy a tím má právo systém rutinně používat; k témuž datu přechází vlastnictví ke hmotnému nosiči dat, na němž je zaznamenán počítačový program (je-li relevantní).

7.12. Udělení veškerých práv uvedených tímto článkem smlouvy nelze ze strany Zhotovitele vypovědět a rovněž tak na udělení takových práv nemá vliv ukončení platnosti této smlouvy.

Čl. 8. Další práva a povinnosti smluvních stran

8.1. Zhotovitel je povinen udržovat převzatá pracoviště pro plnění Díla v prostorách objednatele (bude- li jeho přítomnost na místě u objednatele relevantní) v trvale dobrém stavu, průběžně odstraňovat všechny odpady a dodržovat bezpečnostní a požární předpisy.

8.2. Zhotovitel je ve smyslu ustanovení § 2 písm. e) zákona č. 320/2001 Sb., o finanční kontrole ve veřejné správě a o změně některých zákonů (zákon o finanční kontrole), ve znění pozdějších předpisů (dále „ZFK“), osobou povinnou spolupůsobit při výkonu finanční kontroly prováděné v souvislosti s úhradou zboží nebo služeb z veřejných výdajů nebo z veřejné finanční podpory, tj. zhotovitel je povinen podle § 13 ZFK poskytnout požadované informace a dokumentaci kontrolním orgánům (Řídicímu orgánu Integrovaného regionálního operačního programu Ministerstva pro místní rozvoj ČR, Ministerstvu financí ČR, Evropské komisi, Evropskému účetnímu dvoru, Evropskému úřadu pro boj proti podvodům, Nejvyššímu kontrolnímu úřadu, příslušnému finančnímu úřadu a dalším oprávněným orgánům) a vytvořit kontrolním orgánům podmínky k provedení kontroly vztahující se k předmětné veřejné zakázce a poskytnout jim součinnost.

8.3. Zhotovitel je povinen uchovávat veškeré originální dokumenty související s realizací veřejné zakázky po dobu uvedenou v závazných právních předpisech upravujících oblast zadávání veřejných zakázek, nejméně však po dobu 10 let od finančního ukončení projektu, zároveň minimálně do roku 2030. Po tuto dobu je zhotovitel povinen umožnit osobám oprávněným k výkonu kontroly projektů provést kontrolu dokladů souvisejících s realizací veřejné zakázky.

8.4. Zhotovitel není oprávněn převést jako postupitel svá práva a povinnosti z této Smlouvy nebo její část na třetí osobu ani jednostranně započítat svoje pohledávky proti pohledávkám objednatele.

8.5. Zhotovitel je povinen vést veškerou komunikaci v souvislosti s plněním předmětu této Smlouvy, jakož i předat veškeré písemné výstupy vyhotovené v rámci plnění předmětu této Smlouvy, výlučně v českém jazyce, nedohodnou-li se objednatel se zhotovitelem ohledně dílčích výstupů či dokumentů výslovně jinak. V případě dokumentace poskytnuté zhotoviteli třetími stranami, vyhotovené v cizím jazyce, je zhotovitel povinen zajistit její překlad do českého jazyka.

8.6. Zhotovitel se zavazuje realizovat veškeré práce vyžadující zvláštní způsobilost nebo povolení podle příslušných právních či technických předpisů osobami, které tuto podmínku splňují.

8.7. Zhotovitel se dále zavazuje, že plnění předmětu této Smlouvy, konkrétně v oblasti Analýzy, Implementace a Podpory, zajistí prostřednictvím realizačního týmu, který bude složen z osob, jejichž prostřednictvím zhotovitel prokazoval v rámci zadávacího řízení na veřejnou zakázku technickou kvalifikaci ve smyslu čl. 4.3.2. zadávací dokumentace na veřejnou zakázku, tedy tým ve složení:

- projektový manažer:

- architekt řešení:

- databázový specialista:

- programátor:

- bezpečnostní specialista:

Změna člena realizačního týmu je možná jen po předchozím písemném souhlasu objednatele, a to v případě, že člen týmu bude nahrazen osobou, která splňuje minimálně kvalifikační předpoklady dle čl. 4.3.2. zadávací dokumentace na veřejnou zakázku ve vztahu k příslušné pozici. V takovém případě není objednatel oprávněn bezdůvodně nahrazení člena realizačního týmu odmítnout.

8.8. Zhotovitel je povinen postupovat při plnění předmětu této Xxxxxxx s odbornou péčí, podle nejlepších znalostí a schopností, sledovat a chránit oprávněné zájmy objednatele a postupovat v souladu s jeho pokyny a interními předpisy souvisejícími s předmětem plnění této Smlouvy (či její dílčí části), které objednatel zhotoviteli poskytne nebo s pokyny jím pověřených osob.

8.9. Zhotovitel je povinen mít po celou dobu trvání Smlouvy uzavřenou a účinnou pojistnou smlouvu, jejímž předmětem je pojištění odpovědnosti za škodu způsobenou zhotovitelem třetí osobě v souvislosti s výkonem činnosti, která je předmětem této Smlouvy, a to ve výši nejméně 2 000 000 Kč (slovy: dva miliony korun českých). Do pěti (5) pracovních dnů od výzvy objednatele je zhotovitel povinen Objednateli prokázat, že má pojistnou smlouvu uzavřenou za podmínek uvedených v tomto odstavci.

8.10. Zjistí-li zhotovitel při plnění předmětu Xxxxxxx skryté překážky bránící řádnému provedení předmětu plnění, je povinen to bez odkladu oznámit objednateli a navrhnout mu další postup.

8.11. Zjistí-li zhotovitel při plnění předmětu Smlouvy, že podklady či pokyny předané mu za účelem jejich využití při plnění předmětu Smlouvy objednatelem nejsou vhodné či jsou vadné, je povinen na tuto skutečnost objednatele upozornit a navrhnout řešení, kterým je možné dosáhnout stejného či obdobného výsledku při současném zabránění vzniku škod. To neplatí pro podklady, na jejichž základě zhotovitel zpracoval a podal svojí nabídku na plnění veřejné zakázky v rámci zadávacího řízení; tyto podklady zhotovitel posoudil a shledal je vyhovujícími pro naplnění účelu této Smlouvy.

8.12. Zhotovitel se zavazuje respektovat pracovní dobu objednatele, a to zejména v případech, kdy je nezbytná součinnost pracovníků objednatele v rámci realizace úkolu zhotovitele. Případné lhůty stanovené pro součinnost objednatele běží pouze v příslušné pracovní době. Pro účely plnění dle této Smlouvy se za pracovní dobu na straně objednatele považuje doba v pracovních dnech od 8:30 do 16:00 hodin.

8.13. Objednatel je povinen v průběhu provádění díla poskytovat zhotoviteli nezbytnou součinnost odpovídající povaze a rozsahu předmětu Díla, zejména umožnit zhotoviteli či jeho pracovníkům vstup do objektů objednatele, poskytnout jim potřebné informace a přístupové údaje nezbytné ke splnění předmětu Díla a zajistit účast odpovědných osob v rámci Akceptačního a předávacího řízení.

8.14. Objednatel je povinen seznámit zhotovitele před zahájením plnění předmětu Díla s vnitřními předpisy objednatele relevantními z hlediska předmětu Díla.

Čl. 9. Předání Díla, Akceptační řízení

9.1. Předání Systému do ostrého (rutinního) provozu proběhne po ukončení Implementace, v termínu sjednaném v čl. 4.1.4. této Smlouvy, a to na základě výzvy učiněné písemně zhotovitelem vůči objednateli neméně 5 pracovních dní před zahájením předávacího řízení.

9.2. Výzva k uskutečnění předání a převzetí hotového Systému dle předchozího odstavce bude zhotovitelem učiněna vůči zástupci objednatele pro věci technické na e-mailovou adresu uvedenou v čl. 1 této Smlouvy.

9.3. Předání a převzetí Systému bude provedeno na základě oboustranně podepsaného předávacího protokolu, ve kterém budou zachyceny přinejmenším tyto předpoklady pro uskutečnění předání a převzetí Systému:

9.3.1. informace o dodání Systému – identifikace SW, identifikace, vč. množstevní specifikace, licencí (včetně případných licencí k SW třetích stran) v potřebném počtu dle čl. 7 této Smlouvy (tím do budoucna nebudou dotčeny povinnosti zhotovitele stanovené v čl. 7.3. této Smlouvy);

9.3.2. informace o provedení Analýzy a ukončení Implementace Systému;

9.3.3. informace o výsledku testování a pilotního provozu uskutečněných dle této Smlouvy;

9.3.4. informace a výčet předané dokumentace dle této Smlouvy;

9.3.5. informace o rozsahu a výsledcích školení realizovaných dle této Smlouvy,

9.3.6. informace o výsledcích Akceptačního řízení dle čl. 9.4. této Smlouvy; akceptační protokol se závěrem „AKCEPTOVÁNO BEZ VÝHRAD“, nebo „AKCEPTOVÁNO S VÝHRADAMI“ bude přílohou předávacího protokolu.

9.4. Před zahájením předávacího řízení, na závěr testovacího, resp. pilotního provozu Systému a jako podmínka pro zahájení předávacího řízení, proběhne tzv. Akceptační řízení, v jehož rámci bude provedena kontrola funkčnosti všech funkcionalit a vlastností Systému v souladu s jeho specifikací uvedenou v Přílohách č. 1 a č. 2 této Smlouvy. Výsledkem akceptačního řízení bude protokol obsahující jeden z těchto závěrů:

9.4.1. Akceptováno bez výhrad. V případě, že objednatel v průběhu akceptačního řízení nenalezne v předaném plnění žádné vady ani nedodělky, uvede objednatel do protokolu, že předané plnění bylo akceptováno bez výhrad a akceptační protokol potvrdí svým podpisem.

9.4.2. Akceptováno s výhradami. V případě, že budou v průběhu akceptačního řízení zjištěny v předaném plnění vady nebo nedodělky nebránící dalšímu užití Díla, dohodnou se objednatel a zhotovitel na termínu, do kterého zhotovitel zjištěné vady a nedodělky odstraní. Zhotovitel ve spolupráci s objednatelem do akceptačního protokolu uvede seznam vad nebo nedodělků s klasifikací závažnosti a s termíny jejich odstranění. V akceptačním protokolu se uvede, že předané plnění bylo akceptováno s uvedenými výhradami a obě smluvní strany protokol potvrdí svým podpisem. Odstranění zjištěných nedostatků bude ověřeno opětovným testováním a výsledek bude zaznamenán formou samostatného zápisu v protokolu o vyřešení výhrad z akceptace.

9.4.3. Neakceptováno. V případě, že budou v průběhu akceptačního řízení v předaném plnění zjištěny takové vady a nedodělky, které by bránily v užití díla či jeho části, není předané plnění akceptováno. Obě smluvní strany se dohodnou na termínech nového předání a nového akceptačního řízení; tím není dotčen čl. 4.1.4. této Smlouvy. Do protokolu objednatel uvede, že předané plnění nebylo akceptováno, dohodnuté termíny nového akceptačního řízení a obě smluvní strany protokol potvrdí svým podpisem.

9.5. Pokud je akceptační řízení ukončeno s výsledkem „Akceptováno s výhradami“, je objednatel oprávněn stanovit zádržné části fakturace dle čl. 6.2. této Smlouvy, které bude vázáno na vyřešení všech výhrad z akceptace dle odsouhlasených postupů a termínů (dále jen „Doplatek“), a to ve výši 20 % ze Smlouvou předpokládané výše fakturace dle čl. 6.2. této Smlouvy. Doplatek je zhotovitel oprávněn fakturovat až po podpisu akceptačního protokolu o vyřešení všech výhrad z akceptace dle odsouhlasených postupů a termínů.

9.6. Akceptační a předávací protokol vyhovující požadavkům této Smlouvy připraví pro účely Akceptačního a předávacího řízení zhotovitel.

9.7. Výzvu k zahájení Akceptačního a/nebo předávacího řízení učiní zhotovitel na vlastní odpovědnost tak, aby tato proběhla (byla ukončena) v souladu s požadovanými termíny plnění dle čl. 4.1.4. této Smlouvy.

Čl. 10. Podpora Systému

10.1. Zhotovitel se zavazuje provádět Podporu provozu Systému od okamžiku uvedení Systému do ostrého (rutinního) provozu.

10.2. Podpora Systému bude realizována zhotovitelem v souladu s podmínkami a požadavky obsaženými v Příloze č. 4 této Smlouvy.

10.3. Součástí Podpory Systému bude rovněž zálohování, jak je toto popsáno v Příloze č. 2 této Smlouvy.

10.4. Pro účely komunikace objednatele, resp. jeho pracovníků se zhotovitelem ve věcech realizace Podpory Systému je zhotovitel povinen zřídit a provozovat help-desk, který se bude dostupný na níže uvedených kontaktech

gsm: x000 000 000 000; tel.: x000 000 000 000; e-mail: xxxxxxxx@xxxxxx.xx

Čl. 11. Odpovědnost za vady, záruka za jakost

11.1. Dílo má vady, pokud nemá vlastnosti, které stanoví Smlouva, nebo existují vady v dokladech a dokumentech nebo Dílo má právní vady. Zárukou za jakost se zhotovitel zavazuje, že Dílo bude po dobu záruční doby způsobilé k použití pro účel a za podmínek dle této Smlouvy, jinak pro obvyklý účel, a zachová si vlastnosti a parametry vymezené touto Smlouvou.

11.2. Zhotovitel odpovídá za vady, jež má Dílo v době převzetí Systému objednatelem a vady, které se projeví v záruční době. Za vady Díla, které se projeví po záruční době, odpovídá jen tehdy, pokud jejich příčinou bylo prokazatelně jeho porušení povinností.

11.3. Záruční doba se sjednává na dobu dvacet čtyři (24) měsíců. Pokud je u některých součástí plnění (SW třetích stran apod.) stanovena záruční doba delší, platí ohledně těchto částí Díla tato záruční doba delší.

11.4. Záruční doba počíná běžet dnem následujícím po předání kompletního Systému dle čl. 9 této Smlouvy; jestliže však objednatel převzal dílo s vadami či nedodělky, které nebrání užívání Systému, počíná záruční doba běžet dnem následujícím po odstranění poslední z vad či nedodělků uvedených v předávacím protokolu.

11.5. Objednatel uplatní práva z vadného plnění písemným oznámením vady učiněným na help-desk dle čl. 10.4. této Smlouvy. Oznámení vady bude obsahovat popis vady nebo způsob, jakým se vada projevuje, a uplatnění nároku z vadného plnění / záruky.

11.6. V případě, že objednatel uplatní nárok z vadného plnění nebo ze záruky na odstranění vady, je zhotovitel povinen bezplatně odstranit vady způsobem a v režimu, jak je tento uveden v čl. 2.3. Přílohy č. 4 této Smlouvy (režim SLA). Zhotovitel je povinen zahájit a realizovat odstranění uplatněného nároku z vadného plnění i v případě, že nárok neuznává.

11.7. Smluvní strany se dohodly, že po dobu odstraňování reklamovaných vad Díla záruční doba neběží. Na provedenou opravu poskytne zhotovitel záruku za jakost ve stejné délce dle odstavce

11.3. této Smlouvy.

Čl. 12. Smluvní pokuty

12.1. Za prodlení zhotovitele se splněním kteréhokoliv z termínů dle čl. 4.1. této Smlouvy, je zhotovitel povinen zaplatit objednateli za každý, byť započatý den prodlení, smluvní pokutu ve výši 0,2 % z ceny plnění (dle čl. 5.1. této Smlouvy) s nímž se dostal do prodlení, a to až do odstranění prodlení.

12.2. Za prodlení objednatele s úhradou ceny za Dílo, resp. kterékoliv faktury řádně vystavené a objednateli doručené v souladu s podmínkami této Smlouvy, sjednávají smluvní strany úrok z prodlení z dlužné částky v zákonné výši stanovené 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ěna 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ů.

12.3. Za prodlení zhotovitele s odstraněním vad a nedodělků zjištěných v rámci Akceptačního řízeni postupem dle čl. 9.4.2. této Smlouvy, ve lhůtách v akceptačním protokolu stanovených, je zhotovitel povinen zaplatit objednateli za každou vadu či nedodělek, s jejímž odstraněním se dostal do prodlení, smluvní pokutu ve výši 1.000,- Kč za každý den, ve kterém prodlení trvá.

12.4. Za porušení povinnosti zhotovitele zajišťovat Podporu Systému způsobem dle čl. 10 této Smlouvy se sjednávají smluvní pokuty následovně:

12.4.1. za nesoulad Systému (byť jeho jednotlivé funkcionality) s platnou a účinnou legislativou (legislativní update/upgrade dle čl. 1. Přílohy č. 4 této Smlouvy) je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 10 000,- Kč za každý jednotlivý zjištěný případ;

12.4.2. za nedostupnost (neplnění) služeb dle čl. 2.2. Přílohy č. 4 této Smlouvy je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 5 000,- Kč za každý jednotlivý zjištěný případ;

12.4.3. za prodlení s dobou reakce a/nebo dobou vyřešení stanovými pro Konzultační servis v rámci SLA dle čl. 2.3. Přílohy č. 4 této Smlouvy je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 500,- Kč za každou započatou hodinu prodlení;

12.4.4. za prodlení s dobou reakce a/nebo dobou vyřešení stanovenými pro oblasti provozní správy, expertní podporu, změny provozní dokumentace a legislativní údržbu v rámci SLA dle čl. 2.3. Přílohy č. 4 této Smlouvy je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 1 000,- Kč za každý započatý den prodlení;

12.5. Za porušení povinnosti zhotovitele zajišťovat plnění předmětu Smlouvy prostřednictvím realizačního týmu v souladu s čl. 8.7. této Smlouvy, je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 10.000,- Kč za každý jednotlivý zjištěný případ.

12.6. Za porušení závazku zhotovitele ve vztahu k licencím dle čl. 7.3. této Smlouvy, je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 50.000,- Kč za každý jednotlivý zjištěný případ.

12.7. Za porušení závazku zhotovitele ve vztahu k poskytnutí údajů či kódů dle čl. 7.10. věta druhá této Smlouvy, je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 100.000,- Kč za každý jednotlivý zjištěný případ.

12.8. Za porušení povinnosti zhotovitele mít uzavřenou pojistnou smlouvu v souladu s čl. 8.9. této Smlouvy, je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 50 000,- Kč.

12.9. Za porušení povinnosti zhotovitele ve věci ochrany osobních údajů, důvěrných informací či mlčenlivosti, stanovené v čl. 14. této Smlouvy, je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 50 000,- Kč za každý zjištěný případ.

12.10. Za porušení kterékoliv další povinnosti, závazku či prohlášení zhotovitele obsažených v této Smlouvě je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 1 000,- Kč za každý zjištěný případ, a to i opakovaně v případě, kdy po vytčení neplnění povinnosti, závazku či prohlášení zhotovitel tento stav nenapraví a neuvede jej do souladu se Smlouvou.

12.11. Objednatel uplatní nárok na smluvní pokuty uvedené v předchozích odstavcích vždy písemnou výzvou u zhotovitele. Zhotovitel je povinen zaplatit uplatněnou smluvní pokutu ve lhůtě uvedené ve výzvě, a není-li uvedena lhůta ve výzvě, tak do 10 (deseti) dnů od doručení této výzvy zhotoviteli. Uplatněnou smluvní pokutu, uvedenou v předchozím odstavci, zaplatí zhotovitel bez ohledu na to, vznikla-li objednateli škoda. Nárok na náhradu škody, způsobené objednateli v souvislosti s porušením smluvní povinnosti zhotovitelem, zůstává objednateli vůči zhotoviteli v plné výši zachován.

Čl. 13. Trvání a zánik Smlouvy

13.1. Tato Smlouva se v rozsahu týkajícím se dodání Systému a splnění souvisejících povinností dle této Smlouvy (Analýza, dodání SW, dokumentace, školení) sjednává na dobu nezbytnou k realizaci příslušných částí Díla, resp. na dobu trvání sjednané záruční doby.

13.2. Co do zajišťování Podpory Systému v rozsahu dle čl. 10 této Smlouvy se Smlouva sjednává na dobu určitou do 31. 12. 2029.

13.3. Smlouva zaniká vedle případů stanovených zákonem č. 89/2012 Sb., občanský zákoník, ve znění pozdějších právních předpisů, také:

a) dohodou smluvních stran, v jejímž obsahu je dohodnuto též vzájemné vyrovnání účelně vynaložených nákladů;

b) jednostranným odstoupením od Xxxxxxx objednatelem pro její podstatné porušení zhotovitelem, kterým se rozumí:

- prodlení zhotovitele s poskytnutím plnění delším než 30 (třicet) kalendářních dnů;

- prodlení zhotovitele s odstraněním vad či nedodělků delším než 15 (patnáct) kalendářních dnů;

- opakované plnění předmětu Smlouvy osobami nevyhovujícími požadavkům podle čl. 8.7. této Smlouvy, a to přes předchozí písemné upozornění objednatele na zjištění takové skutečnosti;

- opakované neposkytování Podpory Systému za podmínek (a tedy i ve lhůtách) sjednaných v čl. 10, resp. Příloze č. 4 této Smlouvy, a to přes předchozí písemné upozornění objednatele na zjištění takové skutečnosti;

c) jednostranným odstoupením od Xxxxxxx zhotovitelem pro její podstatné porušení objednatelem, kterým se rozumí prodlení s úhradou kterékoliv faktury splatné v souladu s touto Smlouvou o dobu delší než 60 dnů, a to přes předchozí písemné upozornění zhotovitele na vznik prodlení a možnost aplikace tohoto důvodu pro odstoupení od Smlouvy.

13.4. Objednatel je dále oprávněn od Smlouvy odstoupit v případě, že mu objektivně zanikne možnost využít předpokládané spolufinancování předmětu Díla z Projektu (zejména z důvodu neschválení Projektu poskytovatelem dotace, zrušení Projektu poskytovatelem dotace, ukončení Projektu a nezískání financování prostřednictvím navazujícího projektu apod.).

13.5. Objednatel je oprávněn vypovědět Xxxxxxx co do zajišťování Podpory Systému bez udání důvodu, a to s výpovědní lhůtou 6 měsíců, která počne svůj běh od prvního dne měsíce následujícího po měsíci, ve kterém bude výpověď doručena zhotoviteli.

13.6. Zhotovitel je oprávněn vypovědět Xxxxxxx co do zajišťování Podpory Systému bez udání důvodu, a to s výpovědní lhůtou 12 měsíců, která počne svůj běh od prvního dne měsíce následujícího po měsíci, ve kterém bude výpověď doručena objednateli; smluvní strany se dohodly, že výpověď podle tohoto článku je zhotovitel oprávněn učinit nejdříve po uplynutí 36 měsíců od zahájení poskytování Podpory Systému v souladu s touto Smlouvou. Přílohou výpovědi ze strany zhotovitele musí být kompletní dokumentace Systému a další související informace, podklady apod. (viz zejm. čl.

7.10 této Smlouvy) tak, aby v průběhu výpovědní doby byl objednatel schopen získat jiného dodavatele pro Podporu Systému či si ji byl schopen poskytovat sám tak, aby pořízený Systém neztratil funkčnost v důsledku výpovědi ze strany zhotovitele. Zhotovitel odpovídá za případné škody a dodatečné náklady způsobené objednateli v souvislosti s předčasným ukončením poskytování Podpory Systému.

Čl. 14. Xxxxxxx osobních údajů a důvěrných informací, mlčenlivost

14.1. Zhotovitel se zavazuje zachovávat mlčenlivost ohledně důvěrných informací, jimiž se rozumí:

14.1.1. skutečnosti, které se zhotovitel v souvislosti s plněním podle této smlouvy dozvěděl nebo které objednatel označil za důvěrné;

14.1.2. osobní údaje podle zákona č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů (dále jen „ZOOÚ“), resp. 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“).

14.2. Zhotovitel je oprávněn zpracovávat osobní údaje pouze za účelem plnění účelu této Smlouvy.

14.3. Zhotovitel je povinen přijmout opatření k ochraně důvěrných informací.

14.4. Povinnost mlčenlivosti a zachování důvěrnosti informací se nevztahuje na informace, které se staly obecně známými za předpokladu, že se tak nestalo porušením některé z povinností vyplývajících z této smlouvy, nebo o kterých tak stanoví zákon, zpřístupnění je však možné vždy jen v nezbytném rozsahu.

14.5. Za důvěrné informace se dále považují veškeré skutečnosti obchodní, ekonomické a technické povahy související se smluvními stranami, které nejsou běžně dostupné v obchodních kruzích a se kterými se smluvní strany seznámí při realizaci předmětu této Smlouvy nebo v souvislosti s touto Smlouvou.

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

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

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

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

14.7.3. jsou známé nebo byly zveřejněny jinak, než následkem porušení povinnosti jedné ze smluvních stran;

14.7.4. příjemce je zná dříve, než je sdělí smluvní strana;

14.7.5. jsou vyžádány soudem, státním zastupitelstvím nebo příslušným správním orgánem na základě zákona, popřípadě, jejichž uveřejnění je stanoveno zákonem;

14.7.6. smluvní strana 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.

14.8. V případě, že při plnění předmětu této Smlouvy se zhotovitel dostane do kontaktu s osobními údaji nebo bude docházet ke zpracování osobních údajů, je tato Smlouva zároveň smlouvou o zpracování osobních údajů ve smyslu § 6 ZOOÚ, resp. v souladu s podmínkami GDPR. Zhotovitel má pro účely ochrany osobních údajů postavení zpracovatele ve smyslu ZOOÚ, resp. GDPR. Pro případ, že aktuální legislativa bude vyžadovat doplnění této Smlouvy v souvislosti se zpracování osobních údajů, je zhotovitel povinen na vlastní odpovědnost navrhnout doplnění této Smlouvy tak, aby tato příslušným požadavkům ZOOÚ resp. GDPR vyhovovala.

14.9. Zhotovitel je oprávněn zpracovávat osobní údaje v rozsahu nezbytně nutném pro plnění předmětu této Smlouvy, za tímto účelem je oprávněn osobní údaje zejména ukládat na nosiče informací, upravovat, uchovávat po dobu nezbytnou k uplatnění práv zhotovitele vyplývajících z této Smlouvy, předávat zpracované osobní údaje objednateli, osobní údaje likvidovat.

14.10. Zhotovitel učiní v souladu s platnými právními předpisy dostatečná organizační a technická opatření zabraňující přístupu neoprávněných osob k osobním údajům.

14.11. Zhotovitel zajistí, aby jeho pracovníci i další osoby podílející se na jeho straně na plnění předmětu této Smlouvy byli v souladu s platnými právními předpisy poučeni o povinnosti mlčenlivosti a o možných následcích pro případ porušení této povinnosti. Povinnost mlčenlivosti není časově omezena.

14.12. Zhotovitel zajistí, aby písemnosti a jiné hmotné nosiče informací, které obsahují osobní údaje, byly uchovávány pouze v uzamykatelných skříních umístěných v uzamykatelných místnostech.

14.13. Zhotovitel zajistí, aby elektronické datové soubory obsahující osobní údaje byly uchovávány v paměti počítače pouze:

14.13.1. je-li přístup k takovýmto souborům chráněn heslem, jehož složitost splňuje požadavky best practice;

14.13.2. je-li přístup k užívání počítače, v jehož paměti jsou tyto soubory umístěny, chráněn heslem, jehož složitost splňuje požadavky best practice.

14.14. Je-li pro účely kontroly správného fungování předmětu plnění, odstranění vady nebo další úpravy či rozvoj plnění nezbytné poskytnout zhotoviteli kopii databází, souborů nebo nosičů údajů obsahujících jakékoliv údaje z činnosti objednatele, je zhotovitel povinen s takovými údaji nakládat tak, aby nedošlo k jejich úniku či zneužití.

14.15. Povinnosti ochrany důvěrných informací stanovených tímto článkem trvají bez ohledu na ukončení platnosti této Smlouvy.

Čl. 15. Vyšší moc

15.1. Za okolnosti vylučující odpovědnost smluvních stran za prodlení s plněním smluvních závazků dle této Smlouvy (vyšší moc) jsou považovány takové překážky, které nastanou nezávisle na vůli povinné smluvní strany a brání jí ve splnění její povinnosti z této Smlouvy, jestliže nelze rozumně předpokládat, že by povinná smluvní strana takovou překážku nebo její následky odvrátila nebo překonala, a dále, že by v době vzniku smluvních závazků z této Smlouvy vznik nebo existenci těchto překážek předpokládala.

15.2. Za překážky dle odst. 15.1. této Smlouvy se výslovně považují živelní pohromy, jakákoliv embarga, občanské války, povstání, válečné konflikty, teroristické útoky, nepokoje nebo epidemie. Za živelní pohromy se zejména považují požár, úder blesku, povodeň nebo záplava, vichřice nebo krupobití, sesuv.

15.3. Za okolnost vylučující odpovědnost zhotovitele se výslovně nepovažuje jakékoliv porušení právních povinností prodávajícího, způsobené jeho dodavateli.

15.4. Nastanou-li okolnosti vylučující odpovědnost jedné ze smluvních stran, které způsobí či mohou způsobit podstatné zpoždění jakéhokoliv termínu nebo prodlení lhůty podle této Smlouvy, či zánik nebo zrušení závazků podle této Smlouvy, jsou smluvní strany povinny se neprodleně o těchto okolnostech vylučujících odpovědnost informovat a vstoupit do jednání ohledně řešení vzniklé situace. Zhotovitel ani objednatel nejsou oprávněni takto vzniklé situace jakkoliv zneužít ve svůj prospěch a jsou povinni v dobré víře usilovat o dosažení přijatelného řešení pro obě smluvní strany v co nejkratší době. V případě porušení této povinnosti jedné smluvní strany spolupracovat s druhou smluvní stranou, je tato smluvní strana v prodlení s plněním svých povinností dle této Smlouvy.

15.5. V případě, že nedojde k dohodě smluvních stran, termíny či lhůty plnění jednotlivých povinností podle této Smlouvy, dotčené okolností vylučující odpovědnost, se prodlužují o dobu, po kterou okolnost, vylučující odpovědnost, trvala.

15.6. Odpovědnost nevylučuje překážka, která vznikla teprve v době, kdy povinná strana byla v prodlení s plněním své povinnosti, či vznikla z jejích hospodářských poměrů.

15.7. Účinky okolnosti, vylučující odpovědnost, jsou omezeny pouze na dobu, dokud trvá příslušná překážka, s níž jsou tyto účinky spojeny.

Čl. 16. Závěrečná ustanovení

16.1. Všechny právní vztahy, které vzniknou při realizaci závazků vyplývajících z této Smlouvy, se řídí právním řádem České republiky.

16.2. Tuto Smlouvu lze měnit pouze písemným, číslovaným, oboustranně potvrzeným ujednáním, výslovně nazvaným dodatek ke Smlouvě, podepsaným statutárními orgány nebo zmocněnými zástupci obou smluvních stran. Jiné zápisy, protokoly apod. se za změnu Xxxxxxx nepovažují. Při jednání o jakékoliv změně této Smlouvy není odpověď smluvní strany, přijímající návrh na uzavření dodatku Xxxxxxx s doplněním nebo odchylkou, přijetím návrhu dodatku na jeho uzavření.

16.3. V případě změny v osobě oprávněné jednat za nebo jménem smluvní strany, zástupce objednatele nebo zhotovitele oprávněného jednat ve věcech faktické realizace Smlouvy, nebude vyhotoven dodatek ke Smlouvě; smluvní strana, u které ke změně došlo, je povinna tuto změnu oznámit druhé smluvní straně. Účinnost změny nastává okamžikem doručení oznámení příslušné smluvní straně.

16.4 Smluvní strany sjednaly, že doručování se provádí na doručovací adresy uvedené v čl. 1. této Smlouvy. V případě, že smluvní strana odmítne doručovanou zásilku převzít, platí den odmítnutí převzetí za den doručení. V případě, že smluvní strana nevyzvedne zásilku v úložní době u držitele poštovní licence, má se za to, že zásilka byla doručena 3. (třetím) dnem od uložení a to, i když se smluvní strana o uložení nedozvěděla. Ujednání tohoto článku se nevztahují na doručování sjednané v čl. 6.3. této Smlouvy.

16.5. V případě změny sídla, místa podnikání, nebo doručovací adresy zhotovitele je zhotovitel povinen neprodleně tuto skutečnost oznámit objednateli. Pokud zhotovitel tuto povinnost nesplní, platí pro doručování písemností adresa uvedená v čl. 1. této Smlouvy.

16.6. Zhotovitel souhlasí se zveřejněním obsahu této Smlouvy podle povinností, které se na objednatele vztahují ve smyslu ustanovení § 219 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, resp. 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 (zákon o registru smluv), ve znění pozdějších předpisů. Smluvní strany se dohodly, že uveřejnění Smlouvy v registru smluv zajistí objednatel.

16.7. Jestliže z výzvy včetně zadávací dokumentace na veřejnou zakázku nebo nabídky zhotovitele podané v zadávacím řízení na veřejnou zakázku vyplývají zhotoviteli povinnosti vztahující se

k realizaci předmětu této Smlouvy, avšak tyto povinnosti nejsou výslovně v této Smlouvě uvedeny, smluvní strany se pro tento případ dohodly, že i tyto povinnosti zhotovitele jsou součástí obsahu závazkového vztahu založeného touto Smlouvou a zhotovitel je povinen je dodržet.

16.8. Smluvní strany prohlašují, že Xxxxxxx byla uzavřena podle jejich vážné a svobodné vůle, že nebyly k jednání přinuceny pod hrozbou násilí ani lstí, Xxxxxxx si přečetly, považují obsah této Smlouvy za určitý a srozumitelný, jsou jim známy veškeré skutečnosti, jež jsou pro uzavření této Smlouvy rozhodující, a na důkaz toho připojují ke Smlouvě své podpisy.

16.9. Tato Xxxxxxx nabývá platnosti dnem jejího podpisu oběma smluvními stranami a účinnosti jejím uveřejněním v souladu s ustanovením § 6 odst. 1 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 (zákon o registru smluv), ve znění pozdějších předpisů.

16.10. Smlouva je vyhotovena ve 3 (třech) výtiscích, z nichž dva obdrží objednatel a jeden zhotovitel.

Čl. 17. Přílohy

Nedílnou součástí této Smlouvy jsou následující přílohy:

Příloha č. 1 – Věcný popis Konzultačního servisu – business plán Příloha č. 2 – Technická specifikace Konzultačního servisu

Příloha č. 3 – Minimální požadavky na strukturu a dostupnost informací z Konzultačního servisu na webu CRR

Příloha č. 4 – Požadavky na úroveň poskytovaných služeb (SLA) a na podporu Konzultačního servisu

Příloha č. 5 – Technické řešení Konzultačního servisu

Příloha č. 6 – Plná moc pro Xxx. Xxxxxx Xxxxx (samostatně připojený dokument)

V Praze dne 5. 6. 2020 V Brně dne 31. 3. 2020

………………………………………… ………………………………….………..

Xxx. Xxxxxx Xxxxx Xxx. Xxxxx Xxxxx

generální ředitel předseda představenstva, v plné moci

Centrum pro regionální rozvoj InQool, a.s. České republiky

Příloha č. 1 – Věcný popis Konzultačního servisu – business plán

Popis požadavku	Splňuje (ANO / NE)	Pozn., event. popis naplnění
Východiska KS
Cílem je evidovat dotazy k IROP 2 přehledně v jedné databázi dostupné všem relevantním pracovníkům CRR. Tím dojde k vytvoření znalostní databáze, která bude využívána jako pomůcka pro další odpovědi tazatelů. Struktura databáze, ovládací prvky a další části poskytnutého řešení poskytnou maximální podporu pro zajištění jednotného obsahu odpovědí na obdobné dotazy a tedy ve výsledku jednotný přístup vůči žadatelům a příjemcům napříč všemi pobočkami CRR. Přínosem pro veřejné uživatele systému bude přehled vlastních dotazů a odpovědí na ně na jednom místě.	ANO	----
Požadavky na SW KS
Obecná funkčnost helpdesku.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Příjem dotazů (strukturované vyplnění dle číselníků, textové pole pro dotaz).	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Systém bude umožňovat vkládání příloh s omezením velikosti a typu souboru (tuto funkčnost ale zatím neplánujeme využívat).	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Evidence dotazů, odpovědí a tazatelů.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Notifikace o zadání a přidělení dotazů dle nastavených pravidel.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Delegace dotazů v rámci organizace (notifikace o přidělení a vyřízení) - předání dotazu v rámci vnitřní struktury (Centrum – ŘO) - komunikace neviditelná pro externího uživatele/tazatele, ale uchovatelná – forma komentářů.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Zodpovídání dotazů skrz aplikaci s notifikací na tazatelem zadaný e-mail.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Registrace externích uživatelů dle „firmy/organizace“.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Vstup pro externí uživatele přes webovou stránku, která bude využívat stejný vizuální styl jako webové stránky CRR	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Požadavky na SW – Externí uživatelé
Budou se registrovat (odkaz na webových stránkách CRR). Bude probíhat ověření zadané mailové adresy, možnost resetu hesla.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Vyplní požadované údaje a odešlou dotaz.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Své dotazy i odpovědi na ně mají přístupné pod svým účtem.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Na zadaný a ověřený mail dostávají notifikace o zaregistrování požadavku, o jeho zodpovězení, o případném následném doplnění odpovědi. V případě, že dotaz není do určité lhůty zodpovězen (např. do týdne), dostávají notifikaci o tom, že stále probíhá příprava odpovědi.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Zveřejněné odpovědi ostatních tazatelů a také	ANO	Na základě technologické platformy iQ

FAQ budou externím uživatelům k dispozici na webu CRR. Pro tyto účely požadujeme XML rozhraní pro možnost přenosu dat.		UAS 2.0 popsané v nabídce.
Požadavky na SW – Interní uživatelé
maximálně 650 uživatelů, z toho 10 pracovníků Ministerstva pro místní rozvoj (Řídící orgán IROP).	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Budou jim přiděleny role administrátor (cca 5 uživatelů), editor (cca 60 uživatelů) a čtenář (maximálně 600 uživatelů)	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Čtenáři – mohou jen číst dotazy a odpovědi, případně vygenerovat sestavu z interní části databáze.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Editoři – zodpovídají dotazy, delegují je na jiné editory. Zadané odpovědi mají možnost doplňovat, doplňovat k nim komentáře. Označují dotazy určené ke zveřejnění v seznamu dotazů nebo v FAQ, případně ruší toto označení. Dále mají možnost odesílat notifikace tazateli nebo jinému internímu uživateli. O dotazu vloženém do KS je příslušný editor informován notifikací. Příslušnost je určena dle specifického cíle, aktivity a dle kraje realizace projektu. Editoři mají možnost dotaz uživatelsky zadat za tazatele (po telefonické mailové nebo osobní konzultaci).	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Administrátoři – nastavují role uživatelům KS. Mají možnost upravovat číselníky, zadávat nové číselníky a uživatelsky nastavovat automatické notifikace (o registraci dotazu, jeho zodpovězení, případné pozdější aktualizaci odpovědi, o stavu zpracování odpovědi, atd.) Administrátoři mají oprávnění zadávat požadavky na rozvoj/úpravy KS.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Interní uživatelé mají možnost vyhledávat dotazy a odpovědi v databázi, filtrovat dle všech zadaných parametrů, vytvářet výstupní sestavy z databáze ve formátu xlsx.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Popis fungování KS z uživatelského hlediska
Tazatel (externí uživatel) se zaregistruje na webové stránce KS – založí si svůj účet, proběhne ověření zadané mailové adresy.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Tazatel vyplní do formuláře svůj dotaz (vyplní údaje dle Přílohy č. 3 – „Minimální požadavky na strukturu informací ... na webu CRR ČR“.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Xxxxxxx dostane mailem notifikaci o zaregistrování svého dotazu. Dotaz bude mít na svém účtu přístupný.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Podle zadaných informací systém identifikuje interního uživatele zodpovědného za zajištění odpovědi a zašle mu automatickou notifikaci do mailu.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Interní uživatel zodpovědný za zajištění odpovědi může dotaz vrátit k doplnění tazateli, může k dotazu doplnit komentář a dotaz delegovat na jiného interního uživatele. Ten je o tomto kroku informován automatickou notifikací do svého mailu.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Pokud není dotaz zodpovězen do týdne (nebo	ANO	Na základě technologické platformy iQ

jiné lhůty, jejíž délku má možnost uživatelsky nastavit interní uživatel s rolí administrátor), dostává tazatel automatickou notifikaci do mailu (s informací, že odpověď se ještě připravuje). Notifikaci může i ručně vytvořit interní uživatel (např. vysvětlení, proč příprava odpovědi trvá déle).		UAS 2.0 popsané v nabídce.
Interní uživatel s rolí editor xxxxx xxxxxxx, o čemž je tazatel informován automatickou notifikací.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Tazatel odpověď vidí na svém účtu – je přiřazena k příslušnému dotazu. Tazatel pod svým účtem vidí pouze své dotazy a příslušné odpovědi.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Interní uživatel s rolí editor má možnost doplnit odpověď už zodpovězeného dotazu, o čemž je příslušný tazatel automaticky informován notifikací do mailu.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Interní uživatel s rolí editor má možnost doplnit komentář k dotazu v jakémkoli stavu. Komentář bude viditelný pro všechny interní uživatele, nebude viditelný pro externí uživatele.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Interní uživatel s rolí editor má možnost odpověď označit příznakem „Zveřejnit“, což může kdykoli vzít zpět. Informace o takto označených dotazech bude moci z KS exportovat přes standardní XML rozhraní (o která data se jedná je uvedeno v příloze „KS- návrh.xlsx“).	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Interní uživatel s rolí editor má možnost odpověď označit příznakem „Zveřejnit v FAQ“, což může kdykoli vzít zpět. Informace o takto označených dotazech bude moci z KS exportovat přes standardní XML rozhraní (o která data se jedná je uvedeno v příloze „KS- návrh.xlsx“).	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Interní uživatel s rolí editor má možnost upravovat všechny zadané informace u všech dotazů v databázi ve všech stavech.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Interní uživatel s rolí editor může v rámci interní databáze příznakem seskupit externí uživatele pod různé subjekty (firmy/organizace).	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Interní uživatel s rolí administrátor má možnost přidělit nebo odebrat ostatním interním uživatelům roli editor nebo administrátor. Interní uživatelé, kteří nemají roli editor nebo administrátor mají roli čtenář.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Interní uživatel s rolí administrátor má možnost doplňovat položky číselníků nebo vytvářet nové číselníky, které se stanou součástí databáze dotazů a formuláře pro zadání dotazu.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Interní uživatel s rolí administrátor má možnost uživatelsky nastavovat pravidla pro zasílání automatických notifikací interním i externím uživatelům.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.
Všichni interní uživatelé systému mohou číst všechny informace v databázi, řadit a filtrovat podle všech parametrů, exportovat data do souboru formátu xlsx nebo xml.	ANO	Na základě technologické platformy iQ UAS 2.0 popsané v nabídce.

Příloha č. 2 – Technická specifikace Konzultačního servisu

Pozn: V případě, že je pod jednotlivými nadpisy vypsáno více parametrů, platí podmínka pro splnění všech, tzn. „a zároveň“.

Popis požadavku	Splňuje (ANO / NE)	Pozn., souhlas, event. popis naplnění
TECHNICKÉ (NEFUNKČNÍ) POŽADAVKY
Návrh aplikace
Návrh aplikace musí být objektový.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Aplikace musí být moderní, reflektující nové trendy v IT a to jek technologicky ve vazbě na použité technologie, tak i vzhledově a věcně.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Aplikace je webová aplikace provozovaná bez doplňků na straně uživatelů.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Konzultační Servis je typově blízký HelpDesku/ServiceDesku, který je upraven na míru specifickému účelu	ANO	Za uchazeče InQool, a.s. souhlasíme.
Licenční podmínky a zdrojové kódy
Pokud KS bude dodáván jako licencovaný produkt: - Zadavatel nepožaduje zdrojové kódy aplikace. - Zadavatel nepožaduje výhradní licenci - Zadavatel bude oprávněn využívat veškerou funkčnost KS v souladu se ZD.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Zadavatel požaduje garanci bezpečného provozu minimálně po dobu 10 let od podpisu (bezpečným provozem se rozumí odstranění bezpečnostních zranitelností nebo případně jejich eliminací.) smlouvy	ANO	Za uchazeče InQool, a.s. souhlasíme.
Zadavatel požaduje možnost vývoje/úprav do systému minimálně po dobu 5 let od podpisu smlouvy	ANO	Za uchazeče InQool, a.s. souhlasíme.
Součástí dodávky musí být i licence třetích stran nezbytných pro provoz systému, pokud jsou vyžadovány pro běh KS	ANO	Za uchazeče InQool, a.s. souhlasíme.
Po dobu trvání smlouvy se dodavatel zavazuje zajistit platnou podporu pro licence třetích stran minimálně v rozsahu možnosti využití nových verzí a odstranění bezpečnostních chyb.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Dodavatel garantuje licenční čistotu provozu celého systému.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Licenčně počty uživatelů interních i externích jsou bez omezení.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Podpůrné systémy, služby, moduly a licenční čistota těchto služeb provozovaných v OS pro KS jsou v plném rozsahu ke zodpovědnosti vybraného dodavatele.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Po celou dobu platnosti smlouvy budou používány jen takové externí komponenty, služby a jiné součástí systémů, kterým nenastalo datum EoL (EndOfLife)	ANO	Za uchazeče InQool, a.s. souhlasíme.
Uživatelské rozhraní
Uživatelské rozhraní pro externí i interní uživatele KS je moderní grafické webové. Aplikace musí být provozovaná bez doplňků na straně uživatelů na požadovaných prohlížečích s plnou srovnatelnou funkcionalitou.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Rozhraní podporuje minimálně následující	ANO	Za uchazeče InQool, a.s. souhlasíme.

webové prohlížeče vždy poslední verze: MS Xxxx, Firefox, Chrome.
KS je dostupný z Portálu (webu) CRR a na tento Portál je navigace (odkaz) ze stránek CRR (zajistí zadavatel v rámci analýzy požadavků).	ANO	Za uchazeče InQool, a.s. souhlasíme.
Rozhraní pro externí uživatele je minimálně v českém a anglickém jazyce.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Mezi jazykovými verzemi se dá dynamicky přepínat.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS je připraven na přidání dalších jazyků pro komunikaci s externími uživateli (spolupráce se SK).	ANO	Za uchazeče InQool, a.s. souhlasíme.
Rozšíření rozhraní o další jazykové mutace musí být možno jen doplněním „slovníku“ bez nutnosti změny kódu aplikace.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Rozhraní pro interní uživatele je minimálně v českém jazyce.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS má pro vyplňování formulářů externími uživateli průvodce.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Uživatel může pracovat i přímo s formuláři bez využití průvodce.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS zobrazuje před přihlášením uživatele varování typu „Tuto aplikaci smí používat pouze uživatel s platným oprávněním“ a „Využití aplikace je monitorováno“.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS zobrazuje po přihlášení uživatele datum a čas posledního úspěšného přihlášení a seznam neúspěšných přihlášení od posledního úspěšného přihlášení.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Obsahuje kontextový help.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Součástí rozhraní pro interní uživatele je i grafické administrátorské rozhraní pro konfiguraci, správu a ovládání aplikace KS. Toto rozhraní umožňuje minimálně: - konfigurovat KS - nastavené základních parametrů služeb, možné základní úpravy formulářů. - startovat a zastavovat jednotlivé komponenty (moduly) KS	ANO	Za uchazeče InQool, a.s. souhlasíme.
Provoz Konzultačního servisu
KS bude provozován na prostředcích zadavatele v definovaném rozsahu.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Dodavatel bude mít k dispozici na provoz KS vyčleněný výpočetní virtuální prostor zadavatele.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Vlastnosti vyčleněného výpočetního virtuální prostor: - Dedikovaný diskový prostor pro VHD je 150 GB - 4 jádra vCPU – odpovídající výkonu CPU řady Xeon E5-26xx, - 24GB RAM - Dodavatel je oprávněn rozdělit výpočetní výkon na více virtuálních serverů - Zadavatel garantuje 1x denně zálohu celého VM po dobu 14 dnů - Dostupnost VM je 99,9% v režimu 7x24 - Server bude umístěn v DMZ infrastruktury	ANO	Za uchazeče InQool, a.s. souhlasíme.

zadavatele - Server bude provozován na virtualizační platformě Hyper-V - Dodavatel bude mít úplná administrátorská práva k OS daného serveru - Všechny hypervizor servery jsou pokryty licencí OS Windows server edicí Datacenter pokryté platnou SA. - Hypervizor servery mají přidělené licence MS Windows Server External Connector.
Za kompletní správu prostředí KS, serverů KS, prostředí OS a služeb KS včetně souvisejících částí, které jsou předmětem realizace, zodpovídá dodavatel.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Testovací prostředí KS je vyžadováno, viz níže kapitola „Testovací prostředí“.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Dodaný informační systém musí reflektovat vývoj v IT technologiích a být schopný v průběhu času po dobu trvání smluvního vztahu, plně fungovat na nástupnických technologických produktech.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Vazba na Active Directory (AD)
KS musí být napojen na Active Directory v režimu Single Sign On. Interní uživatelé se tedy autentizují do KS svým AD účtem jménem a heslem (LDAP nebo využití autentizace pomocí ADFS Single Sign On).	ANO	Za uchazeče InQool, a.s. souhlasíme.
Role a práva pro KS pro konkrétního uživatele si řeší SW interně formou aplikačních práv uvnitř služeb KS. Oprávnění a práva uživatelů zadává zadavatel po proškolení vybraným dodavatelem.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Vazba na AD bude využita pouze pro vybranou skupinu interních uživatelů.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Vazba na AD musí být realizována standardizovaným bezpečným způsobem. Funkčnost autentizace do KS v infrastruktuře zadavatele je povinností dodavatele v té míře, aby realizoval vazbu na AD v souladu s best practice společnosti Microsoft pro provoz webových aplikací.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Zadavatel, v rámci realizace KS a vazby na AD, nepřipouští řešení postavené na domain trust, read only domain controler.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Přiřazení uživatelů z Active Directory (realizace Single Sign On), integrace s MS AD zadavatele s využitím LDAP komunikace (důvěra v přihlášení), případně využití autentizace pomocí ADFS Single Sign On.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Správa uživatelů, tvorba/správa uživatelských rolí/skupin, integrace s MS AD zadavatele s využitím LDAP nebo ADFS komunikace.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Správa uživatelů bude realizována v aplikaci KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Konstrukce login name pro aplikaci nesmí byt omezena vůči pravidlům MS AD.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Základní informace o uživateli (např. e-mail, telefon, umístění, nadřízený,…), které KS potřebuje, musí získat z AD. Připouští se	ANO	Za uchazeče InQool, a.s. souhlasíme.

duplikace údajů v režimu automatické aktualizace (refresh) ve svém prostředí, ale bude si je přebírat právě z MS AD.Seznam atributů k využití z MSAD bude upřesněn v rámci realizace. Atributy jsou standardní a vychází z typu a názvu běžně využívaných.
Možnost ručního spuštění synchronizace uživatelů a atributů.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Zadavatel vyžaduje autentizaci interních uživatelů vůči MS Active Directory metodou Single Sign On.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Autoritativním zdrojem vybraných interních uživatelů je doména zadavatele.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Správa KS
Za kompletní správu prostředí KS, serverů KS a prostředí KS včetně souvisejících částí, které jsou předmětem realizace, zodpovídá dodavatel.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Vývoj KS je požadován v plném rozsahu po vybraném dodavateli.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Údržba KS je požadována v plném rozsahu po vybraném dodavateli.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Bezpečnost KS je požadována v plném rozsahu po vybraném dodavateli.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Penetrační testy, implementace, nasazení systému a funkcionalit KS a provoz KS je povinností vybraného dodavatele.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Dostupnost KS
KS je provozován pro externí i interní uživatele s dostupností v režimu 5 x 12. Během rozšířené pracovní doby 8-20 hodin může dojít k plánovanému výpadku maximálně po dobu 2 hodin týdně.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Celková doba výpadku KS bez plánovaných odstávek pro externí i interní uživatele během rozšířené pracovní doby může být za kalendářní měsíc maximálně 8 hodin a celkem za rok 32 hodin. Nedostupnost jednoho modulu je považována za nedostupnost celého KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Mimo rozšířenou pracovní dobu je prostředí KS pro externí i interní uživatele standardně dostupné s výjimkou servisního okna v maximální délce 6 hodin 1x týdně.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Mimo rozšířenou pracovní dobu může dojít ke kompletnímu výpadku KS max. 6 hodin 1x týdně.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Dostupnost testovacího prostředí je v režimu 5 x 8. Během pracovní doby 8-16 hodin může dojít k výpadku dostupnosti KS maximálně po dobu 6 hodin.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Celková doba výpadku testovacího prostředí KS bez plánovaných odstávek během pracovní doby může být za kalendářní měsíc maximálně 10 hodin a celkem za rok 40 hodin. Nedostupnost jednoho modulu je považována za nedostupnost celého KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Mimo pracovní dobu je testovací prostředí KS standardně dostupné s výjimkou servisního okna v maximální délce 12 hodin 1x týdně.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Mimo pracovní dobu může dojít ke kompletnímu	ANO	Za uchazeče InQool, a.s. souhlasíme.

výpadku dostupnosti testovacího prostředí KS.
Uložení dat v databázi
Data KS jsou uložena v relační databázi ve struktuře odpovídající datovému modelu.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS a jeho vazba na databázi, by měla být na DNS jméno nikoliv přímo na IP adresu (pokud vyplívá z řešení, DNS adresace je brána jako vhodnější).	ANO	Za uchazeče InQool, a.s. souhlasíme.
Do databáze se ukládají veškeré data KS s vyjma příloh typu obrázky a jiné. Ty mohou být uloženy i jinak, než v databázi.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Zadavatel neposkytuje prostředí pro provoz databází pro potřeby KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Provoz databáze(í) pro KS musí být v souladu s best practice společnosti vyvíjející dané databázové řešení. Verze DB serveru musí být plně podporovaná výrobcem. Zadavatel požaduje pro dodávaný databázový systém použití moderních technologií s podporou řešení třetích stran včetně bezpečnostních a jiných aktualizací.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Zadavatel preferuje poslední verze databázového systému, tedy provoz aktuální dostupné verze. Není přípustné provozovat databázový server, který již nemá plnou podporu výrobcem a nejsou vydávány aktualizace pro jeho provoz.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Databázové řešení musí reflektovat požadavky KS po celou dobu předpokládaného provozu a limity verzí databázového prostředí nesmí omezovat chod samotného KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Kapacitní požadavky na KS
Maximálně 650 interních uživatelů, z toho maximálně 10 administrátorů.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Odhad 20 tisíc externích subjektů (OVM a právnické osoby případně i fyzické osoby). Je předpoklad neomezeného počtu subjektů.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Každý externí subjekt má právo vytvořit dotaz a k němu historii odpovědí.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Každý subjekt má možnost využít až 100 různých formulářů se žádostmi či dotazy.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Každý externí subjekt má svou schránku/účet – své přihlášení do KS. Své přihlášení získá subjekt po registraci externího uživatele a tento účet je uložen v databázi KS. Registrace externího uživatele je součástí KS. O externím uživateli bude zadavatel uchovávat pouze základní identifikační údaje jako IČO, DIČ, Jméno, Příjmení, Jméno organizace, Adresa – není striktně vyžadována implementace číselníku adres, kontakt telefon a mobil. Registrace žadatele (externího subjektu) bude ověřována automatem na mail adresu, kterou uvedl v registraci. Zadavatel si vyhrazuje právo určit přesný rozsah ukládaných atributů v rámci před implementační analýzy. Registrace však nepředpokládá ukládat více jak 12 základních informací o subjektu.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Výkonnostní požadavky na KS
Všechny části systémů KS odpoví na libovolný	ANO	Za uchazeče InQool, a.s. souhlasíme.

požadavek klienta (uživatele) v 90 % nejdéle do 2 s a v 98 % nejdéle do 5 s. Přihlášení do aplikace pak max. 10s interní/externí uživatelé.
Plánován je (KS umožní) provoz až 300 současně pracujících klientů, denně do systému může přistoupit až 2000 klientů (externích subjektů).	ANO	Za uchazeče InQool, a.s. souhlasíme.
Vyhledávání jakýchkoliv dotazů v jakémkoliv zadávaném tvaru využívá indexy databáze a odezvy nesmí překročit 5 sekund.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Zadání na vyhledávání uživatelů, která by zapříčinila dlouhé odezvy nebo neúměrné zatížení služeb, musí být ošetřena z hlediska výkonu, bezpečnosti a provozu.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Maximální doba běhu skriptu, která by blokovala ostatní moduly či uživatele pro běžný chod 120 s.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Počet současných spojení do databáze plyne z architektury KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS bude zasílat notifikace tazatelům i interním uživatelům do mailu a to na základě workflow vyspecifikované v rámci analýzy.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Testovací prostředí KS
Testovací prostředí KS je vyžadováno.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Testovací prostředí KS je určeno pouze pro testování interními zaměstnanci.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Testovací prostředí KS musí být od produkčního prostředí KS odděleno a to včetně samostatné databáze. Produkční a testovací prostředí mají oddělené databáze.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Testovací prostředí KS se od produkčního prostředí KS liší pouze výkonově.	ANO	Za uchazeče InQool, a.s. souhlasíme.
V testovacím prostředí KS nesmí být žádné údaje z produkčního ani testovacího prostředí. Data obsažená v testovací instanci jsou demonstrativní a nejsou vázána na osobní údaje k danému záznamu.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Autentizace do testovacího prostředí i produkčního prostředí jsou obdobná, tzn. na jiné url adrese se stejným přihlašovacím jménem.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Testovací prostředí musí být graficky viditelně označeno, že se jedná o TEST.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Komunikace KS
Komunikace mezi jednotlivými komponentami KS probíhá na standardních protokolech TCP/IP. Musí být možné použít IPv4 i IPv6.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Komunikace mezi testovacím a produkčním prostředím není možná.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Certifikáty pro komunikaci zajistí zadavatel a předá k provozu dodavateli, který je odpovědný za jejich funkčnost v aplikaci.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Musí být možné zajistit šifrování a vzájemnou autentizaci komunikace mezi komponentami jedné instance KS i mezi instancemi KS buď prostředky KS, nebo prostředky operačního systému serverů, na kterých KS běží, nebo prostředky dalších SW nebo HW komponent.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Komunikace KS vs client je výhradně a pouze na portu 443 a tedy https. Xxxx porty nesmí být	ANO	Za uchazeče InQool, a.s. souhlasíme.

použity.
Externí uživatelé (z MMR) budou mít účet na webserveru a autentizace formou přihlášení vůči službě KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Hardware
Součástí dodávky nejsou servery ani žádný jiný hardware.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Aplikační infrastruktura
Zadavatel připouští použití i jiného OS než Windows Server a to konkrétně OS Linux. OS musí být obecně známý a podporovaný a musí být implementován v poslední verzi dané distribuce.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Operační systém pro KS být musí podporován pro provoz v Hyper-V prostředí.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Dodavatel se zavazuje provádět upgrade OS v návaznosti na upgrade virtualizačního prostředí zadavatele.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Data jsou uložena v databázi (Více informací v kapitole „Uložení dat v databázi“).	ANO	Za uchazeče InQool, a.s. souhlasíme.
Na serverech s KS je provozován antimalware software jako ochrana služeb a bezpečně nakonfigurovaný firewall v souladu s best practice společnosti Microsoft (případně společností spravující Linux distribuci) pro bezpečnost dat a provoz webových služeb.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Pro práci interních uživatelů je možné používat PC a notebooky s operačním systémem MS Windows 10.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Práce v KS pod systémy iOS, MacOS, WindowsPhone nebo Android není vyžadována.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Nahlížení k části systémů na stránkách zadavatele bez autentizace (knowledge base), tipy a rady a dále není předmětem VZ.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Konfigurovatelnost KS
KS musí být konfigurovatelný. Dále je uveden neúplný výčet konfiguračních parametrů.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Nastavitelný manuální nebo automatický režim. - Globálně. - Pro jednotlivé typy workflow. - Pro jednotlivé kroky workflow.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Definice workflow.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Prováděné vstupní kontroly. - Odděleně pro jednotlivé moduly KS. - Odděleně pro jednotlivé typy externích uživatelů.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Povolené rozsahy IP adres. - Odděleně pro jednotlivé typy externích uživatelů.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Země, ze kterých je povolený přístup ke KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Zdroje pro autorizaci interních uživatelů – viz. vazba na AD.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Doba pro reautentizaci uživatelů. - Odděleně pro jednotlivé moduly KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Kryptografické prostředky.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Log servery a protokol (TCP/UDP) pro zasílání logů. Je možné nadefinovat až dva nezávislé cíle pro logování.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Údaje nutné pro přístup k DS KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.

Údaje (včetně hesel) pro přístup k obsahu DB KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Konfigurace poštovního SMTP serveru. Je možné nadefinovat až dva servery. Při nedostupnosti jednoho KS zkouší poslat přes druhý server. Je vyžadováno smtp autentifikace a SSL komunikace na SMTP server.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Implicitní jazyk pro externí uživatele.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Implicitní jazyk pro interní uživatele.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS bude zasílat notifikace tazatelům i interním uživatelům do mailu a to na základě workflow vyspecifikované v rámci analýzy.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Záznamy o provozu KS
KS protokoluje svoji činnost, tj. vytváří záznamy o jednotlivých operacích a odesílá je na dohledové systémy CRR (napojení na SIEM či jiný systém musí být standardní a běžné). Minimální rozsah je alespoň 3 metody (řádky) uvedené způsoby sběru událostí: 1. Standardní syslog - RFC 5424 2. prosté soubory (s jasně definovanou strukturou – bude upřesněno v rámci analýzy)	ANO	Za uchazeče InQool, a.s. souhlasíme.
Vytváří záznamy o úspěšných i neúspěšných operacích.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Výhodou možnost nastavení vlastních chybových hlášek webového serveru.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Monitoring událostí, aktivity uživatelů, prohlížení logů (fulltextové vyhledávání).	ANO	Za uchazeče InQool, a.s. souhlasíme.
Logování administrátorských činností (vytváření účtů, uživatelů, zástupů, rolí,…).	ANO	Za uchazeče InQool, a.s. souhlasíme.
Přehled aktivních uživatelů (případně uživatelů využívajících licenci k systému), přehled aktuálně přihlášených uživatelů.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Blokování přístupů uživatele od definovaného data na definované moduly/celky.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Exit strategie
Není po vybraném dodavateli požadována.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Zadavatel v plném rozsahu požaduje kompletní export svých dat včetně číselníků do předem schválené podoby. Předpoklad jsou formáty typy MS Office (XLSX v 2016 a vyšší).	ANO	Za uchazeče InQool, a.s. souhlasíme.
Data KS jsou vlastnictvím zadavatele nikoliv provozovatele systému.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Provozovatel (dodavatel) nesmí bez výslovného písemného souhlasu nejvyšších činitelů organizace zadavatele jakkoliv s daty manipulovat, zveřejňovat či jinak nakládat.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Bezpečnostní požadavky
Pro vývoj a provoz KS je možné používat pouze takové prostředky, které neohrožují bezpečnost KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Ukládání dat, bezpečnost prostředí vyplývající z provozu serverů a služeb pro KS musí být v souladu s best practice.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS provádí identifikaci a autentizaci MS Active Directory viz vazba na AD. Ostatní uživatelé se autentizují pomocí webového přihlášení vůči KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS nepovolí žádné operace s výjimkou veřejně přístupných před úspěšnou autentizací	ANO	Za uchazeče InQool, a.s. souhlasíme.

uživatele.
KS nepovolí více současných přihlášení jednoho uživatele.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS zobrazí každému uživateli údaj o posledním úspěšném přihlášení a údaje o posledním neúspěšném pokusu o přihlášení. Na vyžádání zobrazí uživateli historii úspěšných přihlášení a neúspěšných pokusů o přihlášení.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS má implementované role pro rozlišení oprávnění uživatelů.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS provádí reautentizaci uživatele po určité době nečinnosti. Tato doba je konfigurovatelná a může být odlišná pro různé kategorie (kombinace rolí) uživatelů.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS odhlásí uživatele po určité době nečinnosti. Tato doba je konfigurovatelná a může být odlišná pro různé kategorie (kombinace rolí) uživatelů.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS provádí autorizaci uživatele při každém provádění jakékoli operace, která není veřejně přístupná.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS provádí protokolování akcí prováděných uživateli (logování).	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS umožňuje online odesílání záznamů o činnosti na log server s využitím standardních protokolů a formátů dat (syslog).	ANO	Za uchazeče InQool, a.s. souhlasíme.
Veškerý přístup externích uživatelů ke KS s výjimkou přístupu k veřejným informacím je šifrovaný (HTTPS). Nešifrovaný provoz je úplně zakázán.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS kontroluje veškeré vstupní údaje včetně URL, cookies, HTTP hlaviček a dále. Ověřuje přípustný rozsah dat, kódování vstupních údajů, délku vstupních údajů. Zajistí, že dovnitř se nedostanou nebezpečná nebo nekorektní data. Kontroly dat jsou konzistentní v celém KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS kontroluje veškerá výstupní data a nepovolí výstup dat, která by mohla ohrožovat jiné systémy.	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS nezobrazuje uživatelům v chybových hlášeních žádné údaje, které by mohl někdo využít k narušení bezpečnosti KS (údaje o účtech, jiných uživatelích, ladicí informace, interní adresy atd.).	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS pracuje bezpečným způsobem s pamětí. Alokuje dostatečné množství paměti pro jednotlivé operace. Uvolňuje bezpečným způsobem alokovanou paměť (vymaže obsah, skutečně paměť uvolní).	ANO	Za uchazeče InQool, a.s. souhlasíme.
KS neobsahuje žádné nedokumentované funkce, nebo zadní vrátka.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Komunikace KS vs client je výhradně a pouze na portu 443 a tedy https. Xxxx porty nesmí být použity.	ANO	Za uchazeče InQool, a.s. souhlasíme.
U použitých standardních komponent jsou odstraněny veškeré části, které nejsou nezbytné pro fungování KS. Jsou změněna veškerá standardní hesla.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Údaje pro spojení s databází jsou chráněny.	ANO	Za uchazeče InQool, a.s. souhlasíme.

Nesmí být uloženy v plain textu či jakékoliv jiné čtivé metodě.
KS bude připraven na to, aby data v databázi mohla být uložena šifrovaně. Šifrování se v budoucnu může provádět prostředky databáze, operačního systému nebo prostředky aplikace KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Funkce Web Security – při napadení webu provozovatel (dodavatel) uvede web do poslední známé funkční a ověřené konfigurace se zabezpečením proti opakované zjištěné chybě.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Pokud systém KS bude provozován v infrastruktuře dodavatele, je nezbytné předložit ke schválení penetrační testy a jiné bezpečnostní opatření, zajišťující chod KS s ohledem na bezpečnost systému a jeho dat. Cílem VZ je taková realizace a nasazení KS, který bude provozován bezpečně s ohledem na stávající a budoucí aspekty doby z pohledu provozu IS v infrastruktuře zadavatele či provozovatele (dodavatele).	ANO	Za uchazeče InQool, a.s. souhlasíme.
Pokud systém KS bude provozován v infrastruktuře dodavatele je Zadavatel oprávněn provádět kontrolu nebo audit infrastruktury nebo samotné aplikace. Kontrola či audit může být prováděna třetí stranou. Dodavatel je povinen poskytnout veškerou součinnost včetně poskytnutí k náhledu interních materiálů vztahujících se k KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Služba KS a tedy webstránka (např. xxxxx://xx.xxx.xx), bude upřesněno zadavatelem a její zabezpečení pro šifrovanou síťovou komunikaci dle testu Qualys. SSL Labs SSL Server Test bude splňovat minimální známku A (score >= 80) dnem předání díla (akceptační kritérium). Test na adrese: xxxxx://xxx.xxxxxxx.xxx/xxxxxxx/	ANO	Za uchazeče InQool, a.s. souhlasíme.
SSL 2.0 není povolena.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Nezabezpečené vyjednávání (Insecure renegotiation) není povoleno.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Nesmí být zranitelný vůči útoku Heartbleed, OpenSSL CVE-2014-0224, CVE-2016-2107, nesmí se použít klíče pod 1024 bitů, použití Added DROWN testing, zranitelný vůči Ticketbleed (CVE-2016-9244), Zombie POODLE, GOLDENDOODLE, Zero Length Padding Oracle, Sleeping POODLE, odolnost vůči hrozbě Return Of Bleichenbacher's Oracle Threat, použití export suites grade, použity podpisy certifikátů MD5.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Doporučení dle SSL and TLS Deployment Best Practices týkající se služby KS tzn. protokolu Secure Sockets Layer (SSL) pro šifrovanou síťovou komunikaci. xxxxx://xxxxxx.xxx/xxxxxxx/xxxxxxxx/xxxx/XXX- and-TLS-Deployment-Best-Practices 1. Podpora protokolu TLS 1.1 nebo TLS 1.2 2. Key or DH parameter strength: >2048 bitů <= 4096 bits (e.g., 2048 nebo e.g., 4096)	ANO	Za uchazeče InQool, a.s. souhlasíme.

3. Cipher strength: >= 256 bits (e.g., 256)
Požadujeme plný administrátorský přístup pro určené zaměstnance CRR ke všem částem informačního systému. Zadavatel nebude provádět aktivní administraci systému. KS bude spravovat na své náklady dodavatel a má za funkčnost a řešení plnou odpovědnost. Jelikož bude systém provozován on-premise tak zadavatel si vyhrazuje právo definic provozních a bezpečnostních požadavků, aby byl systém bezpečně provozován v infrastruktuře zadavatele a neohrožoval jiné systémy.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Zadavatel bude na VM serverech pro provoz KS tzn. včetně databázového serveru používat nakonfigurovaný firewall a antivirovou ochranu a to v aktuálních verzích a aktualizacích. Detaily budou předmětem analýzy.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Vstupní datové zdroje
V této kapitole jsou popsána data, která nezadávají uživatelé KS, ale jsou nutná k provozu KS. Během realizace projektu může být doplněn omezený počet dalších datových zdrojů. Tyto datové zdroje bude KS primárně získávat voláním webových služeb. Záložním řešením je načtení ze souboru. • Geolokace veřejných IP adres Konfigurace seznamu obsahující rozsahy povolených/zakázaných adres. • Seznam OVM. Definice dle ZZR: § 2 písm. c) „ státní orgán, územní samosprávný celek a fyzická, nebo právnická osoba, byla-li jí svěřena působnost v oblasti veřejné správy.“ • Seznam platných i zneplatněných účtů • Nastavení firewallu. Data obsahují seznam veřejných IP adres, pro které jsou nastavené prostupy na firewallu.	ANO	Za uchazeče InQool, a.s. souhlasíme.
OBSAH DODÁVKY
Analýza
Prohloubení a dokončení analýzy provedené CRR s vybraným dodavatelem - upřesnění požadavků na aplikaci. Specifikace způsobu realizace požadavků. Obsahem realizace vybraného dodavatele je před-implementační analýza za plné součinnosti zadavatele.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Aplikace
• Aplikace je webová aplikace provozovaná bez doplňků na straně uživatelů. • Konzultační Servis je typově blízký HelpDesku/ServiceDesku, který je upraven na míru specifickému účelu Hlavním předmětem dodávky je fungující aplikace KS bez vad a nedodělků, která splňuje všechny požadavky a je nainstalovaná a připravená k rutinnímu provozu v cílovém produkčním i testovacím prostředí a je veřejně dostupná a funkční. Tedy včetně napojení na autentizační servery zadavatele metodou Single	ANO	Za uchazeče InQool, a.s. souhlasíme.

Sign On, a bude rovněž obsahovat rozhraní pro naplnění účty a správu účtů přímo v prostředí KS pro externí uživatele. Dodavatel bude aplikaci vyvíjet na vlastních prostředcích.
Software
Součástí dodávky je mimo vlastní aplikace veškerý potřebný software včetně služeb a prostředků pro svůj chod, operačních systémů, databázového systému, systémů pro zálohování KS včetně databází a antimalware (antivir) software. Dodavatel může využít pouze zmíněné licence zadavatele a HW prostředky: • Dodavatel smí využít výše uvedené HW prostředky zadavatele a stejně tak licence typu CAL pro vnitřní uživatele a OS Windows Server licenci pro podkladový OS KS. • Dále prostředky popsané v kapitole „Provoz KS“. Musí být dodán všechen potřebný software a všechny licence potřebné pro provoz KS bez omezení použití. Smí být použity free i licencované komponenty a produkty třetích stran, minimálně v rozsahu možnosti využití nových verzí a odstranění bezpečnostních chyb.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Zálohování
• Zadavatel garantuje 1x denně zálohu celého VM po dobu 14 dnů • Dodavatel zajistí separátně zálohu databáze a zálohu konfigurace služeb KS, stejně tak jako službu KS samotnou. • Záloha databáze pro KS bude v režimu minimálně 1x denně v 5 kopiích separátně od zálohy VM a zajistí ji dodavatel. Záloha bude uložena na prostředky Zadavatele.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Testování
Dodavatel provede v rámci dodávky následující typy testů: o Funkční. Tyto testy potvrdí, že byly implementovány funkční požadavky na aplikaci KS. o Uživatelské. Tyto testy potvrdí, že požadavky byly implementovány uživatelsky akceptovatelným způsobem. o Výkonové. Tyto testy potvrdí, že byly implementovány všechny výkonové požadavky. o Bezpečnostní. Tyto testy potvrdí, že byly implementovány všechny bezpečnostní požadavky. Dodavatel testy navrhne, tj. definuje testovací scénáře a jejich výsledky, CRR je případně doplní a schválí. Testy budou pokrývat případy užití externími i interními uživateli KS a funkční i nefunkční požadavky na řešení. Za dodavatele provede testy vyškolená osoba znalá architektury i fungování KS. Testování bude prováděno na produkční instanci KS. Zadavatel si vyhrazuje možnost	ANO	Za uchazeče InQool, a.s. souhlasíme.

testy v rozsahu dle svého uvážení provést nezávisle na dodavateli (vlastními silami či externím subjektem), přičemž za nevyhovující bude označen negativní výsledek testu bez ohledu na to, zda jej podle schváleného testovacího scénáře provedl dodavatel či zadavatel.
Pilotní provoz
Součástí řešení KS je podpora pilotního (ověřovacího) provozu. Dodavatel je povinen poskytovat po tuto dobu nepřetržitě přímou podporu uživatelům během pracovní doby CRR, bez zbytečného zdržení řešit problémy. Pilotní provoz bude na produkční instanci KS.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Migrace dat
Součástí řešení KS není migrace dat žádného systémů zadavatele vyjma částí autentizačních údajů vůči MS AD, které budou předmětem realizace.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Dokumentace - Analýza
Zadavatel v rámci realizace požaduje prohloubení a dokončení analýzy nutné k řádnému provozu služby KS v lokálním prostředí zadavatele. Zadavatel očekává a požaduje technickou i věcnou analýzu vytvořenou dodavatelem k provozu KS, kterou mu musí zadavatel schválit před samotnou realizací. Zadavatel se tímto zavazuje k plné součinnosti poskytnout informace nutné pro uvedení díla do běžného provozu. Výsledkem analýzy musí být detailní technický návrh celého řešení KS. KS musí být plně kompatibilní s prostředím CRR dle technických požadavků ICT na informační systémy. • Zadavatel požaduje pro dodávaný systém použití moderních technologií s podporou řešení třetích stran a to pro všechny části systémů, nejen služby KS. • Dodávané řešení musí respektovat bezpečnostní parametry v infrastruktuře zadavatele, specifické technické detaily dořeší dodavatel se zadavatelem v rámci analýzy a dále v rámci implementace. Zpracování v českém jazyce.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Dokumentace – Technický projekt
• Obsahem technického projektu je detailní technický návrh celého řešení KS. Jsou v něm specifikovány použité technologie a metodiky, je dokumentována struktura aplikace, případně specifikována všechna rozhraní aplikace na jiné systémy. • Aplikace bude popsána v UML. • Jsou definovány požadavky na hardware a software a seznam potřebných licencí s ohledem pro svůj provoz. Musí být specifikovány tak, aby pokrývaly veškeré potřeby pro realizaci projektu. • Jsou specifikovány požadované prostupy na firewallech, je popsána komunikace mezi	ANO	Za uchazeče InQool, a.s. souhlasíme.

komponentami jedné instance KS a mezi instancemi včetně odhadů datových objemů. Jsou v něm definovány nároky na parametry jednotlivých komunikačních kanálů (rychlost, latence). • Je v něm popsáno řešení správy aplikace KS. • Je v něm definován harmonogram realizace. • Jsou v něm specifikovány testovací scénáře a plán testů. • Popsána autentizační metoda Single Sign On a její technické řešení k uvedení do provozu. • Popsaný návrh bezpečnosti včetně autentizace interních i externích uživatelů aplikace. Zpracování v českém jazyce.
Dokumentace skutečného provedení
Obsahem tohoto dokumentu je popis implementace aplikace KS. Jsou definovány použité technologie a nastavení pro uvedené do provozu (IP adresy atd. a přesné schéma zapojení KS do počítačové sítě při nasazení v prostředí zadavatele). Je v ní popsáno připojení na dohledové nástroje zadavatele (SIEM) pokud zadavatel neurčí jinak. Je v ní popsán proces instalace aplikace na serveru včetně použitých komponent OS. Zpracování v českém jazyce.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Dokumentace z testování
Dokumentace provedených testů a jejich výsledků. Zpracování v českém jazyce.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Uživatelská dokumentace pro externí uživatele
Příručka pro subjekty využívající služby KS. Obsahuje mj. popisy rolí a jím přiřazených práv na využívání funkcionalit KS. Bude obsahovat i základní seznámení s KS a popis registrace a základní práce se systémem. Zpracování v českém jazyce.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Uživatelská dokumentace pro interní uživatele
Příručka pro zaměstnance CRR, kteří pracují s KS. Obsahuje mj. popisy rolí a jím přiřazených práv na využívání funkcionalit KS. Zpracování v českém jazyce.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Administrátorská dokumentace
Příručka pro správce KS. Obsahuje zejména: • Popis zálohování (Aplikace, její konfigurace a dat v databázi separátně). • Popis konfigurace a konfiguračních parametrů. Tj. návod na konfiguraci KS. • Návod na realizaci další jazykové mutace. • Popis a konfigurace nástrojů monitorujících a dohlížejících provoz KS a jejich propojení na monitoring a dohledy CRR. • Kompletní seznam administrátorských a systémových přístupových účtů nutných pro provoz KS. • Popis administrace uživatelů, rolí a	ANO	Za uchazeče InQool, a.s. souhlasíme.

přístupových práv. • Popis change managementu. Tj. jak instalovat aktualizace použitého software, jak nasazovat nové verze použitého software a vlastní aplikace. V rámci realizace se ujasní, kdo bude tyto činnosti vykonávat. Za funkčnost je vždy odpovědný dodavatel. • Jak nastartovat, zastavit a restartovat KS. • Postupy pro řešení problémů. • Zpracování uživatelského manuálu, zpracování krokových postupů běžné práce s programem. Zpracování v českém jazyce.
Provozní dokumentace
Dodavatel v rámci předání díla provede provozní monitoring systémů a předá výsledky formou dokumentace zadavateli. Vyhodnotí rizika, dopady a bezpečnost řešení a obeznámí s nimi zadavatele. Zpracování v českém jazyce.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Bezpečnostní dokumentace
Obsahuje zejména: o Bezpečnostní politika KS. o Popis obnovy ze záloh. o Havarijní plány pro databázi a tedy dat systému a provoz systému. o Dokumentace realizace aplikace z pohledu zákona o kybernetické bezpečnosti. Je popsáno, jak jsou implementovány požadavky zákona a souvisejících vyhlášek. o Bezpečnostní monitoring KS. Zpracování v českém jazyce.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Provedení školení
Součástí plnění jsou školení včetně školicí dokumentace: • Pro administrátory dodané aplikace. V délce min 2 dny po upřesnění zadavatele max. 3 dní v sídle CRR. • Školení všech interních uživatelů v délce min 0,5 den po upřesnění zadavatele max. 1 den v sídle CRR případně i pobočkách CRR v ČR. Max. však 10 školení/běhů celkově.	ANO	Za uchazeče InQool, a.s. souhlasíme.
Legislativní požadavky
• Informační systém musí splňovat požadavky dle platných a účinných právních předpisů České republiky a přímo vykonatelných předpisů Evropské unie. • Legislativní změny budou zahrnuty v paušálu servisní podpory, • Pokud v případech legislativních úprav v aplikaci, bude nutno doplnit nějakou funkcionalitu nebo modul, a dodavatel ji nabízí ve více variantách, bude v ceně servisní podpory dodáno řešení na nejvyšší kvalitativní úrovni nabízené dodavatelem, pokud objednatel výslovně neschválí nižší variantu. Součástí plnění bude dodávka i všech dalších modulů, které by byly	ANO	Za uchazeče InQool, a.s. souhlasíme.

potřebné pro funkčnost v nejvyšší kvalitě v souladu s legislativními požadavky.
Komunikace
Dodavatel umožní pro zadávání servisních požadavků administrátorů a jiných pověřených osob přístup na webový portál v podobě helpdesku, aby bylo možno dohledat všechny dříve zadané problémy a incidenty. Počet uživatelů nebude limitován.	ANO	Za uchazeče InQool, a.s. souhlasíme.

Příloha č. 3 – Minimální požadavky na strukturu a dostupnost informací z Konzultačního servisu na webu CRR

Příloha č. 4 – Požadavky na úroveň poskytovaných služeb (SLA) a na podporu Konzultačního servisu

1. Legislativní údržba

všech částí dodaného plnění - tj. závazek dodavatele udržovat předmět plnění v souladu s platnou legislativou po dobu platnosti a účinnosti smlouvy. Dodavatel se zavazuje v případě legislativních změn vždy zajistit včasné úpravy všech částí plnění tak, aby byly v souladu se změněnými právními předpisy k okamžiku jejich účinnosti a poskytnout upravené části zadavateli včetně zajištění nezbytných prací souvisejících s instalací nebo montáží vedoucích k zajištění souladu s legislativou.

2. Technická podpora

Technická podpora bude poskytována po dobu platnosti a účinnosti smlouvy. Dodavateli - poskytovateli služeb technické podpory bude umožněn zabezpečený vzdálený přístup k servisovaným a spravovaným zařízením a SW.

2.1. Obecné požadavky na organizaci technické (servisní) podpory

• Dodavatel umožní pro zadávání servisních požadavků administrátorů a jiných pověřených osob přístup na webový portál v podobě helpdesku, servicedesku či obdobným systémem, aby bylo možno dohledat všechny dříve zadané problémy a incidenty. Počet uživatelů nebude limitován.

• centrální místo pro oznamování všech servisních požadavků

• v případě použití telefonického zadání požadavku na technickou podporu musí být zajištěno lidskou obsluhou (příjem požadavku pouze automatem není akceptován),

• komunikace s dispečinkem technické podpory, stejně tak komunikace s řešiteli požadavků na technickou podporu musí být zajištěna v českém (případně slovenském) jazyce,

• příjem požadavku musí být umožněn několika nezávislými komunikačními cestami:

o prostřednictvím internetu (webové rozhraní, autentifikace pro oprávněné osoby na základě jména a hesla),

o telefonicky,

o e-mailem,

o datovou schránkou,

o případně faxem (není podmínkou),

• prostřednictvím internetu nebo e-mailu může být požadavek zadán i mimo níže uvedenou dobu pro příjem požadavku, lhůta pro reakci na něj se však v této době počítat nebude.

• zajištění nepřetržitého přístupu do systému pro evidenci požadavků pro oprávněné osoby zadavatele – možnost upřesnění požadavku v průběhu jeho řešení,

• umožnění přístupu k historickým datům o řešení požadavků na technickou podporu (2 roky zpětně online, další roky na vyžádání).

• požadované parametry poskytované podpory a SLA pro jednotlivé části celého řešení jsou uvedeny v souhrnné tabulce na konci kapitoly.

2.2. Služby

• Servisní služby

o diagnostika závady,

o odstraňování SW závad ve lhůtách uvedených v části SLA, případně závad vyplývajících z provozu na HyperV.

o obnovení funkčnosti ze zálohy nebo reinstalací SW či OS,

o otestování funkčnosti celého celku

o uzavření servisního požadavku po akceptaci zadavatele – zhotovení servisního protokolu,

o zaznamenání změn do technické provozní dokumentace,

o náklady související s poskytnutím servisního zásahu jsou zahrnuty v ceně služby, žádné další náklady (cestovné, příp. nocležné apod.) nebudou fakturovány,

o některé servisní služby mohou být zajištěny formou podpory výrobce software,

o uložení informací o provedení servisního zásahu do elektronického systému pro příjem a evidenci požadavků na technickou (servisní) podporu.

• Provozní správa

o Činnosti prováděné automaticky = nebude nutné zadávat požadavky na jejich provedení:

i. pravidelné prohlídky správné funkce spravovaných systémů a zařízení podle navržené a schválené architektury vytvořené na základě analýzy,

ii. poskytování informací o bezpečnostních rizicích,

iii. aplikace bezpečnostních oprav (vždy s předchozím souhlasem zadavatele),

iv. reinstalace nových verzí SW (vždy s předchozím souhlasem zadavatele),

v. poskytování informací o platnosti podpor výrobce pro jednotlivé zařízení/SW, upozorňování na případné ukončení doby podpory zařízení/SW ze strany výrobce.

o Požadavky na činnosti na:

i. příjem požadavku na provedení provozní správy v režimu dle definovaného SLA,

ii. provedení zálohy konfigurací/nastavení před provedením požadované provozní činnosti,

iii. ověření možných dopadů realizace požadavku na zachování funkcionality technologického celku, v případě existence rizik informování zadavatele požadavku o možných důsledcích provedení požadavku,

iv. provedení požadované činnosti provozního charakteru na vyžádání - (např. požadavku na změnu konfigurace, SW úpravu funkčnosti menšího rozsahu apod.)

v. po provedení požadavku otestování funkčnosti dotčeného technologického celku,

o Obecné požadavky:

i. zaznamenání změn do technické provozní dokumentace,

ii. náklady související s poskytnutím služeb provozní správy jsou zahrnuty v ceně služby, žádné další náklady (cestovné, příp. nocležné apod.) související s poskytnutím služby, nebudou fakturovány,

iii. formou této služby nebudou řešeny požadavky na servisní zásahy (viz výše),

iv. čas na realizaci požadavků na provozní správu nebude snižovat předplacené hodiny expertní podpory,

v. uložení informací o provedení provozního zásahu do elektronického systému pro příjem a evidenci požadavků na technickou (servisní) podporu

• Expertní podpora

o konzultační služby (telefonicky, emailovou komunikací, v lokalitě zadavatele),

o řešení problémů (telefonicky, emailovou komunikací, v lokalitě zadavatele),

o zajištění eskalace problémů na centra výrobců SW případně i HW,

o předkládání návrhů na rozvoj systémů - přidělení technického specialisty uchazeče (konzultanta), který bude mít přehled o provozovaných systémech, jejich architektuře a bude předkládat návrhy rozvoje a poskytovat konzultační služby související s provozem a rozvojem těchto technologií,

o zpracování oponentních posudků ke studiím, analýzám, technické dokumentaci předložených zadavatelem (nebo jeho partnerem) ovlivňujících provoz nebo rozvoj spravovaných technologií,

o možnost otestování nových technologií a technických řešení

o poskytování služeb v lokalitě zadavatele nebude mít dopad na cenu poskytované služby (cestovné a další náklady jsou zahrnuty v ceně služby),

o rozsah poskytovaných služeb expertní podpory 20 hodin měsíčně, nevyčerpané hodiny lze převádět neomezeně v rámci kalendářního roku,

o reporting poskytování expertní podpory.

• Provozní a uživatelská dokumentace

2.3. SLA

o vedení a udržování technické provozní dokumentace a uživatelské dokumentace v elektronické podobě,

o technická provozní dokumentace musí obsahovat strukturované základní technické a topologické údaje, zejména základní evidenční údaje SW, přístupová hesla a grafická schémata propojení včetně vazeb, platnosti podpor výrobců apod.), datovaný seznam změn v dokumentaci (chronologicky)

o pravidelná aktualizace technické provozní dokumentace a uživatelské dokumentace po provedených změnách,

o poskytování výstupů z technické provozní dokumentace oprávněným zástupcům zadavatele

• Pokud není určeno jinak, zásah za účelem řešení závady nebo podpory může být proveden vzdáleně nebo onsite.

• Klasifikace závad:

o A - Kritická závada = závada bránící zadavateli poskytovat hlavní předmět jeho činnosti (např. nemožnost KS využívat pro vážnou závadu/chybu – systém není dostupný pro interní uživatele nebo klienty (tazatele), nefunkční autentizace, nefunkční workflow a základní funkce systému, KS neobsahuje data či část dat – došlo k havárii ve vazbě na kontinuitu a členitost dat a další obdobné závažné chyby).

o B - Střední závada = funkčnost systému významným způsobem degradována nebo silně omezena, opakovaný výskyt závady, systém je pomalý a nereflektuje výkonnostní požadavky dle dokumentu technické specifikace, případně systém neposílá notifikace či logovací záznamy na navazující systémy zadavatele.

o C - Nízká závada = funkčnost systému vykazuje určité problémy bez výrazného dopadu na služby poskytované klientům zadavatele.

• Hodnotou 24x7 se rozumí nepřetržité poskytování služby (24 hodin denně, 7 dnů v týdnu, tedy 365 dnů v roce); -> funkčnost SW a vazba na HyperV.

Hodnotou 8x5 se rozumí poskytování v pracovních dnech v době-> platí pro servis Po, Út, St, Čt – 8,00 – 17,00

Pá – 8,00 – 15,00

• Počet požadavků na poskytnutí podpory nebude omezován.

SLA – závady
Část (modul)	Dostupnost služby	Příjem požadavku	Klasifikace závady	Doba reakce	Doba vyřešení
Konzultační Servis	24x7	24x7	A	2 hodin	6 hodin
			B	4 hodiny	12 hodin
			C	6 hodin	Do 48 hodin
SLA – požadavky na provozní správu	Dostupnost služby
			Doba reakce
	8x5	Příjem požadavku 8x5	Do konce následujícíh o pracovního dne

SLA – požadavky na expertní podporu	Dostupnost služby 8x5	Příjem požadavku 8x5
			Doba reakce
			Do konce následujícíh o pracovního dne
SLA – změny provozní dokumentace
Část (modul)	Dostupnost služby	Příjem požadavku	Doba reakce
Všechny	8x5	8x5	Do 5 pracovních dnů
SLA – požadavky na legislativní údržbu =lhůty, v jakých bude garantována změna v systémech dle platné legislativy.
Část (modul)	Dostupnost služby		Příjem požadavku	Doba vyřešení
Všechny části	8x5	8x5	K datu účinnosti změny

Příloha č. 5 – Technické řešení Konzultačního servisu

TECHNICKÁ ČÁST

Pro vyloučení všech pochybností Zadavatele a v souladu s požadavky kapitoly 7.2.5 zde uvádíme následující:

• Dodavatelem doplněnou Přílohu č. 1 Zadávací dokumentace přikládáme jako nedílnou přílohu této nabídky.

• Dodavatelem doplněnou Přílohu č. 2 Zadávací dokumentace přikládáme jako nedílnou přílohu této nabídky.

• Analýzu a návrh nabízeného řešení Konzultačního servisu přikládáme jako soubor strukturovaných kapitol níže.

• Seznam SW produktů či licencí třetích stran, které budou součástí plnění, přikládáme jako dedikovanou podkapitolu uvedenou na konci této kapitoly.

Úvodem zde jako uchazeč čestně prohlašujeme, že námi nabízené řešení splňuje všechny požadavky zadávací dokumentaci, a to i v případě, že nejsou v tomto dokumentu ze své povahy explicitně popsány.

Základní představení účastníka – společnosti

Společnost InQool a.s. vznikla v roce 2010 s jasnou vizí stát se silným technologickým hráčem

v České a Slovenské republice. Ve smyslu této vize stavíme technologie a interní metodiku vývoje sofware na místo hlavní konkurenční výhody. Během naší dlouholeté praxe jsme vypracovali postupy, jak aktivně vyhledávat, testovat a následně aplikovat moderní technologie do významných projektů.

Tento přístup nám umožňuje pro naše klienty dodávat prvotřídní sofware za konkurence schopných cenových podmínek.

Během naší praxe jsme si mimo technologického know-how vybudovali silné znalosti i v oblasti UX a produktového designu, kde pro velké zákazníky (například Slovak Telekom a.s.)

poskytujeme odborné konzultační a analytické služby v oblasti návrhu aplikací, produktů, akvizičních procesů a uživatelské přívětivosti. Ve spojení těchto dvou oblastí leží naše další konkurenční výhoda, kde umíme stavět nejen technologicky vyspělé a robustní systémy, ale zároveň systémy, kde se uživatelům dobře pracuje a ergonomie práce je na vysoké úrovni.

Naše služby poskytujeme v rámci širokého spektra robustních technologií, s jejichž využitím umíme zabezpečit našim klientům vysokou rychlost, maximální bezpečnost, flexibilitu a optimální náklady na údržbu a provoz našich IT řešení. Jsme významným dodavatelem informačních systémů pro veřejnou správu, kam ve velké míře zaměřujeme naše obchodní úsilí a vyvíjíme snahu technologicky inovovat a poskytovat nový přístup k dodávkám software.

Naše společnost se zaměřuje zejména na komplexní dodávky v těchto oblastech:

- Agendové a evidenční systémy,

- Registrové a procesní systémy,

- Datové platformy,

- Portálové řešení,

- Formulářové platformy,

- Open-source dodávky systémů.

Společnost InQool a.s. je od roku 2018 certifikovaná na komplexní vývoj informačních systémů dle ISO norem:

- ISO 9001:2015 – Quality management systems

- ISO 14001:2015 – Environmental management systems

- ISO 20000-1 – IT Service management systems

- ISO 27001 – Information security management

- ISO 31000:2018 – Risk management

Společnost inQool a.s. čítá přes 30 kořenových technologických zaměstnanců a včetně spolupracujících odborníků a kontraktorů se velikost týmu dostává přes 50 zaměstnanců.

Představení přístupu k řešení etap

Společnost InQool a.s. je od roku 2018 certifikována na komplexní vývoj informačních systémů dle ISO norem 9001:2015 – Quality management systems a 20000-1 – IT Service management systems. Tyto průmyslové standardy přímo upravují implementační procesy a procesy řízení kvality v rámci námi dodávaných projektů. Poskytují tedy Zadavateli zvýšenou jistotu, že implementace a kvalita dodávaného projektu bude na maximální možné úrovni.

Ve společnosti InQool a.s. již dlouhodobě úspěšně aplikujeme agilní metodiky vývoje. Tyto metodiky vývoje se obecně řídí veřejně dostupnými standardy, ale je stále potřeba jisté míry individualizace jak pro samotnou společnost, tak i pro realizovaný projekt. Všechny agilní metodiky se řídí dvanácti principy, ze kterých vybíráme ty nejvýznamnější pro kontext tohoto projektu:

• Nejvyšší prioritou je uspokojit zákazníka skrz rychlé a průběžné dodávání kvalitního software.

• Změnové požadavky jsou vítány, dokonce i v průběhu vývoje. Agilní procesy je zpracují tak, aby zákazníkovi přinášely konkurenční výhody.

• Nové verze software jsou dodávány v intervalech týdnů až měsíců.

• Lidé z businessu a vývojáři spolupracují každý den během celého projektu.

• Fungující software je hlavním měřítkem postupu vývoje.

• Průběžná pozornost věnovaná technické dokonalosti a dobrému návrhu posiluje agilní přístup.

• Tým v pravidelných intervalech vyhodnocuje svou práci a upravuje své postupy tak, aby byl co nejefektivnější.

Z praktického hlediska aplikujeme iterativní metodiku implementace software inspirovanou agilní metodikou Scrum. K organizaci práce na projektu používáme webovou aplikaci Trello a GitLab, která nám umožňuje efektivně komunikovat v rámci týmu a případně i vůči zákazníkovi. Zároveň všem členům realizačního týmu poskytuje rychlý přehled aktivity na projektu a řešených či blokujících problémů. Pro zlepšení kvality jsme do našeho vývojového procesu zakomponovali několik programovacích technik a konvencí:

• Vzájemné revize zdrojových kódů (tzv. peer review), kdy zejména významné a klíčové části aplikace jsou hloubkově revidovány různými odborníky z vývojového týmu a tím odhalovány potenciální slabiny nebo místa pro optimalizaci.

• Systém tzv. merge requestů, které přímo podporuje platforma GitLab. Jde o řízenou integraci programovacích změn, kdy jednotlivé změny jsou před jejich začleněním do hlavní větve zdrojových kódů vždy revidovány vedoucím pracovníkem (team leaderem) a když nedosahují požadované kvalitativní úrovně nebo vykazují chyby, jsou vráceny autorovi k dopracování. Tento proces je cyklický a v některých případech se může opakovat i víckrát, než je dosaženo požadované úrovně kvality stanovené projektem.

• Zejména v ladících a testovacích fázích vytváříme prostor pro pravidelný refaktoring. Jde o programátorský zásah, kdy se části zdrojových kódů, které prošly vícenásobnými nebo zásadními úpravami přeprogramují jako celek, pro zajištění čistoty a čitelnosti zdrojového kódu.

• Velký důraz klademe na automatizaci testů, tato probíhá pomocí nástroje TestLink a u komplexních informačních systémů pravidelně budujeme vyšší stovky testů. Samozřejmostí je dokumentace testovacích scénářů, ale až jejich dekompozice na elementární automatizovatelné celky a jejich spouštění během buildovacího a deployment procesu vytváří udržitelný proces řízení kvality.

Zdrojové kódy a další řídící dokumenty našich aplikací verzujeme, sdílíme a uchováváme za pomoci technologie Git. Součástí verzování jsou i tzv. changesety databáze, které uchovávají jednotlivé změny ve struktuře databáze nebo konfiguračních datech mezi verzemi zdrojových kódů (vedeny pomocí technologie Phinx). Nové verze k zákazníkům nasazujeme vzdáleně prostřednictvím tzv. pipelines platformy GitLab (nadstavby nad standardní Git repositář), v rámci kterých sestavují distribuční balíčky, které následně automaticky nebo na pokyn oprávněného uživatele nasazují na vzdálené aplikační servery. Jednotlivé distribuční body (tzv. release points) jsou v repositáři označeny indikátorem nové verze (i s číslem verze) a lze se k těmto distribučním bodům vracet (tzv. version rollback). Sběr uživatelských požadavků a feedbacku realizujeme již v raných fázích implementace (s následným kontinuálním přechodem do testovacích a produkčního režimu) pomocí systému helpdesk nad technologií OSTicket.

Přenos know-how

Pracovníci Zadavatele budou v rámci poskytování nutné součinnosti zapojeni do projektového týmu dodavatele pro účely transferu know-how. Kromě běžné pracovní komunikace na úrovni řídících schůzek navrhujeme zapojit pracovníky Zadavatele do procesů návrhu technického řešení a testování díla, které jsou dle našich zkušeností ideálním místem pro zahájení transferu know-how a následně do instalačních prací SW produktů, kdy se pracovníci zadavatele (zpravidla techničtí administrátoři) můžou seznámit s prostředním navrhovaného řešení in natura, a to ještě před zahájením jeho rutinního provozu. Chápeme, že toto může znamenat zvýšené nároky na součinnost Zadavatele, proto toto předkládáme jako návrh, který může, ale nemusí být ze strany Zadavatele akceptován.

Při vlastním transferu know-how klademe důraz na:

• Porozumění architektury navrhovaného řešení jako celku a jeho složení z dílčích elementů,

• Jednotnou terminologii projektu včetně jeho provozu vycházející z architektury navrhovaného řešení,

• Dokumentace zdrojového kódu vlastního portálu KS na základě předem odsouhlasené metodiky,

• Důslednou dokumentaci postupů a procesů tvorby aplikací a dokumentace včetně uživatelské, administrátorské, provozní a bezpečnostní.

Přenos know-how je taktéž účinnou obranou na vytvoření situace označované jako tzv. vendor lock. Při vlastním stanovení rozsahu nezbytných informací k předání budeme vycházet mj. z dokumentu Zakázkové právo v oblasti ICT a další aktuální témata, Informační list 1/2017, který vydal Úřad na ochranu hospodářské soutěže a kde je v kapitole IV. struktura vhodných témat, která plánujeme se zadavatelem vyjasnit v rámci úvodních pracovních schůzek pro nastavení optimálního procesu přenosu know-how.

Architektura informačního systému

Návrh architektury vychází z naší zkušenosti z obdobných informačních systému pro veřejnou správu a je postaven téměř výlučně na open-source technologiích. Největším dopadem tohoto přístupu je, že je zcela nezávislý na intenzitě využívání systému (či už z pohledu počtu uživatelů, množství dat, nebo sizingu HW infrastruktury). Do budoucna dává Zadavateli také jistotu, že provozní náklady budou drženy v rozumné ekonomické úrovni a také dává možnost perspektivně zapojovat více potenciálních dodavatelů. Oba faktory přispívají k optimálnímu provozu a širokým možnostem rozvoje celého dodaného systému, zejména taktéž eliminovat efekt tzv. vendor lock-in.

Modulárnost, škálovatelnost a vysoká dostupnost

Architekturu systému předpokládáme postavit na základě konceptu mikroslužeb (microservices), což je implicitně nejčistší forma modulárnosti systému. V principu se každá funkcionalita (kde to architektonicky dává smysl) implementuje jako služba, která poskytuje ostatním modulům (službám) definované elementární funkcionality na bázi publisher-consumer (ve volném překladu poskytovatel- konzument). Konkrétní implementace jednotlivých mikroslužeb je pro zbytek systému skryta (a de facto nezajímavá), což mimo jiné pomáhá k údržbě systému (formou průběžného refactoringu mikroslužeb), optimalizaci (zátěžové testy mikroslužeb) a škálování (jednotlivé mikroslužby lze distribuovat na dedikované virtuální stroje a zvýšit tím jejich výkon a stabilitu). Vysoká dostupnost z pohledu architektury je zajištěna implementací load balanceru nad technologií HAProxy (viz. LB1 v kapitolách níže) v kombinaci s podpůrnými databázovými technologiemi Patroni a Etcd (popis viz kapitoly níže).

Infrastrukturní model

Z pohledu infrastruktury předpokládáme provoz prostředí na prostředcích Zadavatele dle podmínek Zadávací dokumentace. Níže přikládáme model první verzi navrhované infrastruktury a topologie pro produkční prostředí. Samozřejmě předpokládáme precizování diagramu s technickými pracovníky Zadavatele během analytické fáze projektu

Uživatelské rozhraní aplikace

Pro realizaci díla využít generickou platformu iQ UAS 2.0 vytvořenou naší společností zaměřenou pro rychlou a jednoduchou tvorbu evidenčních a agendových systémů, koncept uživatelského rozhraní aplikace proto vychází z této platformy. V této kapitole uvádíme ukázky reprezentativních obrazovek z jiných informačních systémů, kde byla tato platforma použita.

Všechny role budou dílo používat ve svém webovém prohlížeči jako responsivní webovou aplikaci. Prvním krokem každého uživatele bude přihlášení (přes vazbu na Active Directory Zadavatele) a následný vstup do požadované agendy informačního systému. V dané agendě následně probíhá samotná uživatelská práce, se záznamy, procesy, formuláři, nastaveními atd. Níže uvádíme některé obecné náhledy uživatelského rozhraní, konkrétně z Evidenčního systému sbírkových předmětů, realizovaného pro zadavatele Zlínský kraj, a z Evidenčního systému národního archivního dědictví, realizovaného pro zadavatele Ministerstvo vnitra, obě s využitím předmětné technologické platformy.

Základním konceptem informačního systému KS bude jeho zasazení nad komponenty generické platformy iQ UAS 2.0. Externí uživatelé budou pracovat zejména s formuláři pro dotaz. Interní uživatelé s agendou jednotlivých dotazů, v rámci které budou na základě bezpečnostních oprávnění manipulovat s jednotlivými záznamy (dotazy). Zejména tedy přesouvat, přiřazovat řešitele, vkládat odpovědi na dotazy, publikovat dotazy a podobně. Z konceptuálního hlediska jde stále o práci s formuláři a jejich interaktivními prvky (číselníky, dynamickými poli atd.), agendovými záznamy, navázanými záznamy a jejich metadaty. Tímto způsobem budou plněna jednotlivé požadavky Zadavatele na předmět této veřejné zakázky, jejich faktické detailní precizování bude následně předmětem analytické fáze realizace veřejné zakázky.

Náhled úvodní obrazovky s výběrem evidencí, agend a registrů reprezentovaných tematickými ikonami dle výběru Zadavatele

Konfigurační nastavení barevného schématu a dalších uživatelských atributů pro zlepšení

ergonomie a komfortu práce v prostředí systému

Náhled pracovního prostředí komplexní evidenční agendy

Náhled editačního formuláře dílčí evidenční entity

Náhled ukázkového evidence (tabulkové zobrazení záznamů)

Náhled využití mechanismu záložek, pro zpřehlednění komplexních formulářů a procesů

Náhled jednoduchého formuláře, pro založení záznamu do registru

Náhled komplexního evidenčního formuláře

Přikládáme zde taktéž jednoduchou ukázku responzivity aplikace:

Standardní zobrazení (na šířku)

Responsivní zobrazení (na výšku)

Podporovaná koncová zařízení aplikace předpokládáme zejména všechny používané prohlížeče (Edge/IE, Chrome, Firefox či Opera) v jejich aktuálních verzích se zajištěním zpětné kompatibility s předchozími verzemi prohlížečů minimálně o jednu verzi oproti verzi aktuální v době zahájení vývoje díla (a dále dle podmínek Zadávací dokumentace).

Návrh řešení vybraných funkčních požadavků

V této kapitole uvádíme analýzu a demonstraci realizaci vybraných funkčních požadavků pro lepší představu Zadavatele o specifikách a výhodách nabízeného plnění.

Vyhledávání

Vyhledávací index bude postaven nad technologií Elastic Search 7.5 a bude poskytovat funkcionality vyhledávání, filtrování a řazení pro systém jako celek i pro jednotlivé registry a agendy. Z technologického hlediska je index technologie Elastic velice robustní a výkonný, umožňuje pracovat s velkým množstvím dat a používat různé operátory a klíčová slova a taktéž jejich kombinaci. V tabulkách níže uvádíme pro názornost jejich přehled:

Název	Význam	Použitelné pro pole obsahující
EQUALS	Hodnota se rovná	text, číslo, datum, binární hodnoty (příznaky)
CONTAINS	Hodnota obsahuje	text
START_WITH	Hodnota začíná na	text
END_WITH	Hodnota končí na	text
GT	Hodnota je větší než	číslo, datum
GTE	Hodnota je větší nebo rovna než	číslo, datum
LT	Hodnota je menší než	číslo, datum
LTE	Hodnota je menší nebo rovna než	číslo, datum
NOT_NULL	Hodnota je vyplněna	text, číslo, datum, binární hodnoty (příznaky)
AND	Zřetězí podmínky ve vztahu “a zároveň”	seznam podmínek
OR	Zřetězí podmínky ve vztahu “nebo”	seznam podmínek
NOT	Negace podmínky	podmínka

Název	Definice1	Význam	Použitelné pro pole obsahující
NOT_EQUALS	NOT_EQUALS x v = NOT (x EQUALS v)	Hodnota se nerovná	text, číslo, datum, binární hodnoty (příznaky)
NOT_CONTAINS	NOT_CONTAINS x v = NOT (x CONTAINS s)	Hodnota neobsahuje	text
NOT_START_WITH	NOT_START_WITH x v = NOT (x START_WITH s)	Hodnota nezačíná na	text
NOT_END_WITH	NOT_END_WITH x v = NOT (x END_WITH v)	Hodnota nekončí na	text
IS_NULL	IS_NULL x = NOT (NOT_NULL x)	Hodnota není vyplněna	text, číslo, datum, binární hodnoty (příznaky)
IN	IN x v[] = OR (x EQUALS v[1], x	Hodnota se rovná	text, číslo, datum,

1 Představuje logickou definici podmínky. V definicích jsou použity následující parametry:

• x - značí název pole

• v - značí uživatelem zadanou hodnotu

• v[] - značí seznam uživatelem zadaných hodnot

• <a, b> - značí uzavřený interval mezi číselnými hodnotami a, b

• (a, b) - značí otevřený interval mezi číselnými hodnotami a, b

	EQUALS v[2], ...)	jedné z vyjmenovaných	binární hodnoty (příznaky)
IN	IN x <a, b> = AND (x GTE a, x LTE b)	Hodnota je v rozmezí uzavřeného intervalu	číslo, datum
IN	IN x (a, b) = AND (x GT a, x LT b)	Hodnota je v rozmezí otevřeného intervalu	číslo, datum
NOT_IN	NOT_IN x v[] = AND (x NOT_EQUALS v[1], x NOT_EQUALS v[2], ...)	Hodnota se nerovná žádné z vyjmenovaných	text, číslo, datum, binární hodnoty (příznaky)
NOT_IN	NOT_IN x <a, b> = OR (x LT a, x GT b)	Hodnota je mimo rozmezí uzavřeného intervalu	číslo, datum
NOT_IN	NOT_IN x <a, b> = OR (x LTE a, x GTE b)	Hodnota je mimo rozmezí otevřeného intervalu	číslo, datum

Pro některé (zejména textové) operace budou taky k dispozici modifikátory operace:

Název	Význam	Použitelné pro operace
fuzzy	Zamlžené vyhledávání. Umožní ignorovat drobné rozdíly a překlepy.	EQUALS, CONTAINS, START_WITH, END_WITH
wildcard	Umožní zadávat speciální znaky jako “*” nebo “?” pro vyhledání dle nedefinovaných znaků	EQUALS, CONTAINS, START_WITH, END_WITH
regexp	Umožní vyhledávat dle regulárního výrazu	EQUALS, CONTAINS, START_WITH, END_WITH

Z uživatelského hlediska je potom vyhledávání a filtrování realizováno například následovně:

Náhled realizace fulltextového globálního vyhledávání pomocí jednoho vyhledávacího pole v horní části agendy. Filtrování, řazení a lokální vyhledávání je integrované přímo do tabulkového

zobrazení registru, resp. do filtrovacího panelu nad tabulkou.

Lokalizace

Pro potřeby lokalizace bude použita komponenta React-intl, která je součástí technologie React v níž bude postaveno uživatelské rozhraní nabízeného systému. Pro úplnost zde uvádíme i odkaz na tuto komponentu xxxxx://xxxxxx.xxx/xxxxxxxx/xxxxx-xxxx. Způsob užití této komponenty v rámci systému je následně jednoduchý a spočívá ve využití lokalizačních souborů, ve kterých je pro každý lokalizovaný řetězec aplikace uveden zobrazovaný text v dané lokalizaci. Aplikace následně využije lokalizační soubor odpovídající jazyku, který si uživatel v aplikaci vybral (případně ten, který se nastaví automaticky dle interních pravidel aplikace)

Logování, reporting

Jednotlivé komponenty systému standardně logují do systémového logu SYSLOG, přes který budou následně předávány do SIEM a Event Management systému Zadavatele. Pro zkvalitnění logování (a v návaznosti na něj i auditování) je použit návrhový vzor AuditObject a Spring AOP (viz. kapitola Popis použitých SW komponent systému).

Základní technologií pro generování reportingů je JasperReports, jednotlivé šablony běžných reportů jsou reprezentovány dokumenty balíku Microsoft Office, ve kterých se nachází tzv. placeholdery, které jsou nahrazeny daty ze systému. Speciálními případy reportů jsou zcela proprietární reporty, které obsahují množství algoritmů a pracují s obrovským počtem dat, tyto jsou generovány plně systémem a jsou konfigurovány pomocí konfiguračních souborů (dynamické reporty). Pro systémové a provozní reporty je možné vybrat jeden z těchto přístupů.

Bezpečnost, Zabezpečení, Šifrování

Pro zabezpečení komunikačních kanálů (interních i externích) je použita transportní vrstva SSL s využitím systémových certifikátů. Z pohledu komunikace externích systémů přes externí rozhraní předpokládáme, že každý obdobný systém bude disponovat certifikátem, jehož veřejná část je uložena v systému. Pro uložení předpokládáme v systému administrační část.

Seznam SW produktů či licencí třetích stran

Úvodem představujeme popis klíčových technologií (aplikačních, databázových, výkonnostních) provozovaných na jednotlivých infrastrukturních prvcích:

Název technologie	Popis technologie
PostgreSQL 11	PostgreSQL je robustní objektově-relační databázový systém. Je aktivně vyvíjen více než patnáct let a vydáván pod open-source licencí typu MIT. Má vynikající pověst pro svou spolehlivost a bezpečnost.
Patroni 1.6.3	Patroni je open-source nástroj, který umožňuje vytváření a správu PostgreSQL vysoce dostupných clusterů. Vydáván je pod open-source licencí MIT. Nástroj je implementován v jazyku Python. Může být použit pro úkony jako jsou replikace, zálohy a obnovy. Spolupracuje s nástroji Etcd a HAProxy pro dosažení vysoké dostupnosti.
Etcd 3.3.18	Etcd je distribuované "klíč-hodnota" úložiště, které poskytuje spolehlivé uložení dat napříč clustrem serverů. Vydáván je pod open-source licencí Apache 2. Etcd umožňuje bezpečnou volbu lídra během chyby sítě, nebo výpadku serveru, včetně samotného lídra.
HAProxy 2.1.0	HAProxy je volně šiřitelný software, který poskytuje vysoce dostupný load balancer a proxy server pro TCP a HTTP komunikaci mezi aplikacemi. Je psaný v jazyku C a poskytován pod licencí GNU GPL 2.
Barman 2.1	Barman je open source nástroj pod licencí GNU GPL 3 pro disaster recovery PostgreSQL databáze, napsaný v jazyce Python. Hlavní vlastnosti jsou katalogizace záloh, definice retenční politiky, PITR, archivování a komprese WAL souborů a záloh.

Icinga 2.11.2	Icinga je monitorovací nástroj pod licenci GNU GPL 2, prostřednictvím kterého se sleduje dostupnost a výkonnost serverů, sítě i aplikací. Slouží nejen pro monitoring, ale i pro aktivní hlášení chyb a generování reportů.
Java 11	Průmyslový standard pro tvorbu robustních serverových aplikací. Bude použita v její poslední stabilní verzi a v opensource edici.
React 16.12.0	React je open source technologie pro tvorbu dynamických uživatelských rozhraní na bázi javascriptu. Původním tvůrcem je společnost Facebook Inc., která ji využívá i u svých základních produktů.
Apache 2.4.41	Webový server zajištující publika uživatelských rozhraní jednotlivých části aplikace. Projekt Apache HTTP Server bol spuštěn ještě v roce 1995 a je stále průběžně inovován a modernizován, v dnešní době patří mezi špičku ve své oblasti.

Seznam licencí

	Všechny SW komponenty	Licence
Operační systém	CentOS 7 Standardní opensource systém	Open-source, bez vlastníka, bez omezení
Databázový systém	PostgreSQL 11, Etcd 3.3.18 Standardní opensource komponenty	Open-source, bez vlastníka, bez omezení
Aplikační, webový server	Apache 2.4.41 Standardní opensource komponenta	Open-source, bez vlastníka, bez omezení
Formulářový systém	iQ Forms 2.0 Standardní komerční produkt uchazeče	Autorské dílo uchazeče, licence dle podmínek smlouvy (bez omezení), vlastník licence bude zadavatel
Vyhledávací systém	ElasticSearch 7.5	Open-source, bez vlastníka, bez omezení

	Standardní opensource komponenta
IDM	Integrovaná správa uživatelů, rolí a oprávnění. Řešeno vývojem nad technologií Java 11	Autorské dílo uchazeče, licence dle podmínek smlouvy (bez omezení), vlastník licence bude zadavatel
Process management	Activiti 7 Standardní opensource komponenta v kombinaci s vývojem modulů na míru nad technologiemi Java 11 a React 16.12	Open-source, bez vlastníka, bez omezení
Portálová technologie	Java 11, React 16.12 Řešeno vývojem nad technologií Java 11 a React 16.12 v kombinaci s readymade komponenty uchazeče	Autorské dílo uchazeče, licence dle podmínek smlouvy (bez omezení), vlastník licence bude zadavatel
Reporty, Bussiness Intelligence	Jasper Reports 6.10 Standardní opensource komponenta v kombinaci s vývojem modulů na míru nad technologiemi Java 11 a React 16.12	Open-source, bez vlastníka, bez omezení. Moduly jako autorské dílo uchazeče, licence dle podmínek smlouvy (bez omezení), vlastník licence bude zadavatel
Integrační vrstva	Java 11 Řešeno vývojem nad technologií Java 11 v kombinaci s readymade komponenty uchazeče a ohledem na budoucí integraci na ESB Zadavatele	Autorské dílo uchazeče, licence dle podmínek smlouvy (bez omezení), vlastník licence bude zadavatel
Monitoring	Icinga 2.11.2 Standardní opensource komponenta	Open-source, bez vlastníka, bez omezení
Auditování	Springboot 2.2.2(Spring AOP + AuditObject stereotype)	Open-source, bez vlastníka, bez omezení. Moduly jako autorské dílo uchazeče, licence dle podmínek smlouvy (bez

	Standardní opensource komponenty v kombinaci s ověřenými návrhovými vzory(stereotypy) použitými v rámci vývoje jednotlivých modulů a komponent na míru nad technologií Java 11	omezení), vlastník licence bude zadavatel
Zálohování	Barman 2.1 Standardní opensource komponenty	Open-source, bez vlastníka, bez omezení
Testování	JUnit 5, TestLink 1.9.17, Selenium 3.141.59 Standardní opensource komponenty	Open-source, bez vlastníka, bez omezení
Zabezpečení	SSL/TLS, LetsEncrypt, OAuth 2.0 Standardní komponenty a služby	---
Vysoká dostupnost, škálování	HAProxy 2.1, Patroni 1.6.3 Standardní opensource komponenty	Open-source, bez vlastníka, bez omezení