SMLOUVA
SMLOUVA
o poskytnutí, implementaci a podpoře SW řešení IS ServiceDesk vč. příslušných licencí
uzavřená dle § 1746 odst. 2 zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „občanský zákoník“), a dle 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 „AutZ“), (dále jen „smlouva“), mezi:
Českou národní bankou
Na Příkopě 28
115 03 Praha 1
zastoupenou: Ing. Xxxxxxx Xxxxxxxxx, ředitelem sekce informatiky
a
Ing. Xxxxxxx Xxxxxxxx, ředitelem sekce správní IČO: 48136450
DIČ: CZ48136450
(dále jen „objednatel“ nebo „ČNB“)
a
SEAL IT Services, s.r.o.
zapsanou v obchodním rejstříku vedeném Mestským súdom v Bratislave III, oddíl Sro vložka č. 31208/B
sídlo/místo podnikání: Xxxxxxxx 0, 000 00 Xxxxxxxxxx, Xxxxxxxxx xxxxxxxxx
IČO: 35880872
DIČ: 2021855429
zastoupenou: Ing. Xxxxxxxxxx Xxxxxxxx č. účtu: 1104066180 / kód banky: 5500
(dále jen „poskytovatel“).
Článek I
Předmět smlouvy, místo plnění a provozní doba objednatele
1. Poskytovatel se touto smlouvou zavazuje pro objednatele zajistit nový informační systém ServiceDesk, tj. systém pro kontinuální správu procesů IT Service Management, Facility Management a dalších obdobných procesů správy v rámci objednatele (dále jen „SD“ nebo „IS SD“), který má nahradit stávající nástroj (původní IS ServiceDesk; dále jen „Původní SD“), a tento IS SD objednateli dodat, implementovat a konfigurovat (dále též „dílo“) tak, aby tento splňoval funkční a nefunkční požadavky uvedené v příloze č. 1 a byl proveden v souladu s akceptovanou realizační studií podle této smlouvy. Poskytovatel může:
a) části, moduly nebo jiné součásti IS SD samostatně dotvořit – doprogramovat specificky pro IS SD (dále jen „doprogramované části“),
b) jako části, moduly nebo jiné součásti IS SD užít programové prostředky (SW) nebo jiná autorská díla získaná od třetích osob, pakliže jsou tyto běžně dostupné na trhu (dále jen „doplněné části“),
musí tak však učinit tak, aby IS SD splňoval funkční a nefunkční požadavky uvedené v příloze č. 1 a byl proveden v souladu akceptovanou realizační studií podlé této smlouvy.
2. Za konfliktní chování doprogramovaných částí IS SD, doplněných částí IS SD a zbylých částí IS SD nese plnou odpovědnost poskytovatel. Doprogramované a doplněné části IS SD musí být doplněny nebo zahrnuty do IS SD takovým způsobem, aby tím objednateli nevznikaly dodatečné náklady finanční, personální ani jiného charakteru (např. fungování IS SD nesmí na základě uvedeného vyžadovat servisní zásahy třetích osob nebo speciální znalosti technické správy u pracovníků objednatele).
3. IS SD musí být plně funkční v systémovém prostředí objednatele, specifikovaném v příloze č. 2 v obou částech A i B (dále společně jako „příloha č. 2“), a musí systémovému prostředí objednatele odpovídat vč. prostředí testovacího, produkčního a vývojového (viz kap. 3.4.1 akceptované realizační studie). Uvedeným se v této smlouvě rozumí:
a) že poskytovatel akceptuje systémové prostředí objednatele včetně databázové platformy, a proto IS SD odpovídá obsahu přílohy č. 2 vyjma její části „varianta 2“; nebo
b) že poskytovatel akceptuje systémové prostředí objednatele s výjimkou databázové platformy, kterou dodá v rámci IS SD vlastní, a proto IS SD odpovídá obsahu přílohy č. 2 vyjma její části „varianta 1“ a databázová platforma se pro účely této smlouvy považuje za součást IS SD.
V obou případech se poskytovatel zavazuje poskytnout objednateli oprávnění k užívání díla
(licenci) v rozsahu uvedeném v čl. X.
4. Parametry a kód IS SD (vč. doprogramovaných a doplněných částí) musí být během implementace a konfigurace optimalizovány pro systémové prostředí objednatele (viz příloha č. 2). IS SD musí být realizován tak, aby implementace do systémového prostředí objednatele (viz příloha č. 2) a jeho konfigurace neohrozily fungování tohoto systémového prostředí jako celku ani jeho součástí nebo fungování a integritu dat dalších programových prostředků (SW), přítomných v systémovém prostředí objednatele (viz příloha č. 2).
5. IS SD ani jeho jakékoliv případné změny v rámci plnění podle této smlouvy (update, upgrade, patch, hotfix, modifikace, doplnění modulu atd.) nesmí obsahovat škodlivý software nebo známé zranitelnosti (dle seznamu OWASP TOP10 a CWE/SANS TOP 25) či skryté funkcionality nebo reklamu, ani poskytovatel nesmí svým dalším plněním podle této smlouvy nebo svou nečinností jinak zapříčinit, že IS SD bude škodlivý software nebo známé zranitelnosti (dle seznamu OWASP TOP10 a CWE/SANS TOP 25) či skryté funkcionality nebo reklamu obsahovat.
6. Poskytovatel bere na vědomí, že veškeré v této smlouvě a jejích přílohách (zejména v příloze č. 2) uvedené verze programových prostředků (SW) jsou orientační a mohou být během plnění aktualizovány na vyšší verze, resp. nahrazeny za přímé nástupce daných programových prostředků (SW); takovou aktualizaci, resp. nahrazení, však není poskytovatel oprávněn požadovat po objednateli. Poskytovatel rovněž bere na vědomí, že veškeré plnění dle této smlouvy je poskytováno za situace, kdy je IS SD provozován v systémovém prostředí
objednatele (viz příloha č. 2), ve kterém dochází k nasazování aktualizací (update / upgrade / patch / hotfix) programových prostředků (SW) a obměně technických prostředků (HW), včetně nahrazování programových prostředků (SW) jejich přímými nástupci. Poskytování plnění podle této smlouvy nesmí být uvedeným narušeno a IS SD (vč. doprogramovaných a doplněných částí) musí být uvedenému plynule přizpůsobován v rámci podpory běžného provozu dle čl. VI.
7. Objednatel bere na vědomí, že plnění dle odst. 10 písm. b) a c) tohoto článku nepokrývá situace, kdy IS SD vykáže vady v důsledku změny systémového prostředí objednatele (viz příloha č. 2) nad rámec popsaný v odst. 6 tohoto článku, např. je-li programový prostředek (SW) nahrazen zcela odlišným programovým prostředkem (SW) stejné funkce, avšak jiného výrobce a jiného mechanismu fungování. Takové vady se považují za vady prokazatelně způsobené objednatelem nebo třetími osobami na jeho příkaz, popř. jejich zaměstnanci.
8. Poskytovatel a objednatel prohlašují, že v rámci této smlouvy dochází ke zpracování osobních údajů poskytovatelem pro objednatele a podle jeho pokynů. Smluvní strany se proto zavazují uzavřít do 20 pracovních dnů od podpisu této smlouvy Ujednání o zpracování osobních údajů, jehož vzor je přílohou č. 3. Poskytovatel je rovněž povinen počínat si při nakládání s osobními údaji v souladu s platnými právními předpisy, zejména s nařízením 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ů), v platném znění.
9. Součástí díla je:
a) Vypracování a poskytnutí realizační studie v souladu s její šablonou dle přílohy č. 4 (dále jen „realizační studie“); obsah realizační studie musí umožňovat naplnění funkčních a nefunkčních požadavků uvedených v příloze č. 1, jakož i dalších požadavků na IS SD podle této smlouvy.
b) Vypracování a poskytnutí testovacích scénářů, které budou umožňovat kontrolu provedení dalších částí díla, v souladu s šablonou dle přílohy č. 5 (dále jen „testovací scénáře“). Testovací scénáře musí zejména umožňovat ověření:
i. naplnění všech funkčních a nefunkčních požadavků podle přílohy č. 1,
ii. shody IS SD s akceptovanou realizační studií,
iii. integrity dat v IS SD migrovaných z Původního SD podle písm. d) tohoto
odstavce,
iv. shody obsahu dokumentace podle písm. g) tohoto odstavce se skutečným fungováním IS SD,
v. dalších požadovaných vlastností IS SD podle této smlouvy.
Jeden testovací scénář může ověřovat naplnění více požadavků na dílo nebo IS SD.
c) Implementace IS SD do testovacího a vývojového prostředí (viz kap. 3.4.1 realizační studie) a konfigurace IS SD v testovacím prostředí objednatele (viz kap. 3.4.1 realizační studie) tak, aby uvedené odpovídalo systémovému prostředí objednatele (viz příloha č. 2).
d) Provedení migrace dat z Původního SD do IS SD (jak do testovacího prostředí, tak
do produkčního prostředí objednatele) ve shodě s akceptovanou realizační studií.
e) Implementace IS SD do produkčního prostředí objednatele (viz kap. 3.4.1 realizační studie) a konfigurace IS SD v produkčním prostředí objednatele (viz kap. 3.4.1 realizační studie), tak aby uvedené odpovídalo systémovému prostředí objednatele (viz příloha č. 2).
f) Zaškolení zaměstnanců objednatele ve lhůtách, o rozsahu a obsahu podle přílohy č. 6,
g) Vypracování a poskytnutí dokumentace IS SD (dále jen „dokumentace“) o rozsahu a obsahu podle přílohy č. 7.
h) Předání čitelného a kompletního zdrojového kódu doprogramovaných částí IS SD a konfiguračních souborů IS SD objednateli ve formátu čitelném IS SD nebo slovního popisu postupu konfigurace IS SD ve formátech editovatelných aplikacemi MS Word 2016 nebo MS Excel 2016, a to zasláním na e-maily pověřených osob objednatele nebo na obecně užívaném paměťovém médiu (např. CD, DVD, USB flashdisk) do podatelny objednatele v místě plnění.
10. Předmětem plnění podle této smlouvy je dále závazek poskytovatele zajišťovat další podporu
IS SD:
a) provoz hotline a helpdesk pro IS SD,
b) podporu běžného provozu IS SD,
c) odstraňování vad provozu IS SD,
d) rozšíření stávající licence pro IS SD,
e) provádění budoucího rozvoje IS SD.
11. Poskytovatel se zavazuje realizovat plnění podle této smlouvy zejména pod dozorem nebo přímo prostřednictvím určených techniků – odborníků (dále jen „odborník“ nebo
„odborníci“), jejichž seznam je volně připojenou přílohou č. 8, a to vždy s ohledem na konkrétní pozici odborníka podle uvedeného seznamu techniků. Poskytovatel může pro plnění této smlouvy užít i jiné své pracovníky, než uvedené odborníky, na požádání objednatele však musí konkrétní činnost nebo soubor činností vykonat osobně podle pozice příslušný z odborníků. V případě, že poskytovatel bude požadovat změnu v osobě odborníka uvedeného v seznamu techniků (příloha č. 8) nebo rozšíření seznamu techniků (příloha č. 8), navrhne to předem na e-maily pověřených osob objednatele. Součástí návrhu bude seznam techniků ve znění navrhovaných změn a prokázání kvalifikace odborníka v rozsahu bodu 8.3 písm. b) zadávací dokumentace zadávacího řízení „IS ServiceDesk“, evidenční číslo ve Věstníku veřejných zakázek: Z2023-045690, které předcházelo uzavření této smlouvy. Pověřená osoba objednatele schválí nebo odmítne návrh na e-mail, ze kterého byl návrh zaslán, a to do 10 pracovních dnů ode dne přijetí návrhu a s příslušným odůvodněním při odmítnutí návrhu. Přijetím návrhu se návrh seznamu techniků ve znění navrhovaných změn stává novou přílohou č. 8 a nahrazuje tak původní přílohu č. 8, a to bez povinnosti uzavírat dodatek k této smlouvě.
12. Místem plnění je sídlo objednatele na adrese: Xx Xxxxxxx 00, 000 00 Xxxxx 0.
13. Provozní dobou objednatele je:
a) pondělí až čtvrtek od 7:45 do 16:15 hodin;
b) pátek od 7:45 do 15:00 hodin; mimo svátky a dny pracovního klidu.
Veškerá plnění z této smlouvy, která je třeba provádět nebo jinak realizovat v místě plnění nebo za součinnosti objednatele, jeho zaměstnanců nebo jím určených třetích osob, musí být prováděna nebo jinak realizována ve stanovenou provozní dobu objednatele, nedohodnou-li se v konkrétním případě pověřené osoby smluvních stran jinak.
14. Veškerá komunikace dle této smlouvy bude vedena a veškerá plnění dle této smlouvy budou
poskytnuta v českém jazyce:
a) nebude-li pověřenými osobami smluvních stran v konkrétním případě dohodnuto jinak, a to bez povinnosti uzavírat dodatek k této smlouvě,
b) nebude-li se jednat o použití konkrétních názvů nebo odborných pojmů, nemajících v českém jazyce ekvivalent; na požádání pověřené osoby objednatele musí být takový název nebo pojem vysvětlen v českém jazyce;
c) nejde-li o výňatky zdrojového kódu/programového kódu/programovacího jazyka.
15. Poskytovatel bere na vědomí, že mu nebude, kromě výjimečných případů, o kterých rozhoduje pověřená osoba objednatele, umožněn vzdálený přístup k serverům objednatele.
16. Objednatel se zavazuje poskytnout poskytovateli součinnost dle dalších ustanovení této
smlouvy a zaplatit za poskytnutá plnění ceny dle čl. III.
Článek II
Lhůty, předání a převzetí díla
1. Dílo bude provedeno v následujících lhůtách:
a) Do 4 měsíců od podpisu smlouvy poskytovatel předá objednateli k akceptaci realizační studii, jejíž náležitosti jsou uvedeny v příloze č. 4, při naplnění podmínek podle kap. 1.1.1 přílohy č. 9.
b) Do 6 měsíců od akceptace realizační studie poskytovatel naplní podmínky zahájení akceptace díla podle kap. 1.2.1 přílohy č. 9.
c) Bylo-li dílo akceptováno s výhradami podle přílohy č. 9, pak ve lhůtách určených v akceptačním protokolu o akceptaci díla poskytovatel odstraní závady díla v tomto protokolu uvedené.
d) Do 1 měsíce od akceptace díla nebo akceptace díla s výhradami poskytovatel naplní podmínky zahájení ověřovacího provozu podle kap. 2.1.1 přílohy č. 9.
e) Do 1 měsíce od úspěšného ukončení ověřovacího provozu poskytovatel předá objednateli kompletní dílo, tedy zejména včetně kompletní dokumentace, obsahující komentář k zdrojovému kódu, a čitelného a kompletního zdrojového kódu samotného.
f) Bylo-li dílo podle odst. 2 tohoto článku převzato s výhradami, pak ve lhůtách určených v protokolu o předání a převzetí díla poskytovatel odstraní vady díla v tomto protokolu uvedené.
2. Dílo bude předáno na základě protokolu o předání a převzetí díla, který podepíše který alespoň jedna pověřená osoba za každou smluvní stranu. Pro protokol o předání a převzetí díla se použije vzor uvedený v části „Vzor předávacího protokolu“ přílohy č. 9. Vykazuje-li dílo v okamžiku předání vady, je převzato s výhradami a objednatel, po projednání s poskytovatelem, určí v protokolu o předání a převzetí díla pro každou z vad závaznou lhůtu pro její odstranění; lhůta může být stanovena i s odkládací podmínkou1; lhůta se nestanovuje pro neodstranitelné vady kategorie C.
3. Poskytovatel není oprávněn dílo předat a objednatel není povinen dílo převzít, nebyl-li
ověřovací provoz nebo poslední opakovaný ověřovací provoz ukončen úspěšně.
4. Lhůty uvedené v tomto článku, v příloze č. 9 a popř. v akceptačním protokolu o akceptaci díla nebo v protokolu o předání a převzetí díla, je oprávněna kterákoliv z pověřených osob objednatele, na písemnou a odůvodněnou žádost poskytovatele, přiměřeně okolnostem prodloužit, pokud poskytovatel objektivně nemohl pokračovat v plnění dle této smlouvy z důvodu, že mu objednatel neposkytl povinnou a nezbytnou součinnost, nebo z důvodu skutečností stojících na straně poskytovatele, které ani poskytovatel jednající s náležitou péčí nemohl předvídat a které sám nezpůsobil (včetně např. výpadku či zdržení v dodavatelsko- odběratelském řetězci, výpadku v pracovní síle poskytovatele z důvodu opatření uložených orgány veřejné moci, nikoli v důsledku protiprávního jednání poskytovatele, zdržení v plnění jiných smluvních partnerů objednatele, které se plnění dle této smlouvy dotýká a které nebylo způsobeno objednatelem). Písemná žádost poskytovatele musí obsahovat i návrh prodloužení lhůty, ten však není pro pověřené osoby objednatele závazný. Změna lhůty je účinná dnem jejího písemného oznámení kterékoliv z pověřených osob poskytovatele, a to bez povinnosti uzavírat dodatek k této smlouvě.
Článek III
Cena plnění a platební podmínky
1. Cena za dílo byla stanovena dohodou smluvních stran a činí 3 409 800,00 Kč bez DPH, z toho činí cena za zahrnutá školení 62 500 Kč bez DPH. V ceně díla je zahrnuta licence v rozsahu dle čl. X této smlouvy. V ceně díla jsou dále zahrnuty všechny náklady na zajištění databázové platformy, kterou dodá poskytovatel v rámci IS SD vlastní, pakliže postupuje podle čl. I odst. 3 písm. b).
2. Cena provozování hotline a helpdesk, za podporu běžného provozu a za odstraňování vad
provozu byla stanovena dohodou smluvních stran a činí čtvrtletně 51 450 Kč bez DPH.
3. Cena za rozšíření stávající licence bude stanovena vždy jako násobek ceny příslušného rozšíření za jednoho uživatele podle přílohy č. 12 a objednatelem požadovaného počtu uživatelů, o který se má rozšířit stávající licence.
1 Např. do 5 pracovních dnů poté, co výrobce programového prostředku (SW) vydá příslušný update nebo patch, nejpozději do 2 týdnů, nebude-li předán postup workaroundu, jinak do 6 měsíců atd.
4. Cena za provedení budoucího rozvoje bude stanovena vždy dohodou pověřených osob smluvních stran, a to na základě cenové nabídky poskytovatele zaslané na e-maily pověřených osob objednatele. Cenová nabídka bude kalkulována podle předpokládané pracnosti a hodinové sazby provádění budoucího rozvoje, která činí 1 500 Kč bez DPH. Cenová nabídka musí obsahovat odděleně pracnost provedení akceptace a/nebo ověřovacího provozu, pokud o jejich provedení požádal objednatel podle čl. IX odst. 8. V ceně je vždy zahrnuta licence v rozsahu dle čl. X této smlouvy, vč. jejích případných pozdějších rozšíření dle čl. VIII této smlouvy, vznikne-li v důsledku provádění budoucího rozvoje autorské dílo.
5. Ceny podle odst. 1 až 4 zahrnují veškeré náklady vzniklé poskytovateli v souvislosti s plněním podle této smlouvy a jsou konečné.
6. Cena díla bude hrazena takto:
a) objednatel poskytne zálohu ve výši 15 % z ceny díla bez DPH, nejvýše však 250 000 Kč na základě dokladu k úhradě, který je poskytovatel oprávněn vystavit nejdříve v den podpisu protokolu o akceptaci realizační studie,
b) objednatel poskytne zálohu ve výši 80 % ceny díla bez DPH na základě dokladu
k úhradě, který je poskytovatel oprávněn vystavit nejdříve v den podpisu protokolu
o akceptaci díla,
c) daňový doklad na úhradu ceny díla je poskytovatel oprávněn vystavit po podpisu protokolu o předání a převzetí díla. V daňovém dokladu budou vyúčtovány zálohy podle písm. a) a b) tohoto odstavce.
7. Cena podle odst. 2 bude hrazena na základě daňového dokladu, který je poskytovatel oprávněn vystavit vždy nedříve první den po konci třetího měsíce (dále jen „podporované čtvrtletí“), ve kterém bylo příslušné plnění poskytováno.
8. Cena podle odst. 3 bude hrazena na základě daňového dokladu, který je poskytovatel oprávněn vystavit vždy nejdříve v den rozšíření stávající licence.
9. Cena podle odst. 4 bude hrazena vždy na základě daňového dokladu, který je poskytovatel oprávněn vystavit vždy nejdříve v den, ve kterém bylo příslušné plnění poskytnuto (předáno a převzato). Přílohou daňového dokladu na cenu podle odst. 4 bude vždy kopie příslušného předávacího protokolu budoucího rozvoje.
10. Doklad k úhradě (fakturu) zašle poskytovatel elektronicky jako přílohu e-mailové zprávy na adresu xxxxxxx@xxx.xx ve formátu ISDOC. Pokud není možné vytvořit doklad ve formátu ISDOC, je možné zasílat jej ve formátu PDF. V jedné e-mailové zprávě smí být pouze jeden doklad k úhradě. Mimo vlastní doklad k úhradě může být přílohou e-mailové zprávy jedna až sedm příloh k dokladu ve formátech PDF, DOC, DOCX, XLS, XLSX. Přijaty budou i doklady k úhradě v jiném formátu, který bude v souladu s evropským standardem elektronické faktury. Nebude-li možné zaslat doklad k úhradě elektronicky, zašle jej poskytovatel v analogové formě na adresu:
Česká národní banka
sekce rozpočtu a účetnictví odbor účetnictví
Na Příkopě 28
115 03 Praha 1
11. Doklad k úhradě bude obsahovat údaje podle § 435 občanského zákoníku a bankovní účet, na který má být placeno a který je uveden v záhlaví této smlouvy nebo který byl později aktualizován poskytovatelem (dále jen „určený účet“). Daňový doklad bude nadto obsahovat náležitosti stanovené v zákoně o dani z přidané hodnoty. Nezbytnou náležitostí každého dokladu je také číslo této smlouvy (ve formátu ISDOC v poli ID ve skupině Contract References), nebo číslo objednávky (ve formátu ISDOC v poli External_Order_ID ve skupině OrderReference), jsou-li objednávky v rámci smlouvy vystavovány. Pokud doklad bude postrádat některou ze stanovených náležitostí nebo bude obsahovat chybné údaje, je objednatel oprávněn jej vrátit poskytovateli, a to až do lhůty splatnosti. Nová lhůta splatnosti začíná běžet dnem doručení bezvadného dokladu.
12. V případě, že bude v dokladu k úhradě uveden jiný než určený účet, je pověřená osoba poskytovatele povinna na základě výzvy objednatele sdělit na e-mailovou adresu, ze které byla výzva odeslána, zda má být zaplaceno na bankovní účet uvedený v dokladu, nebo na určený účet. V tomto případě se doklad k úhradě nevrací s tím, že lhůta splatnosti začíná běžet až dnem doručení sdělení poskytovatele podle předchozí věty.
13. Splatnost dokladu k úhradě je 14 dnů od doručení objednateli. Povinnost zaplatit je splněna odepsáním příslušné částky z účtu objednatele ve prospěch účtu poskytovatele.
14. Smluvní strany se ve smyslu ustanovení § 1991 občanského zákoníku dohodly, že je objednatel oprávněn započíst jakoukoli svou peněžitou pohledávku za poskytovatelem, ať splatnou či nesplatnou, oproti jakékoli peněžité pohledávce poskytovatele za objednatelem, ať splatné či nesplatné.
15. Poskytovatel je oprávněn navrhnout objednateli změnu cen podle odst. 2 až 4 tohoto článku v návaznosti na vývoj Indexu cen v tržních službách, stejné období předchozího roku = 100, konkrétně index J62 Služby v oblasti programování a poradenství a související služby, sloupec Průměr od počátku roku, a to průměr za předchozí kalendářní rok, který vyhlašuje Český statistický úřad. Úpravu cen je poskytovatel oprávněn navrhnout nejdříve po uplynutí dvou let ode dne nabytí účinnosti smlouvy. Úpravy cen budou prováděny písemnými dodatky ke smlouvě podepsanými oprávněnými zástupci obou smluvních stran.
16. Poskytovatel je oprávněn navrhnout objednateli změnu ceny podle odst. 2 tohoto článku v případě provedení budoucího rozvoje podle čl. IX odst. 1 písm. c) a e); xxxx podle odst. 2 tohoto článku může v takovém případě být změněna nejvýše o 2,5 % z ceny poskytnutého plnění, resp. předaného a převzatého budoucího rozvoje, přičemž návrh na změnu ceny podle odst. 2 tohoto článku musí být doručen objednateli spolu s nabídkou poskytovatele podle odst. 4 tohoto článku. Pro vyloučení pochybností strany výslovně sjednávají, že přijetí nabídky a provedení budoucího rozvoje není přijetím návrhu na změnu ceny; případná změna ceny podle odst. 2 tohoto článku bude provedena vždy dodatkem ke smlouvě, jehož účinnost nesmí předcházet podporovanému čtvrtletí, v němž došlo k poskytnutí plnění, resp. předání a převzetí budoucího rozvoje podle čl. IX odst. 1 písm. c) a e).
17. Poskytovatel je oprávněn navrhnout objednateli změnu ceny podle odst. 2 tohoto článku v případě rozšíření stávající licence podle čl. VIII; cena podle odst. 2 toto článku může v takovém případě být změněna nejvýše o 6,5 % z ceny poskytnutého plnění, resp. ceny za rozšíření stávající licence, přičemž návrh na změnu ceny podle odst. 2 tohoto článku musí být doručen objednateli nejpozději 10 pracovních dnů po určení rozsahu rozšíření pověřenou osobou objednatele podle čl. VIII odst. 1, musí předcházet dohodě o lhůtě poskytnutí rozšíření
stávající licence podle čl. VIII odst. 2 a poskytovatel v něm musí doložit, že v souvislosti s rozšířením stávající licence vzniknou poskytovateli náklady nad rámec platby třetí osobě za samotné rozšíření stávající licence vč. výše těchto nákladů. Pro vyloučení pochybností strany výslovně sjednávají, že rozšíření stávající licence není přijetím návrhu na změnu ceny; případná změna ceny podle odst. 2 tohoto článku bude provedena vždy dodatkem ke smlouvě, jehož účinnost nesmí předcházet podporovanému čtvrtletí, v němž došlo k poskytnutí plnění, resp. rozšíření stávající licence podle čl. VIII.
Článek IV Pověřené osoby
1. Smluvní strany si do 7 pracovních dnů ode dne uzavření této smlouvy vymění písemně seznamy pověřených osob, včetně jejich telefonického, e-mailového a případně faxového spojení. Seznam může obsahovat bližší určení rozsahu pověření jednotlivých pověřených osob nebo jejich skupin formou odkazů na konkrétní ustanovení této smlouvy (vč. příloh).
2. V případě změny pověřených osob smluvních stran nebo jejich kontaktních údajů jsou smluvní strany povinny nahlásit změnu následující pracovní den po provedení změny na e-mailové adresy pověřených osob druhé smluvní strany. Změna pověřených osob je účinná dnem jejího oznámení druhé smluvní straně, a to bez povinnosti uzavírat dodatek k této smlouvě.
Článek V
Hotline a helpdesk
1. Za účelem komunikace mezi objednatelem a poskytovatelem při poskytování podpory běžného provozu podle čl. VI, odstraňování vad provozu podle čl. VII a provádění budoucího rozvoje podle čl. IX poskytovatel:
a) Nejméně v provozní době objednatele podle čl. I odst. 13 poskytuje telefonický hotline dostupný na
b) Poskytuje helpdesk dostupný nepřetržitě na e-mailové adrese xxxxxxx@xxxxx.xx /
webovém odkazu xxxxxxx.xxxxx.xx.
c) Uchovává po dobu platnosti a účinnosti smlouvy záznamy o použití hotline a helpdesk takovým způsobem, aby bylo možno vyhovět požadavkům uvedeným v odst. 5 tohoto článku.
2. Veškerá komunikace mezi objednatelem a poskytovatelem prostřednictvím hotline a helpdesk probíhá v jazyce podle čl. I odst. 14 této smlouvy.
3. Služby hotline i helpdesk jsou zajišťovány odbornými pracovníky poskytovatele a v případě použíti telefonických automatů nebo umělé inteligence existuje přímá provolba na odborného pracovníka poskytovatele nejpozději v první volbě možností, resp. ve druhé volbě možností, je-li první volbou možností volba jazyka. Tato provolba nemusí být veřejná, musí však být objednateli poskytovatelem sdělena nejpozději při uzavření smlouvy a kdykoliv poté na žádost objednatele.
4. V případě změny telefonního čísla hotline nebo e-mailové adresy, webového odkazu nebo obdobného kontaktního údaje podle odst. 1 písm. a) nebo b) tohoto článku nahlásí poskytovatel takovou změnu 5 pracovních dnů předem na e-mailové adresy pověřených osob objednatele.
Změna je účinná 6. pracovním dnem po jejím oznámení, a to bez povinnosti uzavírat dodatek
k této smlouvě.
5. Hotline i helpdesk musí obsahovat:
a) Systém pro automatické potvrzení o provedení komunikace (hlášení vady, požadavku, konzultaci), který nejpozději do 2 hodin od provedení komunikace potvrdí tuto skutečnost a obsah komunikace e-mailovou zprávou na e-mail ohlašovatele a další zadané e-mailové adresy; celá historie případu je také dostupná přes helpdesk poskytovatele pod přístupovými údaji ohlašovatele z webu xxxxxxx.xxxxx.xx; půjde-li
o komunikaci prostřednictvím hotline, může potvrzení obsah pouze shrnovat.
b) Systém pro zaznamenání navazující komunikace až do ukončení komunikace s ohledem
na předmět (vyřešení vady, vyřešení požadavku, ukončení konzultace).
c) Řízený přístup pověřených osob objednatele k záznamům podle odst. 1 písm. c) tohoto článku, resp. podle písm. a) a b) tohoto odstavce.
d) Možnost pro pověřené osoby objednatele vyžádat si poskytnutí sumarizačního reportu všech záznamů podle odst. 1 písm. c) tohoto článku, resp. podle písm. a) a b) tohoto odstavce.
e) Možnost pro pověřené osoby objednatele exportovat si všechny záznamy o použití hotline a helpdesk podle odst. 1 písm. c) tohoto článku, resp. podle písm. a) a b) tohoto odstavce.
Článek VI Podpora běžného provozu
1. Podporu běžného provozu počíná poskytovatel poskytovat okamžikem předání a převzetí díla. Pakliže postupuje poskytovatel podle čl. I odst. 3 písm. b), zajišťuje podporu běžného provozu též pro databázovou platformu, kterou dodá poskytovatel v rámci IS SD vlastní a která se proto pro účely této smlouvy považuje za součást IS SD.
2. Poskytovatel zajišťuje objednateli podporu běžného provozu IS SD, v jejímž rámci
poskytovatel:
a) Aktivně a za podmínek podle čl. I odst. 2 a 5 (v průběžně aktualizovaném systémovém prostředí objednatele, viz příloha č. 2) zajišťuje objednateli, že si IS SD zachová vlastnosti podle čl. I odst. 1, 3 až 5 a přílohy č. 1 a rovněž vlastnosti získané v rámci rozšíření stávající licence pro IS SD podle čl. VIII nebo budoucího rozvoje podle čl. IX; poskytovatel tak činí též prostřednictvím odstraňování vad provozu podle čl. VII.
b) Udržuje metodickou a technologickou jednotnost a konzistentnost všech prvků IS SD.
c) Informuje objednatele o všech připravovaných a realizovaných změnách IS SD.
d) Obstarává objednateli všechny na trh či jinak uvolněné aktualizace (update / upgrade / patch / hotfix) IS SD (vč. aktualizací, které musí opatřit od třetích stran, a bez ohledu na to, zda se jedná o aktualizace k opravám chyb nebo o aktualizace zavádějící nové funkce) včetně aktualizací (update / upgrade / patch / hotfix ) všech doplněných částí IS SD, a to včetně doplněných částí IS SD zahrnutých do IS SD v rámci rozšíření stávající licence pro IS SD podle čl. VIII nebo budoucího rozvoje podle čl. IX; poskytovatel tak
činí včetně poskytnutí licence objednateli v rozsahu podle čl. X, popř. v rozsahu
podle čl. X rozšířeném podle čl. VIII, a bez dalších nákladů pro objednatele.
e) Poskytuje konfigurační soubory nebo instrukce pro plnou konfiguraci všech částí IS SD po aktualizaci IS SD nebo jakékoliv jeho části.
f) Aktualizuje dokumentaci IS SD, dojde-li v rámci plnění této smlouvy k takové změně IS SD, že dokumentace IS SD neodpovídá skutečnosti, popř. vyjde-li v rámci plnění této smlouvy najevo, že dokumentace IS SD neodpovídá skutečnosti.
g) Je-li to potřeba pro řádný průběh, poskytuje samostatnou dokumentaci k:
i. aktualizaci IS SD nebo jakékoliv jeho části,
ii. rozšíření stávající licence pro IS SD,
iii. aplikaci výsledků budoucího rozvoje IS SD,
iv. jiné výrazné změně IS SD (např. aktualizace spojená s aktualizací systémového prostředí objednatele),
která obsahuje především popis obsahu aktualizace, rozšíření nebo rozvojové instalace, postup jejich instalace a implementace do IS SD a postup následné konfigurace IS SD, není-li to zajištěno konfiguračním souborem podle písm. e) tohoto odstavce.
h) Zajišťuje objednatelem požadované drobné úpravy IS SD a provozní konzultace ve spojení s IS SD nebo fungováním IS SD, a to v rozsahu 48 člověkohodin za podporované čtvrtletí podpory běžného provozu. Nevyužité celé člověkohodiny, vč. člověkohodin již dříve převedených, se převádějí do následujícího podporovaného čtvrtletí poskytování podpory běžného provozu.
Časovou náročnost požadované drobné úpravy je poskytovatel povinen sdělit objednateli před jejím provedením. Doprava do a z místa plnění se do časového fondu nezapočítává. Pokud časová náročnost požadované drobné úpravy přesáhne časový fond podle tohoto písmene, upozorní na to poskytovatel objednatele a úpravu neprovede, dokud časový převis nezajistí objednatel formou objednávky v rámci provádění budoucího rozvoje podle čl. IX.
Pokud dojde během poskytování provozní konzultace k vyčerpání časového fondu podle tohoto písmene, je na to zaměstnanec poskytovatele povinen objednatele upozornit a konzultaci ukončit.
i) Pokud výrobce IS SD, resp. některé jeho části (zejména doplněné části IS SD), poskytuje službu přístupu do neveřejné databáze znalostí nebo k neveřejnému fóru ohledně předmětného IS SD, resp. jeho předmětné části, zajišťuje poskytovatel objednateli přístup k uvedenému po celou dobu platnosti a účinnosti této smlouvy.
3. Plnění podle tohoto článku probíhá:
a) přímým působením pracovníků poskytovatele na IS SD v prostředí objednatele
(viz příloha č. 2 této smlouvy), v místě plnění podle čl. I odst. 12,
b) zasíláním informací, materiálů nebo souborů na e-maily pověřených osob objednatele,
c) ukládáním informací, materiálů nebo souborů na úložiště určené pro tento účel pověřenou osobou objednatele, čímž nesmí poskytovateli vzniknout žádné dodatečné náklady,
d) doručením informací, materiálů nebo souborů do podatelny ČNB Praha v místě plnění podle čl. I odst. 12, a to na obecně užívaném paměťovém médiu (např. CD, DVD, USB flashdisk),
e) komunikací prostřednictvím helpdesk nebo hotline,
f) poskytnutím přístupových údajů k neveřejné databázi znalostí nebo k neveřejnému fóru, nebo
g) e-mailovou komunikací mezi pověřenými osobami poskytovatele a objednatele,
není-li touto smlouvu nebo písemnou dohodou pověřených osob poskytovatele a objednatele
pro konkrétní případ stanoveno jinak, a to bez povinnosti uzavírat dodatek k této smlouvě.
4. Plnění podle tohoto článku poskytuje poskytovatel v následujících lhůtách:
a) Plnění podle odst. 2 písm. a) a b) průběžně, resp. bez zbytečného odkladu poté, co tak může s ohledem na okolnosti v jednotlivých případech učinit (např. obdrží informaci o připravované změně IS SD), popř. ve lhůtách k tomu určených dále v této smlouvě u odstraňování vad provozu podle čl. VII.
b) Plnění podle odst. 2 písm. c) bez zbytečného odkladu, nejpozději však do 3 pracovních dnů poté, co sám informaci o připravované nebo realizované změně získal.
c) Plnění podle odst. 2 písm. d) bez zbytečného odkladu po uvolnění aktualizace (na trh či jinak). Nesplní-li poskytovatel svou povinnost podle odst. 2 písm. d) ani do 20 pracovních dnů od uvolnění aktualizace (na trh či jinak), je objednatel oprávněn obstarat si toto plnění od třetí osoby a náklady na jeho zajištění požadovat po poskytovateli. Pověřené osoby poskytovatele a objednatele se mohou pro konkrétní případ písemně dohodnout jinak, a to bez povinnosti uzavírat dodatek k této smlouvě.
d) Plnění podle odst. 2 písm. e) společně s příslušnou aktualizací IS SD, která si takové plnění vyžádala. Nesplní-li poskytovatel svou povinnost podle odst. 2 písm. e) ani do 20 pracovních dnů po příslušné aktualizaci IS SD, je objednatel oprávněn obstarat si toto plnění od třetí osoby a náklady na jeho zajištění požadovat po poskytovateli. Pověřené osoby poskytovatele a objednatele se mohou pro konkrétní případ písemně dohodnout jinak, a to bez povinnosti uzavírat dodatek k této smlouvě.
e) Plnění podle odst. 2 písm. f) bez zbytečného odkladu poté, co došlo ke změně IS SD, která si takové plnění vyžádala, nebo poté, co bylo zjištěno, že dokumentace IS SD neodpovídá skutečnosti. Nesplní-li poskytovatel svou povinnost podle odst. 2 písm. f) ani do 20 pracovních dnů po předmětné změně IS SD či zjištění, je objednatel oprávněn obstarat si toto plnění od třetí osoby a náklady na jeho zajištění požadovat po poskytovateli. Pověřené osoby poskytovatele a objednatele se mohou pro konkrétní případ písemně dohodnout jinak, a to bez povinnosti uzavírat dodatek k této smlouvě.
f) Plnění podle odst. 2 písm. g) nejpozději 3 pracovní dny předtím, než má dojít
ke změně IS SD, o jejíž samostatnou dokumentaci se jedná. Prodlením v této lhůtě
nejsou dotčeny žádné lhůty ani doby podle této smlouvy. Pověřené osoby poskytovatele a objednatele se mohou pro konkrétní případ písemně dohodnout jinak, a to bez povinnosti uzavírat dodatek k této smlouvě.
g) Plnění podle odst. 2 písm. h) bezprostředně při komunikaci prostřednictvím hotline, jde-li o provozní konzultaci, nebo po dohodě pracovníků poskytovatele a objednatele, jde-li o požadované drobné úpravy nebo provozní konzultaci mimo hotline; nedohodnou-li pracovníci poskytovatele a objednatele, určí lhůtu poskytnutí závazně pověřená osoba objednatele na e-maily pověřených osob poskytovatele a poskytovatel je povinen takové určení přijmout, není-li lhůta kratší než 12 pracovních dnů od okamžiku zaslání takového určení poskytovateli.
h) Plnění podle odst. 2 písm. i) nejpozději s předáním a převzetím díla, resp. té jeho části v rámci budoucího rozvoje podle čl. IX, jíž se povinnost týká.
Článek VII
Odstraňování vad provozu
1. Podporu odstraňováním vad provozu IS SD počíná objednatel poskytovat okamžikem předání a převzetí díla. Pakliže postupuje poskytovatel podle čl. I odst. 3 písm. b), zajišťuje odstraňování vad provozu též pro databázovou platformu, kterou dodá poskytovatel v rámci IS SD vlastní a která se proto pro účely této smlouvy považuje za součást IS SD.
2. Poskytovatel se zavazuje po dobu platnosti a účinnosti této smlouvy odstraňovat vady v celém IS SD, včetně doprogramovaných částí a doplněných částí, a to včetně doplněných částí IS SD zahrnutých do IS SD v rámci rozšíření stávající licence pro IS SD podle čl. VIII nebo budoucího rozvoje podle čl. IX. V případě, že po dobu účinnosti této smlouvy přestane IS SD vykazovat vlastnosti podle čl. I odst. 1, 3 až 5 a přílohy č. 1, nebo vlastnosti získané v rámci rozšíření stávající licence pro IS SD podle čl. VIII nebo budoucího rozvoje podle čl. IX, popřípadě dojde ke konfliktnímu chování jednotlivých částí IS SD nebo bude zjištěno narušení integrity dat IS SD, zavazuje se poskytovatel:
a) Jedná-li se o havárii:
• do 8 hodin od ohlášení vady v rámci provozní doby objednatele vadu odstranit
nebo nalézt a implementovat dočasné řešení vady (workaround);
• do 5 pracovních dnů od ohlášení vadu odstranit za pomoci trvalého řešení.
Havárie je vada, která znemožňuje či kriticky narušuje práci s IS SD. Havárií je zejména:
• IS SD je zcela nefunkční – všechny funkcionality jsou nefunkční nebo je nelze ovládat,
• funkce IS SD, na které je objednatel závislý a jejíž výpadek má okamžitý a kritický dopad na činnost objednatele, nepracuje a neexistuje způsob, jak funkci dočasně provádět náhradním způsobem bez významných časových nebo osobních nákladů objednatele, nebo zcela bez finančních nákladů pro objednatele,
• IS SD při svém fungování zapříčiňuje ohrožení provozu nebo dostupnosti ostatních programových prostředků (SW) nebo technických prostředků (HW) v prostředí objednatele,
• IS SD bezprostředně ohrožuje bezpečnost objednatele (např. neodpovídá požadavkům podle přílohy č. 10), resp. je možné jeho provozování označit za bezpečnostní riziko,
• IS SD má omezenou funkcionalitu takovým způsobem, že je omezením zasažen významný počet uživatelů (jsou-li mezi uživateli rozdíly v oprávněních, vztahuje se pojem „významný počet uživatelů“ též k jednotlivým skupinám uživatelů s různícími se oprávněními),
• došlo ke ztrátě dat uložených v IS SD,
• IS SD není schopen zpracovávat běžnou provozní zátěž.
b) Jedná-li se o významnou vadu:
• do 2 pracovních dnů od ohlášení vady tuto odstranit nebo nalézt
a implementovat dočasné řešení vady (workaround);
• do 10 pracovních dnů od ohlášení vady tuto odstranit za pomoci trvalého řešení. Významnou vadou je vada, která podstatně ztěžuje práci s IS SD. Významnými vadami
jsou zejména:
• funkce IS SD, na které je objednatel závislý, nepracuje, avšak dopad na činnost objednatele je buď zpožděný, nebo je jen méně závažný, a zároveň existuje způsob, jak výpadek funkce dočasně vyřešit organizačním či jiným opatřením, aniž by uvedené neslo jakékoliv finanční nebo významné časové nebo osobních náklady pro objednatele,
• IS SD ohrožuje bezpečnost objednatele (např. neodpovídá požadavkům podle přílohy č. 10), resp. je možné jeho provozování označit za bezpečnostní riziko,
• IS SD má omezenou funkcionalitu takovým způsobem, že je omezením zasažen malý počet uživatelů (jsou-li mezi uživateli rozdíly v oprávněních, vztahuje se pojem „malý počet uživatelů“ též k jednotlivým skupinám uživatelů s různícími se oprávněními),
• IS SD nebo některou z jeho doplněných částí není objednatel oprávněn užívat, resp. poskytovatel k IS SD nebo některé jeho doplněné části nezajistil objednateli oprávnění k užívání díla (licenci), v rozsahu uvedeném v čl. X nebo v rozsahu rozšířeném podle čl. VIII,
• IS SD není schopen zpracovávat maximální provozní zátěž.
c) Jedná-li se o ostatní vadu:
• do 20 pracovních dnů od ohlášení vady vadu odstranit za pomoci trvalého řešení.
Ostatní vadou je vada, která má pouze velmi omezený vliv na fungování IS SD a všechny ostatní vady, které nejsou vadami kritickými nebo podstatnými. Ostatními vadami jsou zejména:
• IS SD má komplikované využití některé funkcionality,
• IS SD může potenciálně zapříčinit dočasné omezení provozu nebo dostupnosti ostatních programových prostředků (SW) nebo technických prostředků (HW) v prostředí objednatele, resp. může tyto dočasně vytížit nad míru obvyklou,
• IS SD je v nesouladu s dokumentací,
• IS SD (nikoliv informace v něm obsažené) obsahuje pravopisnou nebo gramatickou chybu, překlep nebo nevhodné formátování.
O kategorizaci vady rozhodne objednatel, resp. zaměstnanec objednatele, v rámci jejího hlášení. Proti kategorizaci vady může poskytovatel podat námitku e-mailem pověřeným osobám objednatele; lhůty ani doby podle této smlouvy nejsou námitkou dotčeny. V případě námitky kterákoli pověřená osoba objednatele rozhodne o kategorizaci vady s konečnou platností.
3. Pověřená osoba objednatele hlásí vady IS SD poskytovateli prostřednictvím hotline nebo helpdesk.
4. Písemnou dohodou pověřených osob poskytovatele a objednatele může být pro konkrétní případ odstranění vady stanovena odkládací podmínka2, do jejíhož naplnění nebo odvolání se staví běh lhůt a dob podle tohoto článku, které s předmětnou konkrétní vadou bezprostředně souvisejí, a to bez povinnosti uzavírat dodatek k této smlouvě. Odkládací podmínka se považuje za naplněnou, je-li zmařena možnost jejího naplnění, přičemž poskytovatel nese riziko vyšší moci, nebo rozhodne-li tak pověřená osoba objednatele spolu s písemným odůvodněním zaslaným na e-maily pověřených osob poskytovatele.
5. Poskytovatel bere na vědomí a souhlasí, že podpora odstraňováním vad provozu podle tohoto článku je poskytována za podmínek podle čl. I odst. 2 a 6 (v průběžně aktualizovaném systémovém prostředí objednatele, viz příloha č. 2). Poskytování podpory odstraňováním vad provozu nesmí být uvedeným narušeno.
6. Objednatel bere na vědomí, že podpora odstraňováním vad provozu podle tohoto článku nepokrývá situace, kdy IS SD vykáže vady v důsledku změny systémového prostředí objednatele (viz příloha č. 2) nad rámec popsaný v čl. I odst. 6, např. je-li programový prostředek (SW) nahrazen zcela odlišným programovým prostředkem (SW) stejné funkce, avšak jiného výrobce a jiného mechanismu fungování. Takové vady se považují za vady prokazatelně způsobené objednatelem nebo třetími osobami na jeho příkaz, popř. jejich zaměstnanci.
2 Např. do doby, než výrobce programového prostředku (SW) vydá příslušný update nebo patch atd.
Článek VIII Rozšíření stávající licence
1. Poskytovatel se zavazuje po dobu platnosti a účinnosti této smlouvy poskytovat objednateli rozšíření stávající licence podle čl. X této smlouvy vždy o takový počet uživatelů s oprávněním zadat a schválit požadavek (zadavatelé) a/nebo uživatelů s oprávněním zadat, schválit a řešit požadavek (řešitelé), který určí pověřená osoba objednatele písemně na e-mail pověřených osob poskytovatele.
2. Rozšíření licence poskytovatel poskytne objednateli ve lhůtě podle dohody pracovníků poskytovatele a objednatele; nedohodnou-li se pracovníci poskytovatele a objednatele, určí lhůtu poskytnutí závazně pověřená osoba objednatele na e-maily pověřených osob poskytovatele a poskytovatel je povinen takové určení přijmout, není-li lhůta kratší než 1 měsíc od okamžiku zaslání takového určení poskytovateli.
3. Rozšíření licence podle tohoto článku je možné i opakovaně.
4. Dojde-li po dobu platnosti a účinnosti této smlouvy k případnému přejmenování, přečíslování, změně licencování apod., je poskytovatel povinen zajistit „přímého nástupce“ dané licence při dodržení ceny podle čl. III odst. 3, resp. přílohy č. 12.
1. Budoucí rozvoj zahrnuje:
Článek IX
Provádění budoucího rozvoje
a) Konzultace nových funkčních a nefunkčních požadavků objednatele na úpravy IS SD a jejich dopadů, programátorského rozhraní API, identifikace provozních závad, provozní konfigurace, výkonnostních optimalizací a bezpečnostní konfigurace (rozvojové konzultace), pokud nejsou zahrnuty v jiném plnění dle této smlouvy.
b) Vypracování písemných analýz a návrhů řešení nových funkčních a nefunkčních požadavků objednatele na úpravy IS SD, popř. dalších písemných analýz nebo návrhů souvisejících s možnými úpravami IS SD, pokud nejsou zahrnuty v jiném plnění dle této smlouvy.
c) Úpravy IS SD z podnětu objednatele, které nejsou předmětem podpory běžného provozu podle čl. VI, odstraňování vad provozu podle čl. VII nebo rozšíření stávající licence podle čl. VIII.
d) Odstraňování vad IS SD prokazatelně způsobených objednatelem, jeho zaměstnanci nebo třetími osobami na jeho příkaz, a to na písemnou žádost pověřené osoby objednatele zaslanou na e-maily pověřených osob poskytovatele.
e) Programátorské práce požadované objednatelem v souvislosti s IS SD, pokud nejsou zahrnuty v jiném plnění dle této smlouvy.
Výsledky plnění podle písm. b) až e) se dále nazývají též „výstupy“.
2. Výstupy předává poskytovatel objednateli:
a) zasláním na e-maily pověřených osob objednatele,
b) uložením na úložiště určené pro tento účel pověřenou osobou objednatele, čímž nesmí poskytovateli vzniknout žádné dodatečné náklady,
c) doručením do podatelny ČNB Praha v místě plnění podle čl. I odst. 12, a to na obecně užívaném paměťovém médiu (např. CD, DVD, USB flashdisk),
má-li výstup formu dokumentu nebo jeho aktualizace, pak ve formátech editovatelných aplikacemi MS Word 2016 nebo MS Excel 2016. Výstupy předá poskytovatel včetně aktualizované dokumentace v souladu s čl. VI odst. 2 písm. f).
Pověřené osoby smluvních stran se v konkrétním případě mohou dohodnout i na jiném vhodném způsobu předání výstupu.
3. Spolu s výstupy plnění podle odst. 1 písm. c) a e) a, je-li to vhodné, též podle písm. d) tohoto článku, předá poskytovatel objednateli komentovaný, kompletní a čitelný zdrojový kód výstupu, a popřípadě též další podklady potřebné ke správě, údržbě a úpravám IS SD. V případě interpretovaných programovacích jazyků musí být místo kompilovatelnosti zajištěna podmínka interpretovatelnosti zdrojového kódu v příslušném prostředí daného programovacího jazyka.
4. Plnění podle odst. 1 písm. a) tohoto článku je realizováno způsobem a ve lhůtě dle dohody pověřených osob smluvních stran, a to bez povinnosti uzavírat dodatek k této smlouvě. Pracovníci poskytovatele, popř. též odborníci, bude-li to objednatel požadovat, jsou však povinni dostavit se k rozvojové konzultaci do místa plnění podle čl. I odst. 12 na písemnou výzvu pověřené osoby objednatele, zaslanou na e-maily pověrných osob poskytovatele, a to v požadovaném čase, je-li taková výzva zaslána alespoň 5 pracovních dnů předem.
5. Lhůty pro plnění podle odst. 1 písm. b), c) a e) tohoto článku budou určeny dohodou pověřených osob smluvních stran nebo, nedojde-li k dohodě, objednatelem na e-maily pověřených osob poskytovatele. Jsou-li lhůty určeny objednatelem, pak:
a) lhůta pro předání plnění, resp. výstupu, k akceptaci nesmí být kratší než 20 pracovních dnů ode dne, kdy bylo její určení zasláno na e-maily pověřených osob poskytovatele;
b) lhůta pro předání plnění, resp. výstupu, do ověřovacího provozu nesmí být kratší než 35 pracovních dnů ode dne, kdy bylo její určení zasláno na e-maily pověřených osob poskytovatele;
c) lhůta pro předání plnění, resp. výstupu, u něhož nebude provedena akceptace ani ověřovací provoz, nesmí být kratší než 20 pracovních dnů ode dne, kdy bylo její určení zasláno objednatelem na e-maily pověřených osob poskytovatele;
d) lhůta pro předání plnění, resp. výstupu, u něhož bude provedena pouze akceptace, nesmí být kratší než 30 pracovních dnů ode dne, kdy bylo její určení zasláno objednatelem na e-maily pověřených osob poskytovatele;
e) lhůta pro předání plnění, resp. výstupu, u něhož bude provedena akceptace a ověřovací provoz, nesmí být kratší než 50 pracovních dnů ode dne, kdy bylo její určení zasláno objednatelem na e-maily pověřených osob poskytovatele.
6. Plnění podle odst. 1 písm. d) tohoto článku bude poskytnuto bez zbytečného odkladu po stanovení jeho ceny podle čl. III odst. 4, přičemž cenovou nabídku předloží poskytovatel objednateli nejpozději do 10 pracovních dnů poté, co o to byl pověřenou
osobou objednatele požádán. Poskytovatel musí na odstranění vady pracovat bez přerušení; přerušit práce na odstranění vady lze jen s písemným souhlasem pověřené osoby objednatele, který současně stanoví odkládací podmínku či podmínky3.
7. Objednatel umožní poskytovateli v provozní době objednatele a v místě plnění ověření úprav IS SD v prostředí objednatele.
8. Požadavek na provedení akceptace a/nebo ověřovacího provozu u daného výstupu musí objednatel sdělit poskytovateli vždy nejpozději před vypracováním cenové nabídky poskytovatele podle čl. III odst. 4. Na provedení akceptace a/nebo ověřovacího provozu se přiměřeně užijí ustanovení přílohy č. 9, přičemž závada/y se považuje/í za vadu/y ve smyslu tohoto článku. U výstupu plnění podle odst. 1 písm. d) tohoto článku nelze požadovat provedení akceptace a/nebo ověřovacího provozu.
9. O předání a převzetí plnění podle odst. 1 tohoto článku bude vždy sepsán předávací protokol budoucího rozvoje. Předávací protokol budoucího rozvoje podepisuje alespoň jedna pověřená osoba za každou smluvní stranu. Pokud předávané plnění obsahuje vadu/y a:
a) jde o plnění, resp. výstup, u nějž byl proveden ověřovací provoz, není poskytovatel oprávněn plnění předat a objednatel není povinen je převzít, nebyl-li ověřovací provoz úspěšně ukončen;
b) jde o plnění, resp. výstup, u nějž nebyl proveden ověřovací provoz, avšak byla provedena akceptace, není poskytovatel oprávněn plnění předat a objednatel není povinen je převzít, nebyl-li výstup akceptován nebo akceptován s výhradami;
c) jde o plnění, resp. výstup, u nějž nebyl proveden ověřovací provoz ani akceptace, není objednatel povinen je převzít.
10. Obsahuje-li plnění, resp. výstup, v okamžiku předání vadu/y a objednatel jej přesto přebírá, je převzat(o) s výhradami a objednatel, po projednání s poskytovatelem, určí v předávacím protokolu budoucího rozvoje pro každou z vad závaznou lhůtu pro její odstranění. Lhůta podle předchozí věty může být stanovena i s odkládací podmínkou4. Lhůta podle tohoto odstavce se nestanovuje pro neodstranitelné vady, které nejsou haváriemi nebo kritickými (zá)vadami ve smyslu čl. VII, kap. 1.2.4 nebo kap. 2.1.3 přílohy č. 9 této smlouvy a se kterými objednatel plnění přijal; to musí být v předávacím protokolu budoucího rozvoje výslovně uvedeno. Pro předávací protokol budoucího rozvoje se použije vzor uvedený v části „Vzor předávacího protokolu“ přílohy č. 9.
11. Lhůtu(y) stanovenou(é) podle tohoto článku, uvedenou(é) v příloze č. 9, uvedenou(é) v akceptačním protokolu nebo v předávacím protokolu budoucího rozvoje je oprávněna kterákoliv z pověřených osob objednatele, na písemnou a odůvodněnou žádost poskytovatele, přiměřeně okolnostem prodloužit, pokud poskytovatel objektivně nemohl pokračovat v plnění dle této smlouvy z důvodu, že mu objednatel neposkytl povinnou a nezbytnou součinnost, nebo z důvodu skutečností stojících na straně poskytovatele, které ani poskytovatel jednající s náležitou péčí nemohl předvídat a které sám nezpůsobil (včetně např. výpadku či zdržení v dodavatelsko-odběratelském řetězci, výpadku v pracovní síle poskytovatele z důvodu
3 Např. do 5 pracovních dnů poté, co výrobce programového prostředku (SW) vydá příslušný update nebo patch, nejpozději do 2 týdnů, nebude-li předán postup workaroundu, jinak do 6 měsíců atd.
4 Např. do 5 pracovních dnů poté, co výrobce programového prostředku (SW) vydá příslušný update nebo patch.
opatření uložených orgány veřejné moci, nikoli v důsledku protiprávního jednání poskytovatele, zdržení v plnění jiných smluvních partnerů objednatele, které se plnění dle této smlouvy dotýká a které nebylo způsobeno objednatelem). Písemná žádost poskytovatele musí obsahovat i návrh prodloužení lhůty, ten však není pro pověřené osoby objednatele závazný. Změna lhůty je účinná dnem jejího písemného oznámení kterékoliv z pověřených osob poskytovatele, a to bez povinnosti uzavírat dodatek k této smlouvě.
12. Ohledně budoucího rozvoje je možno s poskytovatelem komunikovat prostřednictvím hotline nebo helpdesk, popř. prostřednictvím e-mailů pověřených osob poskytovatele; k uvedenému jsou oprávněny pouze pověřené osoby objednatele.
Článek X
Licenční ujednání
1. Poskytovatel poskytuje objednateli místně neomezenou licenci na dobu trvání majetkových práv (bez časového omezení), umožňující užívat:
a) dílo vč. všech jeho součástí, zejména zdrojového kódu a aktualizované dokumentace, a pakliže postupuje poskytovatel podle čl. I odst. 3 písm. b), též databázové platformy, kterou za v rámci IS SD dodal poskytovatel vlastní a která se proto pro účely této smlouvy považuje za součást IS SD,
b) veškeré výstupy vč. všech jejich součástí, zejména zdrojového kódu a aktualizované
dokumentace,
c) jakékoliv další autorské dílo ve smyslu AutZ, které by vzniklo při plnění dle této
smlouvy, včetně všech jeho součástí,
a to:
d) všemi způsoby užívání, jedná-li se o autorská díla nebo jejich součásti poskytovatelem individuálně vytvořené, zejména doprogramované části a výstupy, nebo
e) pro potřeby objednatele jakož i třetích osob s množstevním omezením podle přílohy č. 1 požadavku OB16 a za podmínky, že jsou provozovány v systémovém prostředí objednatele, avšak bez dalších množstevních nebo jiných srovnatelných omezení (počtem koncových zařízení, výpočetních jader atd.), jedná-li se o programové prostředky (SW) nebo jiná autorská díla nikoliv poskytovatelem individuálně vytvořená, ale získaná od třetí osoby, zejména doplněné části.
2. Množstevní omezení podle odst. 1 písm. e) tohoto článku se automaticky zvyšuje plněním poskytovatele podle čl. VIII o poskytnuté rozšíření stávající licence, a to bez povinnosti uzavírat dodatek k této smlouvě.
3. Množstevní omezení podle odst. 1 písm. e) tohoto článku se může uplatňovat i prostřednictvím modelu oprávnění konkrétních uživatelů (tzv. named user), musí však umožňovat záměnu konkrétního uživatele za jiného konkrétního uživatele, a to vždy nejpozději do 1 měsíce od okamžiku, kdy je o to poskytovatel požádán pracovníkem objednatele prostřednictvím hotline nebo helpdesk.
4. Licence je poskytována jako nevýhradní i pro všechna autorská díla nebo jejich součásti poskytovatelem individuálně vytvořené, tj. i pro doprogramované části nebo výstupy.
5. Licence v uvedeném rozsahu se vztahuje i na veškeré aktualizace poskytnutých programových prostředků (SW) (tj. update/upgrade/patch/hotfix atd.) a veškeré úpravy všech součástí plnění.
6. Poskytovatel dále výslovně dovoluje objednateli vlastní dílo poskytovatele (zejména doprogramované části a výstupy) a všechny jeho části měnit, upravovat, zpracovávat, spojovat s jinými autorskými díly nebo jejich částmi, zařadit do autorského díla souborného a zasahovat do kterékoliv jeho části, a to jak samostatně, tak prostřednictvím třetích osob, a takovéto vlastní dílo poskytovatele dále užívat všemi způsoby užívání.
7. Licence je poskytnuta okamžikem zpřístupnění plnění poskytovatelem objednateli; to platí
i o rozšíření stávající licence podle čl. VIII.
8. Objednatel není licenci povinen užít.
9. Odměny za poskytnutí či rozšíření stávající licence podle této smlouvy jsou součástí cen podle čl. III.
10. Okamžikem předání a převzetí se objednatel stává vlastníkem jakéhokoliv hmotného substrátu obsahujícího příslušné vlastní dílo poskytovatele, zejména doprogramované části či výstupy. Objednatel se okamžikem předání a převzetí stává rovněž vlastníkem zdrojového kódu plnění, resp. doprogramované části nebo výstupu, jako informace.
11. Poskytovatel prohlašuje, že práva, která touto smlouvou poskytuje, mu náleží bez jakéhokoliv omezení, a odpovídá za škodu, která by objednateli vznikla, pokud by toto prohlášení bylo nepravdivé.
12. Pro vyloučení pochybností smluvní strany prohlašují, že vlastníkem informací (dat) obsažených v IS SD je za všech okolností objednatel. Poskytovatel nemá k informacím (datům) obsaženým v IS SD žádná práva.
Článek XI
Mlčenlivost, bezpečnost a pojištění odpovědnosti
1. Poskytovatel se zavazuje zajistit, že jeho pracovníci a pracovníci jeho poddodavatelů, kteří se budou na plnění podle této smlouvy podílet, zachovají mlčenlivost o všech skutečnostech, se kterými se u objednatele seznámí a které nejsou veřejně známy. Povinnost mlčenlivosti není časově omezena.
2. Poskytovatel se zavazuje v plném rozsahu dodržovat Obecná pravidla v oblasti bezpečnosti IT, která jsou přílohou č. 10 této smlouvy, a Bezpečnostní požadavky ČNB, které jsou přílohou č. 11 této smlouvy.
3. Poskytovatel prohlašuje, že po dobu účinnosti této smlouvy bude mít sjednáno pojištění pro případ vzniku odpovědnosti za škodu způsobenou třetí osobě v souvislosti s plněním této smlouvy, a to s pojistným plněním ve výši nejméně 10 000 000 Kč (slovy: deset milionů korun českých) s tím, že jeho spoluúčast nepřevyšuje 10 %. Poskytovatel se zavazuje, že pojištění v uvedené výši a rozsahu zůstane účinné po celou dobu účinnosti této smlouvy a do 5 pracovních dnů od výzvy objednatele je poskytovatel povinen toto objednateli prokázat.
Článek XII
Další povinnosti poskytovatele a společenská odpovědnost
Poskytovatel se zavazuje:
1. Poskytnout na žádost objednatele bezplatnou součinnost při hromadném exportu dat v případě ukončení (zrušení) této smlouvy.
2. Zajistit legální zaměstnávání osob a férové a důstojné pracovní podmínky pro všechny pracovníky podílející se na plnění této smlouvy. Férovými a důstojnými pracovními podmínkami se přitom rozumí takové pracovní podmínky, které splňují alespoň minimální standardy stanovené pracovněprávními a mzdovými předpisy. Poskytovatel je povinen zajistit splnění požadavků dle tohoto ustanovení i u svých poddodavatelů.
3. Zajistit řádné a včasné plnění finančních závazků vůči svým poddodavatelům, kdy za řádné a včasné plnění se považuje plné uhrazení poddodavatelem vystavených faktur za plnění poskytnutá poskytovateli v souvislosti s touto smlouvou, a to nejpozději do 10 dnů od obdržení platby ze strany objednatele (pokud již splatnost poddodavatelem vystavené faktury nenastala dříve). Kterákoliv pověřená osoba objednatele je oprávněna požadovat předložení dokladů
o provedených platbách poddodavatelům.
Článek XIII Sankce EU
1. Poskytovatel potvrzuje, že ke dni účinnosti této smlouvy není osobou uvedenou v příloze I nařízení Rady (EU) č. 269/2014 ze dne 17. března 2014 o omezujících opatřeních vzhledem k činnostem narušujícím nebo ohrožujícím územní celistvost, svrchovanost a nezávislost Ukrajiny, ve znění jeho změn (dále také jako „nařízení č. 269/2014“) nebo v příloze I nařízení Rady (EU) č. 208/2014 ze dne 6. března 2014 o omezujících opatřeních vůči některým osobám, subjektům a orgánům vzhledem k situaci na Ukrajině, ve znění jeho změn (dále také jako
„nařízení č. 208/2014“) nebo v příloze I nařízení Rady (ES) č. 765/2006 ze dne 18. května 2006
o omezujících opatřeních vůči prezidentu Xxxxxxxxxxx a některým představitelům Běloruska, ve znění jeho změn (dále také jako „nařízení č. 765/2006“) nebo v příloze rozhodnutí Rady 2014/145/SZBP ze dne 17. března 2014 o omezujících opatřeních vzhledem k činnostem narušujícím nebo ohrožujícím územní celistvost, svrchovanost a nezávislost Ukrajiny, ve znění jeho změn (dále také jako „rozhodnutí 2014/145/SZBP“). Osoba uvedená v příloze I nařízení č. 269/2014 nebo v příloze I nařízení č. 208/2014 nebo v příloze I nařízení č. 765/2006 nebo v příloze rozhodnutí Rady 2014/145/SZBP bude dále označována jako „určená osoba“.
2. Poskytovatel se současně zavazuje, že určeným osobám dle předchozího odstavce (není-li jí sám) nebo v jejich prospěch nezpřístupní žádné finanční prostředky ani hospodářské zdroje získané v souvislosti s plněním dle této smlouvy, a to přímo ani nepřímo.
3. Poskytovatel dále potvrzuje, že plnění jím poskytované dle této smlouvy neporušuje žádným způsobem jakékoliv platné právní předpisy vydané zejména orgány Evropské unie [tj. zejména zákazy dovozu výrobků ze železa a oceli ve smyslu nařízení Rady (EU) č. 2022/428 ze dne
15. března 2022, kterým se mění „základní“ nařízení (EU) č. 833/2014 o omezujících opatřeních vzhledem k činnostem Ruska destabilizujícím situaci na Ukrajině, nebo nařízení Rady (EU) č. 2022/355 ze dne 2. března 2022, kterým se mění „základní“ nařízení (ES)
č. 765/2006 o omezujících opatřeních vzhledem k situaci v Bělorusku apod.]. Objednatel je oprávněn při porušení této povinnosti poskytovatele plnění nepřevzít v jakékoliv jeho části.
4. V případě, že by se v průběhu účinnosti této smlouvy poskytovatel nebo jeho jakýkoliv poddodavatel stal určenou osobou, je poskytovatel povinen o takové skutečnosti objednatele bez zbytečného odkladu, nejpozději do 2 pracovních dnů od nastání takové skutečnosti, písemně informovat.
5. Dojde-li za dobu účinnosti této smlouvy ke změnám v kterémkoliv z výše uvedených nařízení Rady (EU) či rozhodnutí Rady nebo k přijetí jakékoliv jiné nové legislativy tak, že bude nezbytné dát tuto smlouvu s nařízením Rady (EU), rozhodnutím Rady nebo jinou novou legislativou do souladu, zavazují se smluvní strany uzavřít písemný dodatek k této smlouvě, jehož předmětem bude úprava či doplnění práv a povinností smluvních stran v rámci této smlouvy (sankční mechanismy či nové možnosti ukončení smlouvy z toho nevyjímaje), a to bez zbytečného odkladu, nejpozději do 15 pracovních dnů poté, co změny nařízení Rady (EU), rozhodnutí Rady či jiná nová legislativa nabudou platnosti, nedohodnou-li se smluvní strany jinak.
6. Vznikne-li objednateli v souvislosti s nepravdivým prohlášením nebo porušením povinností poskytovatele dle tohoto článku smlouvy jakákoliv škoda, je poskytovatel tuto škodu objednateli povinen v plné výši nahradit.
Článek XIV Smluvní pokuty
1. V případě prodlení poskytovatele ve lhůtě podle čl. II odst. 1 písm. a) je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 3 000 Kč za každý den prodlení.
2. V případě prodlení poskytovatele ve lhůtě podle čl. II odst. 1 písm. b) je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 3 000 Kč za každý den prodlení.
3. V případě prodlení poskytovatele v kterékoliv lhůtě podle čl. II odst. 1 písm. c), resp. v kterékoliv lhůtě určené v akceptačním protokolu o akceptaci díla, je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 1 500 Kč za každý den prodlení a za každou takovou lhůtu.
4. V případě prodlení poskytovatele ve lhůtě podle čl. II odst. 1 písm. d) je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 3 000 Kč za každý den prodlení.
5. V případě prodlení poskytovatele ve lhůtě podle čl. II odst. 1 písm. e) je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 1 000 Kč za každý den prodlení.
6. V případě prodlení poskytovatele v kterékoliv lhůtě podle čl. II odst. 1 písm. f), resp. ve kterékoliv lhůtě určené v protokolu o předání a převzetí díla, je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 1 500 Kč za každý den prodlení a za každou takovou lhůtu.
7. V případě prodlení poskytovatele ve lhůtě podle čl. IV odst. 1, a zároveň v dodatečné lhůtě poskytnuté na splnění předmětné povinnosti v souladu s občanským zákoníkem, je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 500 Kč za každý pracovní den prodlení.
8. V případě nedostupnosti hotline nebo helpdesk, trvající déle než 24 hodin, je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 1 000 Kč za každý započatý den. V případě hotline jsou rozhodující pouze hodiny v provozní době objednatele podle čl. I odst. 13. Smluvní pokutu podle tohoto odstavce není objednatel oprávněn poskytovateli uložit, pakliže poskytl objednateli po dobu nedostupnosti hotline nebo helpdesk srovnatelnou alternativní a dočasnou možnost, jak poskytovatele kontaktovat, která je pro období nedostupnosti hotline nebo helpdesk považována za kontakt jejich prostřednictvím, včetně všech následků dle této smlouvy (zejména počátek, přerušení nebo skončení lhůt a dob podle této smlouvy).
9. V případě prodlení poskytovatele ve lhůtě podle čl. VI odst. 4 písm. f) je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 1 000 Kč za každý pracovní den prodlení.
10. V případě prodlení poskytovatele ve lhůtě podle čl. VI odst. 4 písm. g) je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 1 500 Kč za každý pracovní den prodlení.
11. V případě prodlení poskytovatele ve lhůtě podle čl. VII odst. 2 písm. a) odrážky první je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 300 Kč za každou hodinu prodlení.
12. V případě prodlení poskytovatele ve lhůtě podle čl. VII odst. 2 písm. a) odrážky druhé je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 20 000 Kč za každý pracovní den prodlení.
13. V případě prodlení poskytovatele ve kterékoliv lhůtě podle čl. VII odst. 2 písm. b) je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 1 000 Kč za každý pracovní den prodlení.
14. V případě prodlení poskytovatele ve lhůtě podle čl. VII odst. 2 písm. c) je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 500 Kč za každý pracovní den prodlení.
15. V případě prodlení poskytovatele ve lhůtě podle čl. VIII odst. 2 je objednatel oprávněn
požadovat po poskytovateli smluvní pokutu ve výši 3 000 Kč za každý den prodlení.
16. V případě, že poskytovatel bezdůvodně odmítne poskytnout plnění podle čl. IX odst. 1 písm. d), resp. nezašle na takové plnění cenovou nabídku ve smyslu čl. III odst. 4, ačkoliv o to byl pověřenou osobou objednatele požádán, je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 1 000 Kč za každý takový případ a každý den, kdy takový stav trvá.
17. V případě prodlení poskytovatele ve kterékoliv lhůtě podle čl. IX odst. 5 je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 1 500 Kč za každý pracovní den prodlení a za každou takovou lhůtu.
18. V případě, že poskytovatel je v prodlení ve lhůtě pro předložení cenové nabídky, nezačne vadu odstraňovat bez zbytečného odkladu nebo přestane pracovat na odstranění vady podle čl. IX odst. 6, je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 1 000 Kč za každý takový případ a byť i jen započatý každý den, kdy takový stav trvá.
19. V případě porušení povinnosti nebo nepravdivosti prohlášení poskytovatele podle čl. X této smlouvy je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 100 000 Kč za každý takový případ.
20. V případě porušení povinnosti mlčenlivosti podle čl. XI odst. 1 je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 500 000 Kč za každý takový případ.
21. V případě porušení povinnosti dodržovat Obecná pravidla v oblasti bezpečnosti IT a Bezpečnostní požadavky ČNB podle čl. XI odst. 2 je objednatel oprávněn požadovat po poskytovateli smluvní pokutu ve výši 20 000 Kč za každý takový případ.
22. V případě prodlení poskytovatele v kterékoliv lhůtě dle čl. XIII odst. 4 nebo 5 je objednatel
oprávněn účtovat poskytovateli smluvní pokutu ve výši 1 000 Kč za každý pracovní den prodlení.
23. V případě, že se ukáže tvrzení poskytovatele uvedené v čl. XIII odst. 1 nebo 3 jako nepravdivé nebo poruší-li poskytovatel závazek stanovený v čl. XIII odst. 2, vzniká objednateli nárok na smluvní pokutu ve výši 100 000 Kč za každé jednotlivé nepravdivé tvrzení poskytovatele či za každé jednotlivé porušení závazku poskytovatele.
24. V případě, že objednatel od smlouvy odstoupil podle čl. XV odst. 5 písm. a), b) nebo c), vzniká objednateli nárok na smluvní pokutu ve výši 10 % z celkové ceny díla podle čl. III odst. 1.
25. V případě prodlení s uhrazením daňového dokladu zaplatí objednatel poskytovateli úrok
z prodlení podle předpisů občanského práva.
26. Smluvní pokutou není dotčen nárok na náhradu škody.
27. Smluvní pokuty a úroky z prodlení jsou splatné do 14 kalendářních dnů ode dne doručení dokladu k úhradě povinné smluvní straně. Úhradou smluvní pokuty není dotčena povinnost uhradit škodu v plné výši vzniklou v důsledku neplnění povinnosti podle této smlouvy. Povinnost uhradit smluvní pokutu je splněna odepsáním příslušné částky z účtu povinného ve prospěch účtu oprávněného.
Článek XV
Trvání a skončení smlouvy
1. Smlouva se v částech, týkajících se plnění podle čl. I odst. 10, uzavírá na dobu neurčitou s výpovědní dobou 1 rok, která počíná běžet dnem doručení písemné výpovědi druhé smluvní straně. Poskytovatel může smlouvu vypovědět nejdříve v den uplynutí 7 let od předání a převzetí díla.
2. V případě, že některá ze smluvních stran podstatně poruší smluvní povinnost vyplývající pro ni z této smlouvy, je druhá smluvní strana oprávněna od smlouvy odstoupit nebo ji vypovědět bez výpovědní doby. Objednatel je oprávněn odstoupit i od části smlouvy.
3. Za podstatné porušení smluvní povinnosti ze strany poskytovatele se považuje zejména:
a) pokud je poskytovatel v prodlení s jakoukoliv lhůtou podle této smlouvy více než 30 hodin, je-li stanovena v hodinách, více než 30 pracovních dnů, je-li stanovena v pracovních dnech, nebo více než 30 dnů, je-li stanovena ve dnech nebo jiné časové jednotce,
b) pokud poskytovatel více než třikrát bezdůvodně odmítl poskytnout plnění podle čl. IX odst. 1 písm. a) až e), resp. nezaslal na takové plnění cenovou nabídku ve smyslu čl. III odst. 4, ačkoliv o to byl pověřenou osobou poskytovatele požádán,
c) pokud v rozporu s čl. X odst. 3 omezení počtu uživatelů podle čl. X odst. 1 písm. e) neumožňuje záměnu konkrétního uživatele za jiného konkrétního uživatele,
d) pokud je porušeno jakékoliv ustanovení čl. XIII.
4. Za podstatné porušení smluvní povinnosti ze strany objednatele se považuje zejména:
a) pokud je objednatel v prodlení s úhradou kteréhokoliv daňového dokladu k úhradě delším než 30 dnů.
5. Objednatel od smlouvy odstoupí pro podstatné porušení smluvní povinnosti také, pakliže poskytovatel provede dílo, resp. jeho část, v tak nedostatečné kvalitě, že:
a) ani po třetí akceptaci realizační studie není možné realizační studii podle přílohy č. 9 akceptovat (má stále závady),
b) ani po třetí akceptaci díla není možné dílo podle přílohy č. 9 akceptovat ani s výhradami (má stále závady nepřípustné kategorie či v nepřípustném počtu),
c) ani po třetím provedení ověřovacího provozu nebyl ověřovací provoz úspěšně ukončen nebo poskytovatel po neúspěšném ukončení ověřovacího provozu prohlásil, že nehodlá odstraňovat vady, které vedly k neúspěchu ověřovacího provozu.
6. Smluvní strany se dále dohodly, že objednatel je oprávněn odstoupit od smlouvy kdykoliv
v průběhu insolvenčního řízení zahájeného na majetek poskytovatele.
7. Smluvní strany si v souladu s ustanovením § 1992 občanského zákoníku sjednávají, že objednatel je oprávněn zrušit tuto smlouvu zaplacením odstupného ve výši 100 000 Kč na účet poskytovatele, a to kdykoliv před akceptací realizační studie podle přílohy č. 4 této smlouvy. Zrušení smlouvy je účinné zaplacením sjednaného odstupného na bankovní účet poskytovatele, č. ú.: 1104066180/5500. Zaplacením odstupného zanikají všechna práva a povinnosti obou smluvních stran vyplývající ze zrušené smlouvy s výjimkou závazku mlčenlivosti poskytovatele.
8. Odstoupení od smlouvy je účinné dnem doručení oznámení o odstoupení od smlouvy druhé smluvní straně.
9. Odstoupením od smlouvy nejsou dotčena ustanovení týkající se vyrovnání smluvních závazků, smluvních pokut, závazku mlčenlivosti poskytovatele a ustanovení týkající se takových práv a povinností, z jejichž povahy vyplývá, že mají trvat i po odstoupení.
Článek XVI Uveřejnění smlouvy
1. Poskytovatel si je vědom zákonné povinnosti objednatele uveřejnit na svém profilu tuto smlouvu včetně všech jejích případných změn a dodatků a výši skutečně uhrazené ceny za plnění této smlouvy.
3. Povinnost uveřejňování dle tohoto článku je objednateli uložena § 219 ZZVZ.
4. Uveřejňování bude prováděno dle ZZVZ a příslušného prováděcího předpisu k ZZVZ.
Článek XVII Závěrečná ustanovení
1. Smlouva nabývá platnosti a účinnosti dnem jejího podpisu oprávněnými zástupci obou smluvních stran.
2. Smlouvu je možno měnit nebo doplňovat pouze formou písemných, vzestupně číslovaných dodatků podepsaných oprávněnými zástupci obou smluvních stran, není-li ve smlouvě uvedeno jinak. Dodatek v elektronické podobě se považuje za řádně podepsaný objednatelem, je-li podepsán kvalifikovanými elektronickými podpisy.
3. Závazkový vztah založený touto smlouvou se řídí českým právním řádem, zejména občanským zákoníkem a příslušnými ustanoveními AutZ.
4. Spory vyplývající z této smlouvy budou řešeny především dohodou smluvních stran. Nebude-li možné dosáhnout dohody, bude spor řešen před místně a věcně příslušným soudem České republiky, a to výlučně podle českého práva.
5. Odpověď stran této smlouvy podle § 1740 odst. 3 občanského zákoníku s dodatkem nebo odchylkou není přijetím nabídky, ani když podstatně nemění podmínky nabídky.
6. Smluvní strany vylučují uplatnění ustanovení § 1765 a § 1766 a § 2620 občanského zákoníku
na svůj smluvní vztah založený touto smlouvou, čímž se ruší nárok dodavatele na jednání podle
§ 1765 odst. 1 občanského zákoníku. Dodavatel tímto přebírá nebezpečí změny okolností
dle § 1765 odst. 2 občanského zákoníku.
7. Práva a povinnosti vzniklé z této smlouvy mohou být postoupeny pouze po předchozím písemném souhlasu druhé smluvní strany.
8. Ukončením smlouvy nejsou dotčena ustanovení smlouvy týkající se nároků z odpovědnosti za vady, nároků z odpovědnosti za škodu a nároků ze smluvních pokut, závazku mlčenlivosti ani další ustanovení, z jejichž povahy vyplývá, že mají trvat i po zániku účinnosti smlouvy.
9. Smluvní strany se dohodly, že v případě rozporu mezi smlouvou a jejími přílohami se uplatní text smlouvy, v případě rozporu přílohy č. 1 s jinou přílohou se uplatní příloha č. 1, v případě rozporu mezi textovou a obrazovou částí přílohy č. 1 se uplatní textová část.
10. Smlouva je vyhotovena v elektronické podobě, přičemž každá ze smluvních stran obdrží vyhotovení smlouvy opatřené elektronickými podpisy.
Přílohy:
č. 1 Funkční a nefunkční požadavky
č. 2 část A Popis prostředí objednatele a varianty implementace (veřejná část)
č. 2 část B Popis prostředí objednatele a varianty implementace (neveřejná část) č. 3 Ujednání o zpracování osobních údajů
č. 4 Šablona realizační studie
č. 5 Šablona testovacího scénáře
č. 6 Počet, rozsah a obsah školení
č. 7 Obsah dokumentace IS SD
č. 8 Seznam techniků – volně připojená příloha č. 9 Akceptace, ověřovací a testovací provoz
č. 10 Obecná pravidla pro poskytovatele v oblasti bezpečnosti IT č. 11 Bezpečnostní požadavky ČNB
č. 12 Ceny za rozšíření stávající licence
V2P4r.a9ze.d2le0č2as4ového razítka V2B2r.a9tis.l2av0e 2dl4e časového razítka
Za objednatele: Za poskytovatele:
Xxx. Xxxxx Xxxxxxx Xxx. Xxxxxxxx Xxxxxx
ředitel sekce informatiky konateľ
(podepsáno elektronicky) SEAL IT Services, s.r.o.
(podepsáno elektronicky)
Xxx. Xxxxxx Xxxxxx ředitel sekce správní (podepsáno elektronicky)
Funkční a nefunkční požadavky
Příloha č. 1
Hlavním účelem IS SD je zajistit centralizované kontaktní místo mezi poskytovatelem interních služeb a uživateli v ČNB. Systém bude jedním společným portálem pokrývat aktivity dvou samostatných organizačních jednotek ČNB, poskytujících interní služby - sekci informatiky a sekci správní. Každá sekce má své portfolio nabízených služeb, konfigurační položky, svoji kapacitu řešitelů, svoji představu
o obsazení rolí pro zajištění těchto služeb.
Pro sekci informatiky bude systém podporovat správu procesů ITSM (IT service management) a
projektového řízení.
Pro sekci správní bude systém podporovat portfolio služeb v oblastech správy budov, řízení vstupů, organizace konferencí, úklidu, služeb knihovny apod. (dále souhrnně jako Facility Management). Tyto aktivity lze analogicky dle ITSM pokrýt procesy Configuration management, Service level management, Service Request a Incident management.
Zadavatel považuje za důležité, aby proces zadání požadavku do systému SD byl pro uživatele zřetelný a rychlý bez hlubšího studování obrazovky . Na druhou stranu by měl vnímavější uživatel z rozhraní poznat, že existuje definovaný, klasifikovaný soubor služeb s popsanou dostupností, které jsou nabízeny a které může požadovat.
Zpracování požadavku bude probíhat dle procesních workflow, vycházejících z doporučení ITIL a interních pokynů a metodických listů ČNB. Cílem je uživatele tímto pozadím nezatěžovat, ale intuitivně jej provést procesem tak, aby každému kroku rozuměl.
Systém budou využívat dva typy uživatelů - zadavatel a řešitel. Zadavatel může zadávat požadavky a také požadavky schvalovat. Řešitel může požadavky zadávat, schvalovat a navíc i požadavky řešit.
Uživateli budou nadefinovány role oprávnění, se kterou bude v systému vystupovat a která mu umožní přístup pouze k definovaným datům (např. pouze k vybraným službám, číselníkům, adminstraci, řízení procesů apod). Systém SD bude nabízet pro tyto typy uživatelů prostředí, aby mohli efektivně pracovat. Prostředí obrazovky systému se bude lišit z podstaty definovaných rolí v systému.
Konkrétní funkční požadavky jsou níže strukturovány do oblastí:
Service Request + Incident Management 41
Kybernetická bezpečnost - funkční požadavky 49
Kybernetická bezpečnost - nefunkční požadavky 50
Specifické nefunkční požadavky. 54
ID | Název | Popis požadavku |
OB01 | Vyhledávání | Systém umožní snadné fulltextové vyhledávání ve všech typech entit ve všech procesech včetně možností třídění vyhledaných výsledků. Možnost uživatelsky definovaných filtrů. |
OB02 | Inteligentní vyhledávání | Systém nabídne uživateli odkazy na služby, a případně další odkazy (např. položky znalostní DB, existující požadavky) dle největší relevance k uživatelem právě prováděné akci či zadávanému textu. |
OB03 | Vazby mezi požadavky | Systém umožní zakládat požadavky s vazbou k jinému požadavku (k jednomu nadřízenému více podřízených) a to bez omezení počtu úrovní rozpadu. |
OB04 | Dědění atributů | Při vytváření podřízeného požadavku se budou dědit hodnoty atributů z nadřízeného požadavku s možností následné editace uživatelem. Které atributy se mají dědit, a které je možno editovat, bude možno konfigurovat pro každý typ požadavku/šablonu samostatně. |
OB05 | Seznamy | Pro jednotlivé entity existují seznamy (výpisy dat), které umožňují data třídit, filtrovat a exportovat do formátu CSV, XLSX . |
OB06 | Počet úrovní podřízených katalogu služeb | Systém umožní minimálně 5 úrovní rozpadu katalogu služeb. |
OB07 | Možnosti reportingu | Reporty je možno uživatelsky definovat včetně možnosti vložit vlastní dotaz, uložit je a nastavit automatické vytváření a případnou distribuci či notifikaci. Reporty je možno exportovat nebo ukládat do souboru ve formátu CSV, XLSX, HTML, PDF. |
OB08 | Vývojové prostředí | Součástí IS SD je vývojové prostředí, které bude sloužit pro vývoj funkcionality interně vyvinuté i dodané dodavatelem. |
OB09 | Testovací prostředí | Součástí IS SD je samostatné testovací prostředí, určené pro testování funkcionality a nových verzí zadavatelem. |
OB10 | Produkční prostředí | Součástí IS SD je Produkční prostředí slouží k vlastnímu běžnému provozu systému. |
OB11 | Importní rozhraní | Systém obsahuje konfigurovatelné rozhraní pro napojení externích dat za účelem pravidelných importů dat pro využití v SD. |
OB12 | Konfigurace administrátor em | Systém musí být plně konfigurovatelný administrátorem z ČNB a musí umožňovat konfigurovat všechny procesy, workflow, rozhraní, šablony, reporty apod. bez účasti dodavatele. |
OB13 | Školení administrátor ů | Dodavatel zajistí proškolení administrátorů systému z ČNB v takovém rozsahu, aby byli schopni samostatně administrovat dodaný systém. |
OB14 | Školení klíčových uživatelů | Poskytovatel provede školení klíčových uživatelů k detailní znalosti funkcionalit dodaného systému. Toto školení proběhne před začátkem Uživatelských akceptačních testů. |
OB15 | Chat / komentáře | Systém umožní chat nebo komentáře k požadavku. Tyto komentáře zůstanou svázané s daným požadavkem. |
OB16 | Počet uživatelů | Systém musí technicky i licenčně zajistit přístup pro: • 1350 uživatelů s oprávněním zadat a schválit požadavek (zadavatelé) a/nebo 90 současně pracujících uživatelů s oprávněním zadat a schválit požadavek (zadavatelé) • 400 uživatelů s oprávněním zadat, schválit a řešit požadavek (řešitelé) a/nebo 80 současně pracujících uživatelů s oprávněním zadat, schválit a řešit požadavek (řešitelé) |
ID | Název | Popis požadavku |
OB17 | Počty položek katalogu služeb | Systém musí umožňovat definovat v katalogu služeb minimálně 10000 položek. |
OB18 | Počty SLA | Systém musí umožňovat definovat a používat minimálně 10 různých paralelně aktivních SLA služeb. |
OB19 | Počty Workflow | Systém musí umožňovat definovat a použít minimálně 100 různých paralelních Workflow. |
OB20 | Počty konfiguračníc h položek | Systém musí umožňovat definovat a použít aplikačně neomezený počet konfiguračních položek. |
OB21 | Navigace odkazem | Systém musí umožňovat zařadit do katalogu služeb služby, které budou řešeny mimo systém ServiceDesk odkazem (html) do jiného systému (např. ORASHEI – požadavek správce, požadavek uživatele). |
OB22 | Zadání v zastoupení | Možnost zadat požadavek za určitého uživatele jiným uživatelem (nejedná se o zastupování v nepřítomnosti). Zastupující uživatel musí mít možnost vidět jím založené požadavky. Uživatel, za kterého je požadavek vytvářen, je o tom automaticky notifikován. |
OB23 | Schvalování | Systém zajistí různé varianty schvalování - schvalování jednotlivcem i členem uživatelské skupiny. Proces schvalování požadavku musí umožnit dva stupně schvalování – 1. nadřízený uživatele a 2. nadřízený řešitele. Dále musí umožnit výběr schvalovatelů – jednotlivé osoby nebo skupiny a definici strategie schvalování při zadání více osob (např. 1 ze 2 nebo další varianty). Schvalovací proces musí být realizován vygenerováním e-mailové notifikace na schvalovatele obsahující url link umožňující plný náhled na schvalovaný požadavek včetně možnosti jej schválit nebo zamítnout. |
OB24 | Zastupitelnos t schvalování | Možnost nastavení zastupování schvalování v případě nepřítomnosti uživatelem na úrovni jednotlivce i uživatelské skupiny. |
OB25 | Chování dle lokality | Systém zajistí aby byla zohledněna lokalita uživatele (lokalita = fyzická lokalita zpracování/řešení požadavku): • bude před vyplňován atribut lokality automaticky dle lokality uživatele, který požadavek zadává • Předvyplněný atribut lokality musí být schopen uživatel upravit s ohledem na cílovou lokalitu řešení požadavku • Lze vyplnit jen lokalitu, která existuje v ŘDB |
OB26 | Prezentace na typech zařízení | Uživatelské rozhraní bude používat responsivní design, umožňující zobrazení na různých typech zařízení (tablet, mobilní telefon, přenosný počítač). |
OB27 | Portál řešitele | IS poskytne řešitelům přehledné zobrazení požadavku, které má řešit (s možností třídění a filtrování, výpis všech jemu přiřazených požadavků. Včetně statistiky práce v minulém období – počty vyřešených, vykázané hodiny ...). Obsah prezentovaný portálem bude uživatelsky konfigurovatelný. |
OB28 | Portál uživatele 1 | Portál uživatele bude respektovat to, že existuje definovaný, klasifikovaný seznam služeb umístěný v katalogu služeb. Každá služba nabízí uživateli činnosti, které umí, má kapacity tyto činnosti zajistit a lze je po službě požadovat. Tyto činnosti služba definuje navenek jako šablony požadavků. Je v zájmu řádného řízení služeb, aby každá služba tyto šablony měla definované. Toto bude tvořit základní řídící rámec požadavků na službu (mimo služby, které budou zpracovávány v IS ORASHEI). Tento základní řídící rámec nebude nijak navenek zbytečně zatěžovat uživatele, jen bude definováno, co lze a co nelze v rámci služby požadovat. Šablony požadavků bude možné použít kdekoli v rozhraní obrazovky, aniž by uživatel byl vystaven složitému rozhodování v postupu založení požadavku. Na základě definice šablony požadavku bude požadavek zpracován příslušným procesem. |
ID | Název | Popis požadavku |
OB29 | Portál uživatele 2 | Základní členění rozhraní obrazovky pro uživatele „zadavatele“ (ne-řešitele). Uživatelské rozhraní bude uspořádáno tak, že bude přizpůsobovat svůj vzhled roli uživatele a bude zřejmé, na kterou ze dvou sekcí se při založení požadavku obrací. Uživatel v případě potíží svých požadavků kontaktuje Helpdesk příslušné sekce. Rozhraní obrazovky nabídne uživateli následující členění. Základní rychlé nabídky pro jednotlivé oblasti mohou být například tyto (kompletní výčet bude stanoven v rámci analýzy): Pro sekci IT (příklad): • Požadavek vytvoření účtu/nastavení přístupu • Poskytnutí a podpora mobilního tel. • Požadavek na vytvoření, zrušení HW/SW/Služby ... Pro sekci správní (příklad): • Úklid • Klíč/karta • Malování • Prohlídka v Návštěvnickém centru • Společenská akce/konference v Návštěvnickém centru • Gastronomické služby ... |
OB30 | Filtry na seznamech | Uživatel by měl mít možnost definovat vlastní pohledy dle filtrů ve všech zobrazovaných seznamech. |
OB31 | Portál uživatele - základní seznamy žadatele | Umožnit definování a použití následujících seznamů (nebo obdobných zobrazovacích prvků) pro uživatele v roli Žadatel (kompletní výčet bude stanoven v rámci analýzy): • Nejčastěji používané šablony IT (Top 5 nejčastěji používaných šablon všemi uživateli) • Nejčastěji používané šablony SPR (Top 5 nejčastěji používaných šablon) • Moje šablony IT (nejčastěji používané šablony) • Moje šablony SPR (nejčastěji používané šablony) • Uživatel zde bude mít k dispozici jím již použité vyplněné šablony, tak aby je snadno na jednu operaci (kliknutí) mohl znovu použít. • Moje všechny požadavky – defaultní nastavení (mnou zadané všechny požadavky) • Moje požadavky IT (mnou zadané požadavky na IT) • Moje požadavky SPR (mnou zadané požadavky na sekci správní) • Moje KP IT (Konfigurační položky (KP), které spravuji nebo vlastním) • Moje KP SPR (KP které spravuji nebo vlastním) • Moje služby IT (služby, které má právo uživatel požadovat) • Seznam služeb IT (služby sekce informatiky) • Moje služby SPR (služby, které má právo uživatel požadovat) • Seznam služeb SPR (služby sekce správní) |
ID | Název | Popis požadavku |
OB32 | Portál uživatele - základní seznamy řešitele | Umožnit definování a použití seznamů(nebo obdobných zobrazovacích prvků) pro uživatele v roli Řešitel, bude obsahovat nabídku totožnou jako pro Zadavatele + následující (kompletní výčet bude stanoven v rámci analýzy): + pro IT • Požadavky na mě IT (mě přidělené požadavky) • Požadavky na mou skupinu IT (požadavky přidělené mé skupině) • Požadavky ke schválení IT (požadavky předložené ke schválení) • CMDB (Vstup do pohledů na konfigurační databázi) – dle role • Všechny požadavky (Náhled napříč všemi požadavky IT v SD) – dle role • Smlouvy (Katalog smluv) – dle role • + pro SPR • Požadavky na mě SPR (mě přidělené požadavky) • Požadavky na mou skupinu SPR (požadavky přidělené mé skupině) • Požadavky ke schválení SPR (požadavky předložené ke schválení) • CMDB (Vstup do pohledů na konfigurační databázi) – dle role • Všechny požadavky (Náhled napříč všemi požadavky SPR v SD) |
OB33 | Portál uživatele - uživatelská definice vzhledu | Uživatelům, odběratelům určitého okruhu služeb je umožněno si vytvořit své prostředí, zobrazením jednotlivých prvků na obrazovce dle specifického zaměření a frekvence použití služeb, tak aby pracovali s prostředím efektivněji a rychleji bez zbytečných operací. Pokud systém neumožňuje individualizaci na uživatele, musí systém umožnit vytváření individuálních vzhledů pro skupiny uživatelů, v rámci implementace bude zajištěno vytvoření aspoň 20 specifických vzhledů. |
OB34 | Portál uživatele - Průvodce založení požadavku 1 | Pro občasné návštěvníky SD vytvořit zjednodušené rozhraní pro založení požadavku pomocí průvodce minimálně s těmito volbami: • Něco nefunguje • Něco potřebuji • Mnou založené požadavky • Seznam služeb |
OB35 | Portál uživatele - Průvodce založením požadavku 2 | IS umožní použít při založení požadavků průvodce, který uživatele provede seznamem poskytovaných služeb, aby rychle našel oblast nebo službu, kterou požaduje. Ukázka možného vzhledu vstupní obrazovky pro uživatele: Systém musí umožnit oddělení jakéhokoli požadavku dle služeb, ke kterým se vztahují – např. požadavek pro IT (informatika) a požadavek pro ostatní služby (Facility Management - technologická zařízení, vybavení budov, ..). |
ID | Název | Popis požadavku |
OB36 | Rychle přístupné typy požadavků | Příklady typů požadavků, ke kterým by se uživatel měl dostat nejkratší cestou: • Požadavek na nový HW (notebook, tablet, myš, druhý monitor ….), • Požadavek na přístup do konkrétního informačního systému (pro sebe, pro někoho jiného), • Hlášení chyby v konkrétním informačním systému, • Požadavek na změnu/úpravu v konkrétním informačním systému, • Hlášení bezpečnostního incidentu (vir, phishing …) • Požadavek na antivirovou kontrolu média • Požadavek na vypálení CD/DVD • Požadavek na zřízení VPN • Požadavky na služby kolem mobilů • Požadavek na přestěhování techniky do jiné kanceláře • Hlášení problémů s tiskárnou • Požadavek na instalaci/zpřístupnění specifického SW • Hlášení problémů s e-mailem • Požadavek na zřízení účtu WEBEX • Požadavek na obnovu smazaných dat • Založení/změna projektového požadavku |
OB37 | Kalendář změn | Vytvořit pohled, který zobrazí důležité plánované změny a odstávky, které se dotýkají uživatele nebo jsou důležité formou kalendáře změn.(viz ChM6) |
OB38 | Dashboard statistik | Vytvořit pohled, který zobrazí základní statistiky Servicedesku, například počet incidentů za měsíc, počet nevyřízených požadavků, statistiky aktiv s možností uživatelsky definovat obsah pohledu. |
OB39 | Notifikace | Uživatel bude mít možnost si samostatně nastavit, zda a jaké notifikace mu mají být zasílány (vyjma povinných - schvalování, upomínky, eskalace …) |
OB40 | Export dat | Systém musí umožnit exportovat data o entitách v hierarchické struktuře (vybrané atributy, minimálně entita Služba, Konfigurační položka) do souboru ve formátu alespoň CSV. |
OB41 | Schvalování po mailu | Systém musí umožňovat schvalovat prostřednictvím strukturované odpovědi na e-mail s požadavkem na schválení, který musí obsahovat všechny relevantní informace pro schválení. (Nelze odkazem na požadavek – umožněno schvalování bez VPN přístupu do sítě ČNB.). |
OB42 | Povinné SNC atributy požadavku | U všech požadavků musí být vyplněn (atributy budou v některých případech vyplněny automaticky, v některých případech manuálně): - útvar na úrovni nákladového střediska nebo nižší. - činnost a dílčí činnost, k níž se požadovaná služba vztahuje. Činnost bude požadavku přiřazena na základě šablony, ze které byl vytvořen, případně odvozena od projektu v rámci kterého je požadavek zakládán. Útvar bude odvozen od žadatele. |
OB43 | Kopírování / duplikace požadavku | Možnost vytvoření nového požadavku zduplikováním již vystaveného požadavku (použít ho jako předvyplněnou šablonu) s možností editovat v něm jednotlivé atributy. Jako šablonu umožnit použít kterýkoliv požadavek vzniklý v minulosti bez ohledu na to, který uživatel jej vytvořil. V takto nově vzniklém požadavku není obsažena historie původního požadavku. |
OB44 | Přílohy k požadavku | Systém umožní k požadavku přiložit minimálně 20 souborů. Systém umožní u požadavku smazat přílohu. Systém musí umožnit uložit jednotlivý soubor i o velikosti minimálně 100 MB. |
OB45 | Skartace / anonymizace dat | Systém zajistí uživatelem řízenou možnost hromadného mazání/anonymizace dat po uplynutí doby od ukončení platnosti služby/položky (10 let). |
ID | Název | Popis požadavku |
OB46 | Dokumentace Uživatelská | K systému je dodána kompletní elektronická uživatelská příručka popisující způsob práce s IS SD v českém jazyce. (tj. popisy podle uživatelských rolí) Dodavatel musí dodat s každou verzí systému aktualizovanou dokumentaci. |
OB47 | Dokumentace Administráto rská 1 | Administrátorská dokumentace 1 - K systému je dodána kompletní elektronická administrátorská příručka popisující způsob administrace aplikace a dále funkční a technická specifikace v českém nebo anglickém jazyce. (tj. postupy administrace IS SD - správa uživatelů apod.) Dodavatel musí dodat s každou verzí systému aktualizovanou dokumentaci. |
OB48 | Dokumentace Administráto rská 2 | Administrátorská dokumentace 2 - K systému je dodána kompletní elektronická příručka technického správce (tj. zodpovědnosti a postupy aktualizací komponent IS SD, spuštění, zastavení, případně restart systému, řešení chybových stavů apod.). Dodavatel musí dodat s každou verzí systému aktualizovanou dokumentaci. |
OB49 | Dokumentace API | Dokumentaci pro programátora k API. Dodavatel musí dodat s každou verzí systému aktualizovanou dokumentaci. |
OB50 | Zadání požadavku mailem | Systém zajistí automatické založení požadavku na základě strukturovaného emailu vygenerovaným jiným informačním systémem. Formát zprávy bude předán dodavateli v rámci realizační studie. |
OB51 | Znalostní databáze | Systém obsahuje znalostní databázi do které mohou být zaznamenány informace a postupy řešení problémů apod. |
OB52 | Šablony | Systém obsahuje pro jednotlivé entity možnost definice a využívání šablon pro různé procesy (např. šablona pro založení serveru, šablona žádosti o přidělení PC, šablona pro opravu zařízení kanceláře ...) |
OB53 | Generátor reportů | V systému je dostupný nástroj, který umožňuje vytváření uživatelských výstupů ve formátu XLSX, DOCX nebo PDF. |
OB54 | Zobrazení dat v samostatných oknech | Všechny informace ve všech pohledech a formulářích lze zobrazit ve více samostatných oknech, takže je pak snadnější se mezi okny pohybovat a například porovnávat jednotlivé informace nebo otevírat dokumenty obdobného určení (např. protokoly o kontrole). |
OB55 | Nápověda | Informační systém umožní zobrazit nápovědu, která vysvětlí funkci prvků na obrazovce. |
OB56 | Navigátor | U každé zpracovávané entity (požadavku) grafická mapa v jakém stavu se požadavek nachází a co následuje. |
ID | Název | Popis požadavku |
AD01 | Uživatelské šablony | Systém musí umožnit administrátorovi zakládání a správu šablon pro jednotlivé entity (požadavky, změny, problémy, incidenty ...). |
AD02 | Vlastní atributy | Systém musí umožnit definice vlastních atributů u všech základních entit systému (Požadavek, Konfigurační položka, ...). Vlastní atribut definujeme jako přidané informace k danému typu entity. K vlastním atributům bude možnost přidávat jejich vlastnosti (povinné, nepovinné, datový typ, výčet povolených hodnot atd.). Možnost napojení vlastních atributů na číselníky. |
AD03 | Editace workflow | Systém musí obsahovat propracovaný a přehledný nástroj pro tvorbu workflow společně s přehlednou a detailní správou tvorby pravidel stavů entit a následných akcí z toho vyplývajících. Pro každou entitu je možno definovat samostatné workflow. |
AD04 | Workflow | Systém umožní vytvořené workflow uložit (zazálohovat). Užití pro provedení zálohy před změnou workflow, nebo pro případ obnovy nově nainstalovaného systému. |
ID | Název | Popis požadavku |
AD05 | Možnost úpravy klientských formulářů | Systém musí umožňovat editaci vlastních formulářů – definovat, které pole se zobrazují a jejich umístění na formuláři atd. |
AD06 | Notifikace | Systém musí umožnit definici notifikace e-mailem dle nastavených podmínek pro atributy entit (např. při změně stavu entity). Systém musí umožňovat, aby obsahem notifikace byly i atributy předmětných entit (např. kód požadavku, předmět, ...). Zprávu musí být možné nadefinovat jak ve formátu plain text, tak i HTML. Xxxxxx odesílající zprávy musí odpovídat internetovým standardům (RFC). Možnost volání tiketu z notifikace > link. |
AD07 | Uživatelé budou k systému přistupovat pomocí webového prohlížeče | Uživatelé budou k systému přistupovat pomocí webového prohlížeče. Je požadována kompatibilita s prohlížeči Chrome a Edge v podporovaných verzích, bez nutnosti instalace doplňkových komponent na straně klienta (např. Silverlight, Java ...). |
AD08 | API | Systém musí mít programové rozhraní ve formě webových REST API služeb, s jejichž pomocí lze zajistit přinejmenším stejné akce či úkony jako s klientem. Dokumentace musí obsahovat postupy užití a příklady programové práce nad entitami (Požadavek, Konfigurační položka, ...). Možnost REST API pro práci s SD a CMDB. Programátor ČNB musí být schopen na základě dokumentace a REST API naprogramovat funkční kód. |
AD09 | Dokumentace datového modelu | K systému je dodána dokumentace datového modelu databáze, na základě kterého musí být možné vytvořit dotaz na konkrétní data obsažená v databázi. Na úrovni datového modelu musí být řešeny i vazby mezi entitami. |
AD10 | Lokalizace | Uživatelské rozhraní (GUI) musí být v češtině. GUI pro administraci systému může být v angličtině nebo češtině. |
AD11 | Přístupová práva a role | Systém musí umožnit definovat přístupová práva pro jednotlivce i skupiny řešitelů pomocí rolí. Přístupová práva musí být možné definovat na úrovni přístupu ke kategoriím entit (např. Požadavky) i k jednotlivým atributům entit (např. jedna skupina může mít právo pouze zobrazit atributy entity, ale jiná může i některé atributy editovat). Přístupová práva k entitám se budou definovat i na základě atributů entity (např. podle atributu Lokality). |
AD12 | Integrace s Windows Active Directory | Systém musí podporovat Single Sign-On funkcionalitu využívající účty uživatelů v Microsoft Active Directory. Přístupová práva musí být možné přidělovat jak Windows uživatelským účtům, tak i skupinám. |
AD13 | Historie změn atributů | Každá entita (Požadavek, Konfigurační položka, ...) musí mít možnost evidovat historii všech změn zvolených atributů včetně informace kdo a kdy změnu provedl. |
AD14 | Synchronizace dat s externími databázovými zdroji | Systém zajistí automatickou synchronizaci atributů stávajících entit, číselníků i automatické vytváření a odstraňování celých entit na základě události (vytvoření, odstranění záznamu či změně hodnoty) v externím databázovém zdroji. Příklad: změna organizačního zařazení pracovníka v personální databázi, změna popisu konfigurační položky nebo vyřazení konfigurační položky v databázi správy majetku. |
AD15 | Zpřístupnění dat pro SIEM | Systém zpřístupňuje databázové view s daty o entitách Konfigurační položka nebo jejich automatický export v pravidelných intervalech do souboru CSV. |
ID | Název | Popis požadavku |
AD16 | Auditní log | Systém umožňuje logování všech významných bezpečnostních událostí v systému: úspěšné i neúspěšné přihlašování a odhlašování ke všem účtům • činnosti provedené administrátory • úspěšné i neúspěšné manipulace s účty, oprávněními a právy • neprovedení činností v důsledku nedostatku přístupových práv a oprávnění • činností uživatelů, které mohou mít vliv na bezpečnost informačního systému • zahájení a ukončení činností technických aktiv • kritická i chybová hlášení technických aktiv • přístupy k záznamům o událostech, pokusy o manipulaci se záznamy o událostech a změny nastavení nástroje pro zaznamenávání činností Každý záznam musí obsahovat minimálně: • datum a čas včetně specifikace časového pásma s přesností na sekundy • typ činnosti • identifikaci technického aktiva, které činnost zaznamenalo • jednoznačnou identifikaci účtu, pod kterým byla činnost provedena • jednoznačnou síťovou identifikaci zařízení původce • úspěšnost nebo neúspěšnost činnosti Logy systému budou nepřetržitě dostupné systému SIEM, buďto aktivním sběrem logů s využitím lokálního nebo doménového servisního účtu nebo automatickým posíláním pomocí syslog. |
AD17 | Standardní systémové prostředí ČNB | Systém je schopný provozu na standardním systémovém prostředí objednatele (ČNB) (viz příloha č. 2 smlouvy). |
AD18 | Zálohování | Systém musí umožnit zálohu a obnovu dat, především v systému uživateli založených entit (požadavky, konfigurační položky, …) a nastavení konfigurace. |
AD19 | Přenos mezi prostředími | Systém zajišťuje bezodstávkový přenos konfigurací procesů / workflow (vývoj-test- produkce) |
ID | Název | Popis požadavku |
CfM01 | Konfigurační databáze (dále označováno jako Configuratio n management database CMDB) | Musí umožňovat správu aktiv určených správcem, tak aby bylo možné naplnit požadavky ML 720/5/2015 a vyšších předpisů vyplývající ze ZoKB. CMDB musí umožňovat správu aktiv (interně aktiva nazýváme a označujeme jako KP – konfigurační položka). Musí umožňovat hierarchické členění do kategorií (min. 3 úrovně). Základní schéma řízení: |
CfM02 | CMDB pro 2 oblasti: IT a Facility Management | Základní oddělení dat, procesů a služeb. Systém tedy umožní oddělit přístup k určitým konfiguračním položkám pro různé skupiny uživatelů dle práva a rolí. |
CfM03 | Konfigurační Položka | Konfigurační položka je objekt popsaný řízenými/neřízenými atributy, vazbami na jiné KP a další entity (služby, incident, změna, problem, požadavky, smlouvy, přílohy) v rámci SD. Systém umožní vytvářet různé typy KP s různými atributy, vazbami KP. Možnost vytváření vazeb mezi KP a jejich textové a grafické zobrazení. |
CfM04 | Hromadné úpravy KP | Systém umožní hromadné úpravy KP, hromadné editace atributů a vazeb (např. změna zodpovědné osoby pro více položek najednou). |
CfM05 | Výměny KP | Možnost výměny KP za jinou KP při zachování vazeb na jiné KP (výměna serveru). |
CfM06 | Povinné atributy KP | Možnost povinných atributů. |
CfM07 | Automatizov ané úpravy KP | U atributu lze automatizovaně měnit jejich hodnotu na základě jiných událostí (např. změna stavu apod.) |
CfM08 | Filtry na seznamu KP | Seznam konfiguračních položek umožňuje vyhledávání dle filtru, definice filtru, uložení filtru. |
ID | Název | Popis požadavku |
CfM09 | Workflow KP | Možnost definovat workflow pro řízení životního cyklu konkrétního typu KP: Workflow řízené na základě stavů a zdrojů dat ŘDB a ORASHEI. Compliance se základním stavem v majetku. Podpora e-mail notifikace při změně stavu vybraným skupinám. |
CfM10 | Evidence bez vazby na účetnictví | Systém musí umožňovat evidenci Konfigurační položky bez ohledu na její stav/existenci v účetnictví (systému Orashei). KP (aktiva) mohou být evidovány ještě před přiřazením inventárního čísla, při zápůjčkách apod, |
CfM11 | Reporty KP | Možnost definice textových a grafických sestav a reportů nad CMDB pro prezentaci KP a jejich vzájemných závislostí s cílem poskytovat uživateli podporu v rozhodování prezentace služby, popřípadě dalších vztahů, jako např. osob, dodavatelů. Výstup prezentace na obrazovku, do souboru pro další zpracování, na tisk. Možnost reportovat požadavky podle služby, nákladového střediska, činnosti.. Možnost reportu služeb a činností Možnost reportu KP vs. Služba/Služby |
CfM12 | Autentizace/ Autorizace na úrovni CMDB | Možnost řízení přístupu do CMDB až na úroveň KP na základě rolí. Na základě kategorií nebo KP. Možnost autorizace na základě atributu KP. |
CfM13 | Dokumentace CMDB | Kompletní čitelný relační datový model CMDB. |
CfM14 | Historie | Detailní zaznamenání historie aktivit konfigurační položky systému CMDB. Konfigurovatelné. |
CfM15 | Evidence smluvních partnerů | Systém zajistí vedení evidence smluvních partnerů. |
CfM16 | Evidence smluv | Systém zajistí vedení evidence smluv o podpoře. Vazba dodavatel/smlouva/KP. |
CfM17 | Evidence osob | Systém zajistí vedení evidence osob, xxxxxx jako aktiva/aktéra v CMDB/SD. |
CfM18 | Přebírání skupin z ŘDB | Systém zajistí převzetí osob, skupin ŘDB , které budou použity pro napojení aktiva/aktéra na konfigurační položku. |
ID | Název | Popis požadavku |
CfM19 | Pohledy na data CMDB | Možnost nastavení uživatelských pohledů na data konfigurační databáze (seznamů) včetně možnosti aplikace filtrů. Uživatelské pohledy je možno uložit. Např. zobrazení všech KP dané kategorie atd. |
CfM20 | Přístup a role v CfM | CfM bude podporován možností definice a řízením rolí a přístupových práv na KP. Např: Role CfM, role VS KP, role TS KP. |
CfM21 | Evidence služeb a informačních systémů | V systému musí existovat evidence provozovaných informačních systémů a dalších aplikací čerpajících zdroje (viz dále) a služeb poskytovaných sekcí informatiky, přičemž ke každému informačnímu systému, aplikaci i službě musí být přiřazena činnost dle tabulky činností. |
CfM22 | Report serverů | V systému musí existovat přehled všech provozovaných fyzických i virtuálních serverů s následujícími informacemi: - Jedinečný kód serveru - Virtuální/Fyzický server - Inventární číslo (pro fyzický server) - Odkaz na farmu (pro virtuální server) - Gestor serveru - Informační systém nebo jiná služba (viz evidence služeb a informačních systémů), které server slouží (je možné, že jeden server bude sloužit více informačním systémům nebo službám) nebo informace že - jde o fyzický server pro farmu virtuálních serverů - jde o fyzický server pro farmu virtuální PC - Informace o speciálních typech serverů - databázový server ORACLE - aplikační server ORACLE (Forms/APEX/…..) - webový server pro aplikace ORACLE - Informace o bráně DMZ, v níž je server umístěn - Hostname - Popis - Datum uvedení do provozu |
CfM23 | Report databází | V systému musí existovat evidence databází, přičemž pro každou databázi musí být k dispozici Informační systém nebo služba, které databáze slouží a musí být možné pro jednu databázi evidovat více systémů/služeb s případným procentním rozdělením kapacity databáze (neplatí pro "servery" EXADATA, které se sledují jinak). |
CfM24 | Migrace CMDB | Do systému budou převedeny všechny aktivní konfigurační položky a služby (jak z oblasti IT tak z oblasti sekce správní). Jedná se o cca 30000 položek. Dále budou převedeny všechny odpovídající číselníky (např. kategorie konfiguračních položek, smlouvy o údržbě apod.). |
ID | Název | Popis požadavku |
ChM01 | Proces Change management | Systém musí mít schopnost řídit proces Change Management (dále jen ChM) podle ML 720/2/2015.Požadavek na změnu má svůj proces a měl by vzniknout ze základního rozdělení. Snahou základního rozdělení je eliminovat vytváření ZMIT ze SPIT, oba procesy zjednodušit a zpřehlednit. Definice procesu viz níže |
ChM02 | Šablony požadavku na ZMIT | Možnost vytvářet šablony standardizovaných či opakujících se změn s dílčími požadavky (např. při založení požadavku na server se vygeneruje zároveň i dílčí požadavek na přidělení IP adresy apod.) |
ChM03 | Atributy | Na základě šablon možnost vytvářet formuláře změnových požadavků s různými typy atributů, příloh, vazeb mezi procesními entitami a KP. |
ChM04 | Workflow | Možnost správy (editace, import/export) workflow v grafické podobě. |
ChM05 | Schvalování | Možnost v rámci workflow řešit schvalování, strategii schvalování více schvalovateli, schvalování pomocí skupiny. |
ChM06 | Kalendář změn | Možnost vytváření a publikace kalendáře změn a odstávek. Možnost publikace oznámení konkrétní změny na intranetový portál přes XML soubor. |
ChM07 | Notifikace | Možnost v rámci workflow definice e-mail notifikací. |
ChM08 | Možnost navazujících úloh | Možnost vytvářet vazby mezi změnami. Ze změny bude možno vytvořit další změnu. |
ChM09 | Vyhledávání | Možnost vyhledávání/filtrování změn přes atributy v seznamu změn. |
ChM10 | Historie životního cyklu | Systém poskytuje výstup historie ZMIT, tak aby bylo prokazatelné historický sled událostí vývoje ZMIT s možností konfigurace sledování událostí. Z výstupu bude možné zjistit čeho se změna týkala a jednotlivé operace, které s ní byly provedeny. |
ChM11 | Filtry na seznamech | Systém umožňuje nastavení uživatelsky definovaných filtrů na seznamy změn). |
ChM12 | Role | ChM bude podporován možností definice rolí a přístupových práv pro jednotlivé aktéry dle workflow. Např. Role change managera, řešitele, schvalovatele, žadatele, zadavatele atd. |
Service Request + Incident Management
V rámci této oblasti je řešena identifikace, zaznamenání, klasifikace a řešení servisních požadavků (SP)/incidentů - hlášení o poruchách (IN), dokud není požadavek splněn a v případě incidentu/poruchy,
dokud není obnoven normální provoz zasažených služeb; funkční a hierarchická eskalace; vazba na znalostní databázi a příslušné výstupní sestavy.
ID | Název | Popis požadavku |
SRIM01 | Úvodní obrazovka | Systém musí umožnit přihlášení uživatele s využitím SSO do úvodní obrazovky (web rozhraní), ve které si uživatel vybere oblast pro svůj požadavek. Úvodní obrazovka musí umožnit přístup do znalostní databáze, aby si uživatel mohl najít odpověď na svůj dotaz nebo postup, jak opravit nefunkčnost (vyřešené požadavky), návody vypracované Helpdeskem, interní příručky apod.). |
SRIM02 | Formulář požadavku (+ příloha) | Uživatelé zadávají požadavky formou formulářů/šablon, které jsou definovány pro jednotlivé služby nebo skupiny služeb. Při zakládání požadavků jsou některé atributy vyplněny automaticky (např. žadatel, lokalita apod.). Součástí požadavku mohou být i přílohy – dokumenty ve formátech MS Office, txt nebo PDF. Při telefonickém oznámení požadavku zákazníka vyplňuje formulář operátor dispečinkového pracoviště HeplDesku za uživatele. |
SRIM03 | Dodatečné atributy | Systém umožní u vybraných typů požadavků/šablon přidat různé atributy, například • útvar, pro který je požadováno (odlišný od zadavatele požadavku) • činnost, pro kterou je požadováno (odlišnou od typu požadavku i zadavatele) • lokalita – odlišná lokalita od lokality zadavatele • apod. Atributy umožní uživateli vyhledat v číselnících s tím, že číselník činností je vícestupňový. Řešitel může tyto hodnoty měnit v průběhu řešení. |
SRIM04 | Šablony | Systém musí umožnit tvorbu šablon SP s názvy údajů pro vyplnění nebo s předvyplněnými údaji pro snazší a rychlejší založení požadavku. |
SRIM05 | Info o požadavku | 1. Uživatel: Systém obsahuje přehledné web rozhraní pro uživatele, obsahující seznam všech jeho požadavků (incidentů), případně na ně navazujících problémů, změn a pracovních příkazů. 2. Řešitel: Systém obsahuje GUI rozhraní pro řešitele se seznamem požadavků, incidentů, pracovních příkazů, problémů a změn, přidělených jeho skupině k řešení, aby mohl zaevidovat popis způsobu jejich vyřízení. |
SRIM06 | Klasifikace požadavků | a) Systém musí umožnit definice kategorií servisního požadavku - dotaz, porucha/incident, požadavek a jejich priorit (dopad + naléhavost). Po vyřešení požadavku/incidentu pak možnost definice způsobu uzavření a klasifikačního zařazení ve vztahu ke KP. |
SRIM07 | Workflow požadavku | 1. Systém musí mít možnost definovat workflow pro řízení životního cyklu požadavku/incidentu, schvalování a eskalaci požadavku na další úrovně systémové podpory (funkční eskalace) a na liniového manažera (hierarchická eskalace) dle hodnot stavu a dalších atributů požadavku. 2. Systém musí pro vybrané služby umožnit nastavení automatické funkční eskalace na skupinu řešitelů. 3. Workflow musí být podporováno e-mailovými notifikacemi. |
SRIM08 | Schvalování požadavku | Proces schvalování požadavku musí umožnit dva stupně schvalování – 1. nadřízený uživatele a 2. nadřízený řešitele. Dále musí umožnit výběr schvalovatelů – jednotlivé osoby nebo skupiny a definici strategie schvalování při zadání více osob (např. 1 ze 2 nebo další varianty). Schvalovací proces musí být realizován vygenerováním e-mailové notifikace na schvalovatele obsahující url link umožňující plný náhled na schvalovaný požadavek včetně možnosti jej schválit nebo zamítnout. |
ID | Název | Popis požadavku |
SRIM09 | Reporty | 1. On-line náhledy na předdefinované sestavy v textové nebo grafické podobě s možností definice vlastního zobrazení. 2. Možnost exportu grafů/tabulek do CSV, XLS, HTML, PDF souborů. 3. Systém publikace a přístupu k hotovým nebo on-line reportům s možností aplikace výběrových filtrů a vyhledávání dle zadaného textového řetězce pro ostatní procesní manažery nebo jiné uživatele (např. věcné správce služeb) prostřednictvím webového rozhraní. 4. Možnost tvorby souhrnné statistiky požadavků /incidentů a požadavků vztahující se k jedné službě. |
SRIM10 | Řešení požadavků incidentem | Systém umožňuje vyřešit požadavek na základě vyřešení incidentu (tj vyřeší několik požadavků). |
SRIM11 | Info na portál ČNB | Systém musí umožnit vytvoření zprávy na Portál ČNB z požadavku/incidentu („Informace pro uživatele“, „Nefunkčnost/výpadek IS/IT“, „Plánovaná odstávka IS/IT“) |
SRIM12 | Požadavky | Některé požadavky zákazníků jsou komplexnější a skládají se z několika požadavků pro další řešitele (například přidělení klientské stanice zákazníkovi). Systém musí umožnit vytvořit a evidovat tyto požadavky v návaznosti na “hlavní” či “zastřešující” požadavek. |
SRIM13 | Dědění atributů | Při vytváření podřízeného požadavku se budou automaticky dědit hodnoty atributů z nadřízeného požadavku. Které atributy se mají dědit, bude možno konfigurovat pro každý typ požadavku/šablonu samostatně. S možností následné editace uživatelem. |
Problém lze definovat jako příčinu jednoho nebo více incidentů. Cílem je zamezení výskytu problémů a následných incidentů, eliminování opakujících se incidentů a minimalizování dopadu incidentů, kterým nelze zabránit. Proces Správa problémů má jak reaktivní, tak i proaktivní aspekty. Reaktivní činnosti se soustřeďují na řešení problémů vyvolaných incidenty, proaktivní činnosti se zaměřují na identifikaci a
řešení problémů a známých chyb ještě předtím, než se stanou incidenty.
ID | Název | Popis požadavku |
PrM01 | Klasifikace problémů | Systém musí umožnit členění problémů na reaktivní a proaktivní a definovat prioritu problému (dopad + naléhavost). Proaktivní (aktivně zjištěné slabé místo v infrastruktuře IT/IS). Reaktivní (opakující se Incidenty, příp. Incidenty, které vykazují shodné nebo podobné příznaky). |
PrM02 | Uzavření problému | Vyřešení musí být povinně vyplněno. |
PrM03 | Atributy a vazby problému | Systém musí umožnit: - definice, úpravy a přidávání atributů problému, včetně možnosti definice povinného vyplnění atributů a nastavení historie jejich změn |
PrM04 | Grafické zobrazení vazeb | - textové (grafické) zobrazení vazeb problému na entity, ke kterým se vztahuje – Požadavek, Změna, KP a Služba. |
PrM05 | Workflow problému | Systém musí mít možnost definovat workflow pro řízení životního cyklu problému a pro eskalaci problému na další úrovně systémové podpory (funkční eskalace) a na liniového manažera (hierarchická eskalace) dle hodnot stavu a dalších atributů problému. |
PrM06 | Workflow notifikace | Workflow musí být podporováno e-mailovými notifikacemi. |
ID | Název | Popis požadavku |
PrM07 | Problém z více požadavků | Řešení některých problémů je komplexnější a může se skládat z několika požadavků pro další řešitele. Systém musí umožnit vytvořit a evidovat tyto požadavky v návaznosti na “hlavní” či “zastřešující” problém. |
Správa úrovně služeb – definování, sjednávání a řízení úrovní zákazníkem požadovaných služeb a
příslušné výstupní sestavy. Service Level Agreement (SLA) je psaná dohoda či smlouva mezi zákazníkem (např. útvarem využívajícím službu) a poskytovatelem služeb, která dokumentuje dohodnutou nadstandardní úroveň služeb.
ID | Název | Popis požadavku |
SLM01 | Katalog služeb | Hierarchický katalog služeb – min. 3 úrovně s možností úprav hierarchie a vazeb (např. Služby IT/Informační systémy/Docházka,…) IS SD bude disponovat katalogem služeb s možností přiřazení SLA |
SLM02 | Atributy Služby | Systém musí umožnit definice, úpravy a přidávání atributů služby, včetně možnosti definice povinného vyplnění atributů a nastavení historie jejich změn. Na implementační úrovni lze definovat viditelnost a povinnost atributů daného objektu. IS SD bude moci definovat i uživatelské atributy, včetně sledování historie změny hodnoty atributů. |
SLM03 | Vazby Služeb | Možnost evidence a zobrazení vazeb mezi službou a KP, které ji podporují. Možnost evidence a zobrazení vazeb mezi službami, včetně obousměrných vazeb (tzn. služba A využívá službu B, služba B využívá službu A). Služba bude obsahovat ke každé službě seznam KP, které ji podporují. Vztahy mezi službami budou uloženy pomocí vazební tabulky. Zobrazení vztahu bude jak v textové tak grafické podobě. Vazba mezi službami bude obsahovat popis této vazby přístupný uživateli. |
SLM04 | SLA | Služba může mít vytvořeno a přiřazeno 1 a více SLA. Přiřazení služby ke skupině koncových uživatelů. IS SD bude mít možnost definice úrovně služeb. Součástí definice SLA budou i služby, které jsou danou SLA pokryty. Systém musí umožnit přiřazení určité služby a SLA pouze určité skupině koncových uživatelů. |
SLM05 | Atributy SLA | Možnost definice, úprav a přidávání atributů SLA. Systém umožňuje přidávat k SLA parametry včetně kategorie závažnosti. |
SLM06 | Workflow | Systém musí mít možnost definovat workflow pro řízení životního cyklu služby a SLA. Tzn., že Služba a SLA prochází jednotlivými stavy životního cyklu, který je jednoznačně definován. Workflow musí být podporováno e-mailovými notifikacemi. Systém umožňuje definovat k objektům workflow pro řízení jejich životního cyklu. Workflow umožňuje odesílat e-mailové notifikace a zprávy uživatelům nebo skupinám uživatelů. |
ID | Název | Popis požadavku |
SLM07 | Migrace | Ze stávajícího systému budou převedeny do nového systému všechny provozované služby, jejich vazby na KP, SLA a vybrané číselníky nutné pro proces SLM – jedná se o stovky záznamů. Datová struktura IS SD bude disponovat základnou pro import v požadovaných atributech. Rozsah importu bude definován v rámci realizační studie. |
ID | Název | Popis požadavku |
PŘEDPROJ. PŘÍPRAVA A PROJEKTY | ||
PRJ01 | Podchycení projektových aktivit | IS zajistí sledování požadavků souvisejících s projektem (dále jen PP = projektové požadavky). V rámci projektových aktivit budou podchyceny následující typy požadavků (s různými šablonami a workflow): • Projektový požadavek jednoduchý • Projektový požadavek vývojový • Předběžná studie • Podnět Čas vykázaný na tyto požadavky bude započítáván do projektu. |
PRJ02 | Podchycení předprojektové přípravy | IS zajistí sledování požadavků souvisejících s předprojektovou přípravou (dále jen PřP = předprojektová příprava). V rámci předprojektové přípravy budou podchyceny následující typy požadavků: • Podnět |
PRJ03 | Vazby projektu na neprojektové aktivity | IS umožní zaznamenat vazbu na projekt (ID Projektu) i pro všechny ostatní aktivity, sledované v SD (Požadavky, Změny ...). . |
PRJ04 | Napočítávání vykazovaného času na projekt | U požadavků, které nejsou PP nebo PřP, ale obsahují vazbu na projekt, bude možné při jeho založení zaznamenat, zda se na nich odvedený čas má započítat do součtů vykázaných hodin na projekt |
PRJ05 | Šablony projektu | Systém umožní uživatelskou definici šablon projektu, ve kterých bude možné připravit dopředu strukturovanou množinu projektových požadavků. Použitím šablony systém vytvoří podřízené požadavky (PP, PřP), které jsou v šabloně definovány. V systému budou založeny dvě základní šablony: • běžný projekt (plná projektová aktivita se všemi povinnými fázemi projektu) • pracovní požadavek (de facto malý projekt, který nemá povinně definované fáze projektu – chování systému by mělo být stejné jako u běžného projektu) |
PRJ06 | Dědění atributů | Při vytváření podřízeného PP/PřP se budou automaticky dědit hodnoty atributů z nadřízeného PP/PřP s možností následné editace uživatelem. Které atributy se mají dědit a editovat, bude možno konfigurovat pro každý typ PP/PřP/šablonu samostatně. |
PRJ07 | Import číselníků | Systém využije číselníky, které jsou spravovány externími systémy: • číselník projektů a projektových požadavků • číselník podnětů • číselník činností/dílčích činností SNC Bude zajištěna pravidelná automatická aktualizace. |
PRJ08 | Projektový tým | Systém umožní pro každý projekt určit projektový tým, který bude mít přístup k projektovým požadavkům. |
ID | Název | Popis požadavku |
PRJ09 | Role projektového týmu | Pro členy projektového týmu bude pro každý projekt možné určit role, definující možnosti práce s jednotlivými PP. Bude se jednat minimálně o role: • Projektový vedoucí • Člen projektového týmu • Čtenář |
PRJ10 | Role Projektový vedoucí | Uživatel v roli Projektový vedoucí bude mít pro daný projekt možnost: • definovat členy týmu • přiřadit role členům týmu • nastavit PP/PřP do stavu „Uzavřeno“ • měnit stav PP/PřP, který je ve stavu „Uzavřeno“ • pracovat v rozsahu role Člen projektového týmu |
PRJ11 | Role Člen projektového týmu | Uživatel v roli Člen projektového týmu bude mít pro daný projekt možnost: • zakládat PP/PřP • měnit data v PP/PřP • měnit stav PP/PřP (kromě stavu „Uzavřeno“) |
PRJ12 | Role Čtenář | Uživatel v roli Čtenář bude mít pro daný projekt možnost: • číst data PP/PřP |
PRJ13 | Specifické atributy PP | Systém umožní zaznamenání minimálně těchto atributů ke každému PP: Typ (Proj. požadavek jednoduchý/proj. požadavek vývoj/podnět/předběžná studie) ID projektu (skrze projekty bude dále získána vazba na SNC Činnost/Dílčí činnost) |
PRJ14 | Specifické atributy PřP | Systém umožní zaznamenání minimálně těchto atributů ke každému PřP: • Typ (Podnět) • ID podnětu (jen pro typ Podnět) |
PRJ15 | Společné atributy PřP a PP | Systém umožní zaznamenání minimálně těchto atributů ke každému PP: • ID požadavku • ID nadřazeného požadavku • Název požadavku • Popis požadavku • SNC Činnost/Dílčí činnost projektu • Stav • Priorita • Založil (člen proj. týmu, vyplněno automaticky) • Kdo požadoval (vyplněno automaticky, ale jde změnit za jiného člena proj. týmu) • Nákladové středisko (vyplněno automaticky dle osoby uvedené v Kdo požadoval) • Přiřazený řešitel/řešitelé (členové proj. týmu) • Plánované Datum/čas zahájení • Plánované Datum/čas dokončení • Skutečné Datum/čas zahájení (automaticky dle vykázaných hodin) • Skutečné Datum/čas dokončení (automaticky dle vykázaných hodin) • Vykázané hodiny interních lidí (automaticky dle vykázaných hodin na tento požadavek) • Suma vykázaných hodin včetně podřízených (automaticky jako součet vykázaných hodin na tento požadavek a sumy vykázaných na celý strom podřízených požadavků) • Vykázané hodiny externistů • Suma vykázaných externistů (automaticky jako součet vykázaných hodin externistů na tento požadavek a sumy vykázaných na celý strom podřízených požadavků) |
ID | Název | Popis požadavku |
PRJ16 | Základní stavy PP/PřP | U projektových požadavků jednoduchých bude možné sledovat následující stavy: • Plánovaný • K realizaci • Řeší se • Vyřešený • Uzavřený |
PRJ17 | Speciální stavy PP (Projektový požadavek vývojový) | V případě typu Projektový požadavek Vývojový bude možné sledovat následující stavy: • Plánovaný • K realizaci • Převzat • Upřesňován • Řeší se • Pozastaven • Vyřešený • Připraven k testu • Testovaný • Akceptovaný • Uzavřený • Zrušen |
PRJ18 | Řešitelé PP/PřP | K projektovému požadavku je možné definovat jednoho nebo více řešitelů z členů projektového týmu. |
PRJ19 | Notifikace PP/PřP | Systém zajistí minimálně následující notifikace: • řešiteli byl přidělen PP (obdrží řešitel) • změna PP (obdrží řešitel a zadavatel) • PP je ve stavu vyřešen (obdrží zadavatel a Projektový vedoucí) |
PRJ20 | Přeplánování Drag&Drop | Možnost změna polí Plánované zahájení/dokončení z grafického prostředí Gantt diagramu, kalendáře |
PRJ21 | Pravidla pro změny požadavků | Datum a čas zahájení řešení požadavku nesmí být měněn, pokud je datum zahájení řešení požadavku menší nebo roven aktuálnímu datu. Datum a čas ukončení řešení požadavku nesmí být měněno, pokud je datum ukončení menší než aktuální datum. |
PRJ22 | Plánování po lidech | Systém umožní při založení PP naplánovat očekávaný počet čld na jeho řešení po jednotlivých řešitelích. |
VYKAZOVÁNÍ ČASU | ||
VC01 | Vykazování času | Systém umožní importovat z externího vykazovacího systému (SNC) skutečně vykázané časy jednotlivých řešitelů a jednotlivé požadavky (včetně update při změně v SNC) po jednotlivých dnech. |
VC02 | Identifikace ID SNC/činnost | SNC činnost bude u požadavku automaticky určena: • typem požadavku/šablonou (tj. všechny požadavky daného typu/šablony budou odváděny na jednu SNC činnost) • nebo příslušností k Projektu nebo Podnětu • Manuálně při založení požadavku |
VC03 | Vykazování času | Systém poskytne data všech požadavků dle řešitelů, činností případně dalších atributů za otevřené vykazovací období (dle SNC až jeden kalendářní rok) pro externí vykazovací systém v reálném čase. |
ID | Název | Popis požadavku |
REPORTING | ||
R01 | Základní projektový přehled | Systém umožní zobrazit všechny požadavky, vztažené k projektům, s možností třídit a filtrovat: • ID požadavku • typ (PP/PřP, jiný neprojektový...) • ID Projektu • Název požadavku • Zadavatel • Řešitel • Priorita • Stav • Založeno dne • Termín do • Vykázáno hodin SNC • Vykázané hodiny externistů Možnost exportu do formátu MS Excel. |
R02 | Projektový dashboard | Systém umožní vytvoření přehledového dashboardu s možností vlastní definice zobrazovaných dat o PP/PřP s možností grafické prezentace (počty, součty za období ...), který si bude moci každý uživatel konfigurovat dle svých potřeb. |
R03 | Projektový reporting hierarchických PP/PřP | U PP/PřP, které mají podřízené PP/PřP, systém umožní zobrazit seznam podřízených PP/PřP. |
R04 | Report Gantt | Systém umožní zobrazit Gantt diagram u požadavků, u kterých existují podřízené požadavky, na člověka, na projekt, …. (v období) |
R05 | Karta projektu | Systém umožní zobrazit report, který po zadání čísla projektu a období od-do zobrazí následující data: • ID a název projektu • Tabulka členů projektového týmu, u každého člena počet řešených požadavků a suma vykázaných hodin • Tabulka nebo graf vykázaných hodin a počet požadavků, na které byly hodiny vykázány, po týdnech • Výpis požadavků k danému projektu Možnost exportu do formátu MS Excel |
R06 | Karta podnětu/předb ěžnou studii | Systém umožní zobrazit report, který po zadání čísla podnětu/předběžné studie a období od-do zobrazí následující data: • ID a název podnětu • Tabulka osob, které na daný podnět vykázaly a suma vykázaných hodin • Tabulka nebo graf vykázaných hodin a počet požadavků, na které byly hodiny vykázány, po týdnech • Výpis požadavků k danému podnětu/předběžné studie Možnost exportu do formátu MS Excel |
R07 | Report pro SNC | Musí existovat výstup vybraných druhů požadavků ve struktuře: • Číslo požadavku (jedinečný identifikátor) • Typ požadavku • Nákladové středisko, které požadovalo zajištění služby (ve formátu složeného čísla útvaru používaného v ČNB -(např. "0700 0223 03") • Činnost, pro kterou se příslušný požadavek realizuje (ve formátu kódu činnosti poskytnutém ve vstupním view.) • Popis požadavku (resp. jiné informace z požadavku sloužící k jeho identifikaci.) |
Kybernetická bezpečnost - funkční požadavky
ID | Název | Popis požadavku |
KB01 | Atributy služby | Systém musí umožnit pro Službu IT (informační systém) evidovat atributy: • Klasifikace podle ZoKB • Důvěrnost + integrita + dostupnost nebo Kritičnost + citlivost • RTO, RPO s výběrem hodnoty z číselníku a • Minimální úroveň služby jako volný text |
KB02 | Atributy konfigurační položky | Systém musí umožnit pro Konfigurační položku (technické aktivum) evidovat atributy: • Klasifikace podle ZoKB • Důvěrnost + integrita + dostupnost nebo Kritičnost + citlivost • RTO, RPO s výběrem hodnoty z číselníku. |
KB03 | Editovatelné číselníky | Systém musí umožnit změnu číselníků pro atributy bez programátorského zásahu. |
KB04 | Nové atributy | Systém musí umožnit definovat nové atributy pro Službu a Konfigurační položku |
KB05 | Evidence garantů | Systém musí umožňovat k Službám a Konfiguračním položkám evidovat věcné správce |
KB06 | Evidence podpůrných aktiv | Systém umožňuje pro Službu IT (informační systém) evidovat netechnická podpůrná aktiva • Dodavatelé • Zaměstnanci podílející se na provozu, rozvoji, správě nebo bezpečnosti |
KB07 | Evidence vazeb | Systém musí umožňovat evidovat vazby mezi Službou a Konfiguračními položkami a mezi Konfiguračními položkami navzájem a rozlišovat typ vazby (s výběrem hodnoty z číselníku) |
KB08 | Grafické zobrazení vazeb | Systém musí umět zobrazit vazby mezi Službou a Konfiguračními položkami a mezi Konfiguračními položkami navzájem v podobě grafu |
KB09 | Propagace atributů | Systém na základě vazeb mezi Službou a Konfiguračními položkami a mezi Konfiguračními položkami navzájem podle stanovených pravidel přenáší hodnoty atributů ze Služby na Konfigurační položky a mezi Konfiguračními položkami navzájem |
KB10 | Evidence bez vazby na účetnictví | Systém musí umožňovat evidenci Konfigurační položky bez ohledu na její stav/existenci v účetnictví (systému Orashei). KP (aktiva) mohou evidovány ještě před přiřazením inventárního čísla, při zápůjčkách apod. |
KB11 | Okamžitá evidence | Evidence zobrazuje co nejlépe skutečný stav. V systému jsou změny Konfiguračních položek, jejich atributů a vazeb evidovány ihned po provedení ve skutečnosti - bez ohledu na to, že odpovídající rozsáhlá Změna s několika kroky ještě není celá provedena, otestována, schválena apod. (Úpravy evidence KP nejsou podmíněny pokrokem ve workflow Změny.) |
KB12 | Evidence bezpečnostní ch událostí | Systém umožní evidovat bezpečnostní události jako jeden druh servisních požadavků |
KB13 | Reporting bezpečnostní ch událostí | Systém poskytne výpis počtu bezpečnostních událostí, jejich stavu, počtu po jednotlivých měsících |
KB14 | Evidence bezpečnostní ch incidentů | Systém umožní evidovat bezpečnostní incidenty ve třech úrovních (I., II., III.) buď jako druh Incidentů nebo jako zvláštní entitu. |
KB15 | Reporting bezpečnostní ch incidentů | Systém poskytne výpis počtu bezpečnostních incidentů, jejich stavu, počtu po jednotlivých měsících s rozlišením úrovní. |
Kybernetická bezpečnost - nefunkční požadavky
ID | Název | Popis požadavku |
BEZ01 | Autentizace | Před přístupem k datům a funkcím informačních systémů mimo těch, které jsou veřejné, je uživatel autentizován a je ověřen rozsah jeho oprávnění. |
BEZ02 | SSO | Systém umožňuje autentizaci přes SSO. |
BEZ03 | Role | Přístup je řízen na základě rolí (tj. ne individuálním přiřazováním dílčích práv jednotlivým uživatelům). Tyto role jsou přiřazovány skupinám a jednotlivým uživatelským účtům přejímaných z ŘDB/MS Active Directory. |
BEZ04 | Jednoznačný identifikátor | Každý uživatel a administrátor má jedinečný identifikátor (vazba na SSO). |
BEZ05 | Omezení přístupu | Je zakázáno používání přímého přístupu do databáze (SQL*Plus, SQL Developer atd.) a programových prostředků, které mohou být schopné překonat systémové nebo aplikační kontroly. |
BEZ06 | Kryptografie | kryptografickych-prostredku/) |
BEZ07 | Zranitelnosti | Systém neobsahuje bezpečnostní zranitelnosti dle seznamu OWASP Top 10 a CWE/SANS top 25 (aktuální verze v době implementace IS). |
BEZ08 | Oddělení prostředí | Provozní prostředí musí být logicky nebo fyzicky odděleno od vývojového a testovacího prostředí. Přenos změn (kódu) mezi prostředími je řízen. Přístupová práva k datům, funkcím i správě systému jsou ve vývojovém prostředí spravována samostatně. |
BEZ09 | Záložní lokalita | Systém je schopen provozu ve dvou lokalitách v takovém režimu, že při zničení provozní lokality je možné obnovit provoz v záložní lokalitě do RTO se ztrátou dat maximálně za RPO. |
BEZ10 | Zálohování | Systém je schopen napojení na centrální zálohování, které bude probíhat minimálně jednou za 24 hodin. |
BEZ11 | Zpracování informací mimo ČNB | Systém nesmí zpracovávat produkční a testovací data (informace) mimo systémové prostředí objednatele (ČNB) (viz příloha č. 2 smlouvy). |
Integrace jsou prováděny na základě tabulek nebo view poskytovaných zdrojovým systémem. Pomocí skriptů jsou data zpracovávána a ukládána do tabulek na straně SD, kde integračním modulem SD jsou na pravidelné denní bázi načítány do databáze SD. Obdobně tento mechanismus probíhá u všech zdrojových systémů: ORAHEI, RDB, Planis, SNC, ABO. U majetku KPIT na základě i.č. se provádí update hodnot v SD.
Nastavení stavu KPIT s IP adresou se provádí na základě hodnot v ORASHEI a RDB.
Nastavení stavu KPIT bez IP adresy se provádí na základě hodnot v ORASHEI.
ID | Název | Popis požadavku |
ITG01 | ORASHEI > Nový SD | Přenášené hodnoty ORASHEI > Nový SD |
Kategorie Pořízeno/zařazeno do Orashei Název Vlastník Inventární číslo Faktura č. Dodavatel Místnost Indikace stavu Sériové číslo Smlouvy o údržbě |
ID | Název | Popis požadavku |
ITG02 | RDB > Nový SD | Přenos RDB > Nový SD Bude existovat view z RDB na základě kterého se integrují sloupce: |
Hostname IP Časová značka Doména Pracovníci Os.číslo Titul. Jméno Příjmení Titul za Evidenční stav Kmenový útvar Nadřízený Místnost Pev. telefon Mob. Telefon Email Komentář Poučení o VPN IT bezpečnostní školení Platí od Platí do Členem skupiny KP Požadavky Historie | ||
Skupiny Kod Název Typ Email Administrátor Komentář Platí od Platí do Historie | ||
Útvary Lokality | ||
ITG03 | Planis > Servicedesk | IS Planis je interní systém sloužící k evidenci projektů a podnětů. Nový SD bude z PLANIS přebírat číselník Podnětů, Projektů a Pracovních úkolů. Všechny tři číselníky obsahují následující datové prvky: • Hlavní klíč (technický hlavní klíč) • Identifikátor (interní ID, může se měnit) • Název (název, může se měnit) • Činnost SNC/dílčí činnost (identifikátor SNC činnosti, může se měnit) Preferované řešení je databázové view v Planis, ze kterého bude SD čerpat data. Přenos bude jednosměrný z Planis do nového SD. |
ID | Název | Popis požadavku |
ITG04 | Servicedesk - SNC | Vzhledem k tomu, že aplikace Servicedesk slouží jako evidence různých druhů aktiv, bude sloužit jako zdroj informací pro klíče a další podklady při sledování nákladovosti činností. SNC je modul informačního systému Orashei, který slouží mimo jiné i k evidenci odvedeného času zaměstnanců. Přenos Nový SD > SNC bude formou souboru/naplnění DB tabulky vybraných druhů požadavků ve struktuře: • ID požadavku (jedinečný identifikátor) • Název požadavku • Typ požadavku • Nákladové středisko, které požadovalo zajištění služby (ve formátu složeného čísla útvaru používaného v ČNB -(např. "0700 0223 03") • SNC činnost/dílčí činnost, pro kterou se příslušný požadavek realizuje • Osobní číslo řešitele (Uxxxxx) • Datum a čas zahájení řešení úkolu, • Datum a čas ukončení řešení úkolu • Stav úkolu Přenos SNC > Nový SD • číselník SNC činnosti (hlavní/dílčí) – číselník je dvoustupňový (u IS) • čas spotřebovaný na řešení požadavku ve struktuře: o ID úkolu, o Osobní číslo, o Celkový počet hodin vykázaných na úkol, o Datum a čas Perioda přenosu dat - v obou směrech ideálně po každé změně. Maximální interval 1x denně. Pravidla pro změny úkolů jsou následující: • Datum a čas zahájení řešení úkolu nesmí být měněn, pokud je datum zahájení řešení úkolu menší nebo roven aktuálnímu datu. • Datum a čas ukončení řešení úkolu nesmí být měněno, pokud je datum ukončení menší než aktuální datum. |
ITG05 | ABO > Servicedesk | Do SD se bude přenášet číselník klientů ABO pro přesnou identifikaci volajícího v případě problémů s ABO. Jedná se o číselník cca 989 klientů. |
ITG06 | ServiceDesk > IBIS | Předávání informací o odstávkách, haváriích apod. do aktualit na intranet. |
Specifické nefunkční požadavky.
ID | Název | Popis požadavku |
SNP01 | Výkon/reakce systému | Je chápán jako požadavek na aplikaci. Aplikace musí obsloužit požadovaný počet uživatelů tak, aby po návrhu a uvedení do provozu nedošlo ke zpomalení systému nebo nutnosti jeho rozšiřování. Aplikace musí zpracovat požadavek od 170 souběžně pracujících uživatelů v těchto parametrech: Otevření formuláře pro zadání požadavku do 1s. Interakce se systémem do 1s (Otevření formuláře, uložení formuláře, výběry z číselníků na formuláři). Vyhledání konkrétního záznamu v CMDB podle názvu, popisu, i.č., kódu do 2s. Vytvoření reportu textový/grafický závislostí CMDB do hloubky 5, 350 prvků nesmí trvat déle než 15s. Hodnoty z číselníků (např. číselník osob, projektů, útvarů apod) se zobrazí ve formulářích (např. požadavek, změna apod) do 1s. |
SNP02 | Škálovatelnos t | Je chápána jako schopnost podpořit kvalitu služeb tím, že zvýšíme kapacity systému bez toho, aby došlo ke změnám v software. Systém musí umět navyšovat kapacitu podle toho, jaké jsou na něj kladeny nároky a neustále drží požadovaný výkon. Aplikace musí podporovat vertikální škálovatelnost, tzn. přidání procesoru, paměti bude mít vliv na výkon aplikace. Dodavatel prokáže, že navýšením zdrojů CPU a RAM o 100% se výkon systému povýší alespoň o 20%. |
SNP03 | Udržitelnost | Požadavek na udržitelnost je schopnost opravení nedostatků systému bez toho, aby se ovlivnila některá další část. Opravou jedné komponenty nesmí vzniknout chyba na komponentě jiné. Dodavatel musí prokázat, že systém byl v minulosti pravidelně udržován a disponuje rozhraním a postupem, jak takové operace provádět. |
SNP04 | Spolehlivost | Při zvýšené zátěži musí aplikace pokračovat ve zpracování žádostí od uživatele a zpracovávat transakce tak, jak by je aplikace zpracovávala v době, kdy je náročnost menší. Spolehlivost aplikace bude posuzována podle toho, že bude bezchybně vykovávat funkční požadavky a bude dostupná. Spolehlivá aplikace bude prohlášena po úspěšném splnění akceptačních testů. |
SNP05 | Dostupnost | Dostupností se rozumí, že v každém momentu jsou přístupné všechny služby nebo zdroje daného systému. Je požadována 99,45% (cca 55 minut týdně) dostupnost. |
SNP06 | Modifikovatel nost / rozšiřitelnost | Rozšiřitelnost je schopnost zavést novou funkcionalitu Systém musí nabízet rozšiřitelnost pomocí rozhraní (API rozhraní, které umožní programově aplikaci ovládat nezávisle na výrobci aplikace svépomocí). Pověřený znalý zaměstnanec ČNB prokáže, že pomocí dokumentace a dodaného REST API lze aplikaci ovládat nezávisle na výrobci. Provede CRUD operace nad požadavkem, konfigurační položkou, osobou. Modifikovatelností se myslí možnost konfigurace/nastavení prostředí, procesů, tak aby byly splněny funkční požadavky a bylo možné reagovat na změny procesů bez nutnosti systém doprogramovat. |
SNP07 | Relační databáze | Data ServiceDesk jsou uložena v relační databázi |
SNP08 | HA | Systém umožňuje rozšíření pro zajištění nepřerušovaného provozu (High Availabilty) z více lokalit. |
ID | Název | Popis požadavku |
OBN01 | RTO (Recovery Time Objective) | Řešení je možné obnovit ze zálohy do původního stavu (ne staršího než záloha z předešlého dne) v době kratší než 3 dny. Test obnovy systémů musí být součástí akceptačních testů. |
OBN02 | RPO (Recovery Point Objective) | Okamžik před havárií, ke kterému budou dostupná data za nejdéle 24 hodin. |
OBN03 | Obnovitelnost | Systém bude používat pro zálohování centrální zálohovací systém ČNB a systém musí být možno ze zálohy obnovit pro všechna prostředí. |
OBN04 | Podklady pro postup obnovy | Součástí dodané dokumentace musí být podklady pro vytvoření postupu obnovy systému po zničení produkčního prostředí - postup konfigurace komponent, jejich vazby apod. |
Příloha č. 2A
Popis prostředí objednatele a varianty implementace
1.3 Prostředí klientské stanice 58
2 VARIANTY IMPLEMENTACE IS SD DO INFRASTRUKTURY OBJEDNATELE 58
1 Systémové prostředí objednatele (ČNB)
IS SD musí akceptovat standardní systémové prostředí objednatele (ČNB) a musí být snadno do tohoto prostředí implementovatelný.
Standardní systémové prostředí objednatele (ČNB) je soubor konkrétních produktů technického a programového vybavení včetně pravidel pro jejich provoz a dále seznam definovaných služeb, které souhrnně tvoří základní platformu pro provoz informačních systémů a informačních technologií (IS/IT) v prostředí České národní banky (ČNB). Toto prostředí se průběžně aktualizuje dle standardů ČNB.
• Klientské stanice připojeny rychlostí typicky 1 Gbsec-1 1000Base-T
• Servery připojeny typicky rychlostí 10 Gbsec-1 či v záloze 1Gbsec-1 1000Base-T
• Mezi servery a klientskými stanicemi pouze L3 konektivita, mezi servery možná L2 nebo
L3 konektivita
• Adresace dle RFC 1918 (10.x.y.z)
• Plně přepínaná síť s redundantním jádrem
• Platforma architektury x86/x64 - MS Windows Server 2016 Server Standard Edition
• Oracle Enterprise Linux 7.0 a vyšší či Platforma Red Hat Linux v. 7.x či vyšší
Virtualizační platforma
• Platforma VMware vSphere 7.x
• Platforma Oracle Linux VM 4.x
Centrální diskové kapacity
Slouží pro ukládání dat spravovaných databázovými systémy, pro sdílení programového vybavení a dat organizačních útvarů ČNB, poskytují prostor pro uložení dat jednotlivých uživatelů. Jsou využita fault tolerantní disková pole instalované v geograficky vzdálených lokalitách.
Elektronická pošta
• Server elektronické pošty - MS Exchange 2016
• Klient elektronické pošty – MS Outlook 2016 nebo OWA
Tisková zařízení
• Síťová tisková zařízení,
• Komunikační protokol – TCP/IP,
• Podporované síťové služby – SNMP, DHCP, DNS.
Databázové servery
Data standardních IS jsou uložena v databázích Oracle:
• Oracle RDBMS 19 a vyšší - long time verze
• Protokol Oracle Net
Zálohování dat provozních databází je zajištěno stanovenými prostředky a postupy.
Single Sign-On
• využitím služby MS AD (autentizační protokol Kerberos).
1.3 Prostředí klientské stanice
Klientská stanice uživatele je osobní počítač IBM-PC kompatibilní koncipovaný jako nástroj zajišťující přístup uživatele k centrálně provozovaným IS nebo virtualizovaný desktop (dále jen vDesktop) pomocí technologie Citrix. Minimální parametry klientské stanice provozované ve standardním systémovém prostředí objednatele (ČNB):
• MS Windows 10 Enterprise edice LTSC
• Citrix XenApp 2203 LTSR CUx na MS Windows 2016 Serveru (virtuální desktop využívající MS terminálové služby)
• TCP/IP síťové služby (DHCP klient, SNMP klient)
• MS Office 2016 Professional Plus
• WWW prohlížeče – Google Chrome, MS Edge (Chromium)
• Adobe Acrobat Reader DC CZ – prohlížeč souborů ve formátu PDF
Není přípustné ukládat na klientskou stanici/vDesktop data trvalé hodnoty, taková data je nutno ukládat na centrální diskové kapacity. Na klientské stanici nesmí být prováděno dávkové zpracování dat IS.
Dávkové zpracování centrálně uložených dat je přípustné spouštět a provádět pouze
na databázovém serveru nebo případně na aplikačním serveru.
Při realizaci informačního systému je nutné zajistit, aby programové komponenty realizovaného IS nebyly v rozporu s komponentami dalších provozovaných IS. Realizovaný IS tedy musí být provozovatelný v systémovém prostředí objednatele (ČNB) a současně nesmí narušovat funkčnost ostatních IS.
Varianty implementace IS SD do infrastruktury objednatele
Při realizaci IS SD je nutné zajistit, aby programové komponenty realizovaného IS nebyly v rozporu s komponentami dalších provozovaných IS. Realizovaný IS tedy musí být provozovatelný v systémovém prostředí objednatele (ČNB) a současně nesmí narušovat funkčnost ostatních IS.
IS SD musí být realizován jako webová aplikace přístupná z prohlížečů Edge a Chrome ve výrobcem podporovaných verzích, která nebude vyžadovat instalaci doplňkových komponent na straně klienta (např. Silverlight, Java, Flash apod.)
Varianta 1
Poskytovatel plně akceptuje systémové prostředí objednatele (ČNB) tak, jak je specifikováno
v kapitole 1.
Pro každé z prostředí IS SD (viz kapitola 6) bude vyhrazen jeden virtuální server 1-4vCPU max 32GB RAM s adekvátním diskovým úložištěm. Poskytovateli nebudou poskytnuty
administrátorské účty operačního systému (admin/root).
Pro ukládání dat bude použito samostatné schéma v databázi na Oracle RDBMS serveru verze 19 EE. Tyto databáze budou umístěny na konsolidovaném databázovém subsystému Oracle
EXADATA. Databáze budou limitovány via. CPU Caging (maximální počet využitých CPU) na 8 CPU, respektive 4 CPU pro testovací a vývojové prostředí.
Objednatel zajišťuje:
• virtuální servery
• licence a instalace operačních systémů a virtualizačních platforem uvedených v kapitole 1
a jejich správu
• licence, přístupy do prostředí databáze Oracle a správu databáze (včetně instalace bezpečnostních záplat a upgrade na podporované verze)
• pravidelné zálohování virtuálních serverů formou zálohy virtuálního stroje, včetně případné obnovy ze záloh
• pravidelné zálohování databáze, včetně případné obnovy ze záloh Poskytovatel zajišťuje:
• licence a instalace komponent IS SD do systémového prostředí objednatele (ČNB)
• nastavení vlastního IS SD a jeho komponent pro optimální provoz IS SD
• podporu běžného provozu
• průběžnou optimalizaci kódu tak, aby při nárůstu objemu dat nedocházelo k významnému zpomalování SW vybavení
To vše v rozsahu a časových intencích dle smlouvy, zejména jejích čl. VI, VII a X.
Varianta 2
Poskytovatel akceptuje systémové prostředí objednatele (ČNB) s výjimkou databázové platformy, kterou dodá v rámci IS SD.
Pro každé z prostředí (viz kapitola 6) bude vyhrazen jeden virtuální server 1-4vCPU max 32GB RAM s adekvátním diskovým úložištěm. Pro databázi může být vyhrazen navíc jeden virtuální server 1-4vCPU max 32GB RAM s adekvátním diskovým úložištěm pro každé prostředí. Poskytovateli nebudou poskytnuty administrátorské účty operačního systému (admin/root).
Objednatel zajišťuje:
• virtuální servery
• licence a instalace operačních systémů a virtualizačních platforem uvedených v kapitole 1
a jejich správu
• pravidelné zálohování virtuálních serverů formou zálohy virtuálního stroje, včetně případné obnovy ze záloh
Poskytovatel zajišťuje:
• licence, instalaci a nastavení přístupů k databázi
• licence a instalace komponent IS SD do prostředí
• nastavení prostředí pro optimální provoz IS SD
• správu databáze (včetně instalace bezpečnostních záplat a upgrade na podporované verze)
• pravidelné zálohování databáze, včetně případné obnovy ze záloh
• podporu běžného provozu
• průběžnou optimalizaci kódu tak, aby při nárůstu objemu dat nedocházelo k významnému zpomalování SW vybavení
To vše v rozsahu a časových intencích dle smlouvy, zejména jejích čl. VI, VII a X.
Příloha č. 3
Ujednání o zpracování osobních údajů (vzor)
(dále také jen „Ujednání“)
Smluvní strany smlouvy podle odstavce 1.1 se dohodly na tomto Ujednání, které naplňuje požadavky stanovené pro smlouvu o zpracování osobních údajů podle ustanovení čl. 28 odst. 3 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“).
1. Úvodní ustanovení
1.1. Česká národní banka (dále též „správce“) v souladu se smlouvou o vytvoření a dalším rozvoji informačního systému pro správu zkouškových sad – IS SD a poskytnutí příslušné licence, evidenční číslo smlouvy ČNB: 92-131-21 (dále jen „smlouva“) určuje účel a prostředky zpracování osobních údajů zaměstnanců objednatele (dále jen „interní uživatelé“) a uživatelů informačního systému pro správu zkouškových sad (dále jen „externí osoby“) (společně dále jen „subjekty údajů“) a je tedy v postavení správce osobních údajů ve smyslu čl. 4 odst. 7 GDPR.
1.2. …… (dále též „zpracovatel“) bude na základě smlouvy zpracovávat osobní údaje subjektů údajů a bude ve vztahu ke správci v postavení zpracovatele osobních údajů ve smyslu čl. 4 odst. 8 GDPR.
2. Předmět Ujednání
Toto Ujednání upravuje vztahy mezi správcem a zpracovatelem a určuje jejich práva a povinnosti při zpracování osobních údajů zpracovatelem a v souvislosti s ním, zejména pak vymezuje rozsah osobních údajů, které bude zpracovatel zpracovávat, prostředky a účel, pro který bude osobní údaje zpracovávat, dobu zpracování osobních údajů, jakož i podmínky a záruky zpracovatele z hlediska technického a organizačního zabezpečení ochrany osobních údajů tak, aby zpracování probíhalo v souladu s právními předpisy v oblasti ochrany osobních údajů.
3. Účel zpracování a rozsah zpracovávaných osobních údajů
3.1. Zpracovatel bude zpracovávat osobní údaje subjektů údajů pouze v rozsahu nezbytném pro zajištění realizace smlouvy. Za osobní údaje jsou podle tohoto Ujednání považovány informace uvedené ve výčtu v odstavci 3.2 tohoto Ujednání („osobní údaje“).
3.2. Zpracovatel bude zpracovávat osobní údaje předané ze strany správce pro účely zajištění vývoje, provozní podpory a budoucího rozvoje informačního systému pro správu zkouškových sad (dále též „IS SD“), pouze v následujícím rozsahu, nezbytném pro výkon práv a povinností podle smlouvy:
a) jméno a příjmení subjektů údajů;
b) osobní číslo interních uživatelů;
c) uživatelské jméno subjektů údajů;
d) e-mailovou adresu subjektů údajů (pracovní e-mailovou adresu, v případě uvedení
ze strany externích uživatelů i soukromou e-mailovou adresu);
e) telefonní číslo subjektů údajů (pracovní telefonní číslo, v případě uvedení ze strany externích uživatelů i soukromé telefonní číslo);
f) adresu externího uživatele (adresa právnické nebo fyzické osoby, k níž se externí uživatel váže);
g) (případně se doplní další položky zpravidla zpracovávané)
3.3. Zpracovatel bude osobní údaje zpracovávat následujícími způsoby ve smyslu čl. 4 odst. 2 GDPR: sběrem od správce, shromážděním, zaznamenáním, uspořádáním, strukturováním, uložením, přizpůsobením, nahlédnutím, a také jejich anonymizací a výmazem nebo jiným způsobem v souvislosti s účelem zpracování osobních údajů podle odstavce 3.2 tohoto Ujednání.
3.4. Zpracovatel je ve všech případech při zpracování osobních údajů vázán prokazatelnými pokyny správce. Zpracovatel nesmí bez předchozího prokazatelného výslovného souhlasu anebo pokynu správce zpracovávané osobní údaje upravit nebo pozměnit, třídit nebo kombinovat, zpřístupnit ani předat třetí osobě, šířit ani zveřejňovat, ani jakýmkoli způsobem použít pro vlastní potřebu.
4. Doba zpracování
4.1. Zpracovatel bude osobní údaje zpracovávat po dobu nezbytnou pro účel zajištění realizace
smlouvy.
4.2. Po uplynutí doby zpracování podle odstavce 4.1 tohoto Ujednání bude zpracovatel osobní údaje zpracovávat v souladu s čl. 6 odst. 1 písm. c) a f) GDPR pouze v nezbytném rozsahu a výhradně za účelem plnění právními předpisy uložených povinností a ochrany práv a právem chráněných zájmů správce, zpracovatele, příjemce nebo jiné dotčené osoby, a to nejdéle po dobu vyplývající z příslušných zvláštních právních předpisů.
5. Práva a povinnosti smluvních stran
5.1. Správce pověřuje zpracovatele zpracováním osobních údajů výhradně za účelem podle odstavce 3.2 tohoto Ujednání.
5.2. Osobní údaje nebudou zpracovatelem zpracovávány ani s nimi nebude nakládáno jinak, než pouze za účelem, pro který byly osobní údaje zpracovateli poskytnuty, a vždy v souladu s pokyny správce; to platí i pro zpřístupnění či poskytnutí osobních údajů třetí osobě nebo předání mimo území EU.
5.3. Zpracovatel je povinen při každém případném využití cloudové služby předem informovat správce o tom, ve kterých zemích budou zpracovávané osobní údaje umístěny, a to i v případě jakékoli změny. Zařízení, na nichž budou osobní údaje uchovávány nebo jinak zpracovávány, se budou nacházet výlučně v zemích EU a osobní údaje budou předávány a uchovávány pouze v těchto zemích. Zpracovatel je zároveň povinen zajistit zpracování osobních údajů správce odděleně od případných osobních údajů jiných klientů zpracovatele.
5.4. Zpracovatel je povinen zabezpečit osobní údaje a zachovávat mlčenlivost o osobních údajích a řídit se pokyny správce ve všech případech, kdy se jedná o zpracování či zabezpečení osobních údajů. Zpracovatel přijme technická, organizační a personální opatření adekvátní způsobu zpracování a v souladu s pokyny správce – přičemž toto zabezpečení bude odpovídat příslušným aktuálním používaným bezpečnostním standardům (podrobněji v odstavci 5.5 a násl. tohoto Ujednání).
5.5. Správce stanoví opatření, která považuje za dostatečná pro technické a organizační zabezpečení osobních údajů následovně:
a) Technické zabezpečení osobních údajů bude zajištěno pomocí prostředků:
(i) počítačové bezpečnosti; zpracovatel se zavazuje ke zpracování používat výhradně takové technické a programové prostředky, jejichž používání při vyloučení nepředvídatelných okolností eliminuje možnost narušení, ztráty, zničení či poškození osobních údajů, neoprávněného přístupu k nim, či neoprávněného nakládání s osobními údaji;
(ii) komunikační bezpečnosti; zpracovatel se zavazuje dodržovat taková opatření k zabezpečení ochrany osobních údajů při jejich přenosu telekomunikačními kanály (včetně datových nosičů), jejichž povaha eliminuje při vyloučení nepředvídatelných okolností možnost narušení (šifrování);
(iii) fyzické bezpečnosti; v tomto ohledu zpracovatel prohlašuje, že místo, ve kterém budou osobní údaje zpracovávány a ve kterém budou uchovávány spisy a dokumenty, bude mít charakter prostoru zabezpečeného před možností narušení bezpečnosti;
(iv) (nehodící se vypustí/případně se doplní další položky – jedná se o demonstrativní výčet, opatření však musí být dostatečná pro dodržení platných právních předpisů).
Zpracovatel bude plnit všechny povinnosti stanovené v tomto ustanovení písm. a) využíváním prostředků odpovídajících dosaženému stupni technického pokroku a nárokům odborné péče.
b) Organizační zabezpečení:
(i) osobní údaje budou zpřístupněny pouze určeným osobám z oprávněného personálu zpracovatele a případně oprávněným osobám, které odpovídají za zajištění bezpečnosti systému, kde jsou osobní údaje uloženy, a to na základě zvláštních uživatelských oprávnění zřízených výlučně pro tyto osoby;
(ii) zpracovatel je povinen zabezpečit poučení osob, které mají v rámci zpracování osobních údajů přístup k těmto údajům, aby všechny tyto osoby byly řádně poučeny o svých povinnostech při zpracovávání osobních údajů, zejména pak o povinnosti mlčenlivosti ve vztahu k těmto osobním údajům;
(iii) (nehodící se vypustí/případně se doplní další položky – jedná se o demonstrativní výčet, opatření však musí být dostatečná pro dodržení platných právních předpisů).
c) Dále je zpracovatel povinen:
(i) zabránit neoprávněným osobám v přístupu k osobním údajům a k prostředkům pro jejich zpracování, a také zabránit neoprávněnému čtení, vytváření, kopírování, přenosu, úpravě či vymazání záznamů obsahujících osobní údaje.
(ii) (případně se doplní další položky v závislosti na doplnění sub písm. a) a b)).
5.6. Zpracovatel je povinen zpracovat a dokumentovat přijatá a provedená technická a organizační opatření k zajištění ochrany osobních údajů v souladu s právními předpisy, zejména s GDPR a dalšími předpisy v oblasti ochrany osobních údajů, jakož i provádět nejméně jednou ročně hodnocení efektivnosti přijatých opatření, a to včetně vedení a zpřístupnění následující dokumentace:
a) seznamu osob, které jsou oprávněny přistupovat k osobním údajům (včetně rozsahu oprávnění);
b) elektronického přehledu informací o veškerých přístupech jednotlivých osob
k osobním údajům.
5.7. Zpracovatel bude neprodleně písemně informovat správce v případě jakýchkoliv potíží při plnění povinností vyplývajících z tohoto Ujednání, jakož i o všech okolnostech týkajících se porušení povinností při zpracování a ochraně osobních údajů, zejména o případech, kdy dojde k náhodnému nebo protiprávnímu zničení, ztrátě či změně zpracovávaných osobních údajů nebo neoprávněnému poskytnutí nebo zpřístupnění zpracovávaných osobních údajů. V takovém případě zpracovatel přijme v nejkratším možném termínu veškerá nezbytná opatření k zajištění dostatečné ochrany osobních údajů, notifikuje správce o těchto skutečnostech prostřednictvím kontaktních osob uvedených ve smlouvě a následně postupuje v souladu s GDPR a pokyny správce, budou-li mu sděleny.
5.8. V případě, že v souvislosti se zpracováním osobních údajů zpracovatelem bude zahájeno řízení ze strany orgánu veřejné správy, zpracovatel poskytne správci v těchto řízeních veškerou potřebnou součinnost.
5.9. Zpracovatel je správci na jeho žádost nápomocen při posuzování vlivu zpracovávání osobních údajů na ochranu osobních údajů a při konzultacích správce s dozorovým orgánem, při zohlednění povahy zpracovávání a informací, jež má zpracovatel k dispozici.
5.10. Zpracovatel nezapojí do zpracovávání osobních údajů dalšího zpracovatele bez předchozího písemného povolení správce. V případě, že jakákoliv část zpracovávání osobních údajů bude vykonávaná dalším zpracovatelem po předchozím písemném povolení správce, zůstává zpracovatel plně odpovědný vůči správci za zpracovávání osobních údajů.
5.11. Správce je oprávněn kontrolovat dodržování pravidel stanovených pro zpracování v GDPR či v tomto Ujednání u zpracovatele, resp. i na jiném místě, kde dochází ke zpracování osobních údajů. Zpracovatel za tímto účelem zajistí zástupcům správce, kteří budou provedením kontroly pověřeni, přístup ke všem relevantním informacím a na všechna příslušná místa tak, aby mohlo být řádně provedeno hodnocení oprávněnosti zpracování. Zpracovatel poskytne správci na jeho vyžádání veškeré podklady o přijatých a provedených technických a organizačních opatřeních k zajištění ochrany osobních údajů.
5.12. Po ukončení poskytování služeb podle smlouvy zpracovatel neprodleně vrátí veškeré osobní údaje správci, s výjimkou údajů, které je zpracovatel povinen uchovávat na základě platných právních předpisů.
6. Odpovědnost za újmu a smluvní pokuty
6.1. Článek 6 upravuje odpovědnost za újmu a nárok na smluvní pokuty v případě porušení podmínek tohoto Ujednání. Znění tohoto článku 6 se nevztahuje na smluvní pokuty a úroky z prodlení podle článku VIII smlouvy, ve znění pozdějších dodatků, jehož platnost a účinnost zůstává v plném rozsahu zachována.
6.2. Zpracovatel se zavazuje nahradit správci jakoukoliv újmu, včetně nemajetkové, která vznikne z důvodu porušení tohoto Ujednání ze strany zpracovatele. V tomto závazku zpracovatele je zahrnuta i povinnost odškodnit správce za (i) jakékoliv nároky, a to zejména zadostiučinění, peněžité náhrady nebo pokuty, úspěšně uplatněné v soudním popř. správním řízení, ze strany třetích osob, (ii) za správní pokuty uložené správci pravomocně dozorovým orgánem, nebo (iii) jakoukoli újmu utrpěnou poškozením dobré pověsti v příčinné souvislosti s porušením povinností stanovených právními předpisy nebo tímto Ujednáním ze strany zpracovatele.
6.3. Pokud dojde k porušení GDPR nebo jiných právních předpisů v oblasti ochrany osobních údajů pouze v důsledku jednání té smluvní strany, které je v souvislsoti s tímto porušením uložena správní pokuta, hradí náklady na uhrazení správní pokuty plně ta strana, která GDPR nebo jiný právní předpis v oblasti ochrany osobních údajů prokazatelně porušila a jíž současně byla uložena pokuta.
6.4. V případě, že zpracovatel správci neumožní kontrolu ohlášenou v souladu s odstavcem 5.11 tohoto Ujednání, anebo během kontroly správci neposkytne pro předmět kontroly potřebnou součinnost, je správce oprávněn po zpracovateli požadovat smluvní pokutu ve výši 5 000,- Kč za každý započatý pracovní den takto trvajícího prodlení na straně zpracovatele.
6.5. Zpracovatel je povinen odstranit kontrolou zjištěné nedostatky ve lhůtě 5 pracovních dnů, není-li mezi zpracovatelem a správcem dohodnuto jinak. V případě, že zpracovatel neodstraní kontrolou zjištěné nedostatky, je správce oprávněn po zpracovateli požadovat smluvní pokutu ve výši 5 000,- Kč za každý započatý den prodlení na straně zpracovatele.
6.6. V případě, že zpracovatel poruší kteroukoli z povinností sjednaných v čl. 5 (vyjma odstavce 5.11) tohoto Ujednání, je správce oprávněn po zpracovateli požadovat smluvní pokutu ve výši 50 000,- Kč za každý jednotlivý případ takového porušení.
6.7. Ujednáním o smluvní pokutě podle tohoto článku není dotčeno právo správce na náhradu škody vzniklé z porušení povinnosti.
6.8. Zpracovatel prohlašuje, že má platně uzavřeno pojištění v dostatečném rozsahu pro případ škody vzniklé porušením jeho povinností z tohoto Ujednání, a bude jej udržovat po celou dobu trvání závazků z tohoto Ujednání.
7. Trvání závazků
7.1. Závazek ke zpracování osobních údajů se sjednává pouze na dobu existence závazkového vztahu vzniklého ze smlouvy, nejpozději do dne likvidace posledního zpracovávaného osobního údaje zpracovatelem ve smyslu povinnosti zlikvidovat osobní údaje podle příslušných ustanovení GDPR.
7.2. V případě ukončení smlouvy předá zpracovatel veškeré osobní údaje správci na dohodnutém datovém nosiči a následně neprodleně zlikviduje veškeré záznamy (s výjimkou upravenou v odstavci 4.2 tohoto Ujednání) v jím spravovaných datových úložištích a na datových nosičích, včetně provozně-bezpečnostních záloh zpracovatele i datových záloh uložených u jeho případného podposkytovatele.
8. Další ujednání
8.1. Smluvní strany se zavazují vstoupit v jednání o doplnění tohoto Ujednání, pokud vyjde najevo potřeba takového doplnění zejména s ohledem na nově přijaté právní předpisy, stanoviska dozorových orgánů, nebo rozhodování soudních či správních orgánů, a poskytnout si veškerou potřebnou součinnost ke sjednání dodatku smlouvy, pokud bude pro potřeby plnění požadavků obecného nařízení či jiných právních předpisů potřebný.
8.2. Za písemnou formu se pro účely tohoto Ujednání nepovažuje e-mailová ani jiná elektronická forma. Výjimkou je situace, v níž zpracovatel informuje správce ve smyslu odstavce 5.7 (potíže při plnění povinností vyplývajících z tohoto Ujednání a okolnosti týkající se porušení povinností při zpracování a ochraně osobních údajů), a také oznámení kontroly ve smyslu odstavce 5.11, které lze provést i elektronickým oznámením prokazatelně doručeným druhé smluvní straně. V případě oznámení kontroly postačuje prokazatelné odeslání oznámení správcem na e-mailovou adresu …… určenou pro tento účel zpracovatelem.
Příloha č. 4
Projekt 7035/2021
„Obnova IS ServiceDesk“
Realizační studie
Verze | |
Datum verze | |
Autor | |
Vedoucí projektu poskytovatele | |
Vedoucí projektu objednatele |
Tento dokument obsahuje informace důvěrného charakteru a informace v něm obsažené jsou vlastnictvím České národní banky. Žádná část dokumentu nesmí být kopírována, uchovávána v dokumentovém systému nebo přenášena jakýmkoliv způsobem včetně elektronického, mechanického, fotografického či jiného záznamu a uveřejněna či poskytnuta třetí straně bez předchozí dohody a písemného souhlasu vlastníků.
Některé názvy použité v tomto dokumentu mohou být registrovanými ochrannými známkami nebo obchodními značkami, které jsou majetkem svých vlastníků.
Historie změn
Verze Datum Autor Popis změny
Obsah
1.3 Přehled použitých symbolů 72
1.4 Legislativa, technické normy a standardy 72
2.3 Analýza funkčních požadavků 74
2.4 NÁVRH KOMPONENT UŽIVATELSKÉHO ROZHRANÍ (OBRAZOVKY) 74
3 TECHNICKÁ REALIZACE ŘEŠENÍ 75
3.3.1 Analýza bezpečnostních požadavků 75
3.3.2 Autentizace a autorizace, řízení přístupu 75
3.3.4 Zabezpečení síťové komunikace a uložených dat 75
3.3.5 Soulad s legislativou (Compliance) 75
3.4 Návrh architektury technického řešení 76
3.4.1 Požadavky na systémové prostředí 76
3.6 ZPŮSOB IMPLEMENTACE DO SYSTÉMOVÉHO PROSTŘEDÍ ČNB 76
4 NÁVRH PROJEKTOVÉ REALIZACE 77
4.1 Detailní harmonogram realizace 77
4.2 Požadavky na součinnost 77
Hlavní kapitoly realizační studie jsou povinné, struktura podkapitol je doporučená, možno ji rozšiřovat či upravovat dle potřeb projektu.
1. Úvod
[Dokument realizační studie popisuje způsob realizace řešení včetně analýzy funkčních požadavků, softwarové architektury a systémových požadavků tak, aby byla prokázána realizovatelnost všech zadaných požadavků.]
[Výčet klíčových zkratek a pojmů s jejich vysvětlením]
Termín/Zkratka | Popis/Význam |
1.3. Přehled použitých symbolů
[Popis použitých grafických symbolů v dokumentu]
Grafický symbol | Význam |
1.4. Legislativa, technické normy a standardy
[Seznam legislativy, standardů a norem používaných při realizaci řešení.]
Č. zákona/ ČSN..... ISO...... | Název/Popis |
2. Realizace věcného zadání
[Kapitola obsahuje analýzu procesů Servicedesku v sekci informatiky a sekci správní. Bude vycházet ze stávajícího katalogu služeb a činností, které jsou poskytovány a potřeb zlepšení procesů.].
[Kapitola obsahuje návrh řešení procesů Servicedesku v sekci informatiky a sekci správní na základě analýzy z kapitoly 2.1 Blíže popíše realizaci pro jednotlivé služby a procesy včetně návrhu šablon a workflow].
2.3. Analýza funkčních požadavků
[Kapitola obsahuje mapování funkčních požadavků na cílové řešení. Popis tak ve stručné formě představuje způsob realizace jednotlivých funkčních požadavků.]
ID5 | Popis požadavku | Název funkcionality | Poznámka |
2.4. Návrh komponent uživatelského rozhraní (obrazovky)
[Kapitola obsahuje mapování grafického uživatelského rozhraní tak, aby šlo ověřit pracovní postup koncových uživatelů v rámci zadaného pracovního procesu resp. postupu a to ve všech uživatelských rozhraní. Především je nutné podrobně představit úvodní stránku a postupy z hlediska běžného uživatele (úvodní strana portálu, rychlý a srozumitelný způsob zadávání požadavků apod.). ].
5 ID požadavku objednatele
3. Technická realizace řešení
[Kapitola obsahuje:
- popis možností integrace řešení s jednotlivými stávajícími a budoucími (projektovanými) IS ČNB
- detailní popis rozhraní pro pravidelné, automatizované předávání a přebírání dat z/do IS ČNB.]
3.1.1. ORASHEI
3.1.2. ŘDB
3.1.3. Planis
3.1.4. SNC
3.1.5. ABO
3.1.6. IBIS
[Kapitola obsahuje analýzu a namapování datových struktur původního a projektovaného IS z hlediska jejich převoditelnosti a datové migrace (tj. jednoznačné srovnání datových objektů, které budou využívány při migraci dat mezi oběma systémy) a popis vlastní migrace. Na analýze se podílejí jak zadavatel, tak poskytovatelé obou systémů.]
[Kapitola obsahuje popis řešení z hlediska bezpečnosti, integrity a důvěrnosti dat.]
3.3.1. Analýza bezpečnostních požadavků
[Podkapitola obsahuje analýzu bezpečnostních požadavků.]
3.3.2. Autentizace a autorizace, řízení přístupu
[V podkapitole je popsán princip řízení přístupů k informacím resp. informačním aktivům: jakým prostřednictvím přistupují interní a externí uživatelé, popis technických (aplikačních) účtů – bez časového omezení; způsob automatického blokování účtů uživatelů při ukončení zaměstnaneckého poměru v ČNB, povolené protokoly apod.]
3.3.3. Logování
[V podkapitole je popsán způsob logování a monitorování logů, napojení na SIEM.]
3.3.4. Zabezpečení síťové komunikace a uložených dat
[V podkapitole je popsán způsob, jak je zabezpečena síťová komunikace mezi servery a klientem a zabezpečení uložených dat – FileSystem/DataBase.]
3.3.5. Soulad s legislativou (Compliance)
[V podkapitole je popsán způsob, jak je zabezpečen soulad s legislativou – např. ZoKB, ISO20022 apod.. V případě, že navrhované řešení nebude splňovat nějaké legislativní požadavky, uvede se to v této kapitole včetně zdůvodnění proč.]
3.4. Návrh architektury technického řešení
[Kapitola popisuje globální architekturu IS a fyzickou architekturu nasazení aplikace v infrastruktuře ČNB s ohledem na provoz, monitoring, zálohování a archivaci.]
3.4.1. Požadavky na systémové prostředí
[Podkapitola obsahuje SW a HW specifikaci pro nasazení v prostředí ČNB. Součástí je i sizing HW prostředků pro účely implementace systému. Různá prostředí produkce/test/vývoj/ jsou popsána zvlášť.]
Tabulka 1: HW specifikace
Prvek | Typ | Výkon | RAM | Disková kapacita | Síťové rozhraní | Poznámka |
APP1 | Virtuální server | 2 – 4 virtuální CPU, 2 – 3 GHz | 4 – 8 GB | 15 GB | 100 Mbps | |
Tabulka 2: SW specifikace
Prvek | OS | Databázové služby | Aplikační služby | Poznámka |
APP1 | Windows Server 2008 R2 ENG x64 | Oracle client 10g | MS IIS 7.5 ASP.NET 3.5 SP1 | |
[Kapitola obsahuje seznam všech poskytovaných licencí a práv užívání.]
3.6. Způsob implementace do systémového prostředí ČNB
[Kapitola obsahuje postup nasazení IS SD do cílového prostředí s ohledem na stanovení příslušné součinnosti ze strany ČNB.]
4.1. Detailní harmonogram realizace
[Harmonogram realizace uvádí rozpad realizace projektu do jednotlivých přírůstků (dílčích plnění), etap, fází a činností s ohledem na dodržení stanovených termínů/lhůt. Harmonogram musí obsahovat milníky pro předání díla nebo jeho částí k akceptačnímu řízení.]
[V kapitole je uveden rozsah kapacit požadovaných poskytovatelem po objednateli]
ID | Popis součinnosti | Rozsah | Čerpání |
Legenda:
ID: jedinečný identifikátor požadované součinnosti
Popis součinnosti: popis aktivit, požadovaných poskytovatelem po objednateli Rozsah: odhadovaný rozsah požadovaných kapacit v čld
Čerpání: četnost, způsob čerpání kapacit např. 1x týdně; 2hod v Pá
[V kapitole je uveden seznam všech připravovaných akceptačních testů, které kompletně ověří požadovanou funkcionalitu systému a zodpovědnost za vypracování testovacích scénářů]
ID testu | Testovaná oblast | Testovací scénář | ID požadavku6) | Testovací scénář vypracovává |
Legenda:
ID scénáře: jedinečný identifikátor testovacího scénáře Testovaná oblast: oblast testování např.: Personalistika, …. Testovací scénář: popis testovacího scénáře
ID požadavku: jedinečné identifikátory požadavků objednatele, které jsou daným testovacím scénářem ověřovány.
Testovací scénář vypracovává: jméno/firma autora testovacího scénáře
[Kapitola detailněji popisuje způsob zajištění školení a proškolení příslušných pracovníků, okruh školených uživatelů a správců, kdo zodpovídá za zpracování školící dokumentace a pokud není uvedeno v harmonogramu, tak i předpokládané termíny školení]
6) Požadavky z předběžné studie (funkční a specifické)
[V kapitole je uveden seznam technické, provozní a uživatelské dokumentace a zodpovědnost za její zpracování/aktualizaci.]
[V kapitole je uveden seznam změn oproti předběžné studii/zadávací dokumentaci, jejich akceptace a
jejich dopady do projektu – časové, zdrojové a finanční.]
Akceptována
ID změny
Popis změny
Ano/Ne
Realizace (termín, zdroje a
finance)
Příloha č. 5
Šablona pro testovací scénáře
IS Servicedesk
Testovací scénáře
Verze | |
Datum poslední modifikace | |
Autor | |
Vedoucí projektu poskytovatele | |
Vedoucí projektu objednatele |
Tento dokument obsahuje informace důvěrného charakteru a informace v něm obsažené jsou vlastnictvím České národní banky. Žádná část dokumentu nesmí být kopírována, uchovávána v dokumentovém systému nebo přenášena jakýmkoliv způsobem včetně elektronického, mechanického, fotografického či jiného záznamu a uveřejněna či poskytnuta třetí straně bez předchozí dohody a písemného souhlasu vlastníků.
Některé názvy použité v tomto dokumentu mohou být registrovanými ochrannými známkami
nebo obchodními značkami, které jsou majetkem svých vlastníků.
Historie změn
Verze Datum Autor Popis změny
6. Příprava a podmínky testů
6.1. Testovací prostředí
Testovacím prostředím je testovací prostředí IS Servicedesk instalované v ČNB dle specifikace uvedené
v akceptované realizační studii.
6.2. Provedení testu a jeho vyhodnocení
Testovací scénáře budou prováděny v pořadí, ve kterém jsou uvedeny v „Seznamu testovacích scénářů“. Z provozních důvodů je možné toto pořadí změnit. V případě potřeby budou, v průběhu testování, vždy k danému testovacímu scénáři, vytvořeny přílohy obsahující opisy obrazovek a chybových logů.
Testy budou probíhat pokud možno paralelně, s výjimkou testů administrace a dalších testů, které mohou ovlivnit průběh ostatních testů. Tyto testy budou provedeny samostatně na závěr.
6.3. Účast poskytovatele
Testy proběhnou za účasti dostatečného počtu pracovníků poskytovatele.
7. Seznam testovacích scénářů
[O pořadí rozhoduje poskytovatel při dodržení požadavků podle smlouvy.]
ID scénáře | Testovací scénář | Testované požadavky/vlastnosti | Výsledek |
bez vad/s vadou kategorie A/B/C | |||
8. Jednotlivé testovací scénáře
[V souladu se smlouvou vytvoří poskytovatel.]
8.1. Popis polí testovacího scénáře
• Název – název testovacího scénáře ve vazbě na testovanou oblast/proces
• Verze – verze testovacího scénáře
• ID scénáře – pořadové číslo scénáře ve formátu Txx
• Popis – stručný popis testované oblasti/procesu
• Testované požadavky – seznam testovaných uživatelských požadavků (ID požadavku)
• Vstupní podmínky - popis podmínek pro realizaci testovacího scénáře, např.: nastavení rolí, způsob přihlášení, dostupnost/připravenost dat apod.
• Krok - popis jednotlivých kroků postupu, které bude provádět tester při testování ve struktuře
A – požadovaná akce, R – předpokládaná reakce systému
[Popsaná pole musí být vyplněna v návrhu každého testovacího scénáře.]
8.2. Šablona testovacího scénáře
[Opakuje se pro každý testovací scénář.]
Název | |||
ID scénáře | Verze | ||
Popis | |||
Testované požadavky | |||
Vstupní podmínky | |||
Popis kroků | |||
Krok | Činnost | Výsledek | |
1. | A: | [OK/ chyba] | |
R: | |||
2. | A: | ||
R: | |||
3. | A: | ||
R: | |||
4. | A: | ||
R: | |||
5. | A: | ||
R: | |||
Hodnocení | [Vyplní se na základě výsledků testování – s vadou/s vadami/bez vad.] | ||
Odůvodnění | [Vyplní se na základě výsledků testování.] | ||
Poznámka | [Vyplní se na základě výsledků testování.] | ||
Datum | [Vyplní se v rámci testování.] | Podpis testera | [Vyplní se v rámci testování.] |
Rozsah, obsah a lhůty školení
Příloha č. 6
Poskytovatel zorganizuje pro objednatele tři školení v délce jednoho dne (8 hodin) v rozsahu nezbytném pro zajištění provozu IS SD v systémovém prostředí objednatele (konfigurace, administrace, běžná správa), a to:
• Školení pro technické správce IS SD pro max. 2 odborné pracovníky objednatele, se zaměřením na implementaci upgrade / update / patch / hotfix, řešení poruch, konfiguraci a správu IS SD.
• Školení pro věcné správce IS SD pro max. 2 odborné pracovníky objednatele,
se zaměřením na správu IS SD.
• Školení procesních manažerů pro max. 20 odborných pracovníků objednatele,
se zaměřením na nastavení procesů v IS SD.
• Školení pro testery IS SD pro max. 25 odborných pracovníků objednatele, v rozsahu
nutném pro akceptační testování (provádění testovacích scénářů).
• Školení pro klíčové uživatele IS SD pro max. 25 odborných pracovníků objednatele, se zaměřením na založení, průběh a ukončování procesů IT Service Management a Facility Management v IS SD.
Potřebné školicí materiály zajistí poskytovatel. Prostory pro školení a konkrétní data školení určí objednatel po dohodě s poskytovatelem.
Školení pro technické správce a školení pro testery být provedeno nejpozději před zahájením akceptace díla podle přílohy č. 9 kap. 1.2 a školení pro věcné správce, školení procesních manažerů a školení pro klíčové uživatele nejpozději před zahájením ověřovacího provozu podle přílohy č. 9 kap. 2.
Obsah dokumentace IS SD
Příloha č. 7
Dokumentace je vypracována v jazyce podle čl. I odst. 14 smlouvy a ve formátech editovatelných aplikacemi MS Word 2016 nebo MS Excel 2016.
Dokumentace zachycuje skutečný a konečný stav IS SD v okamžiku předání a převzetí IS SD. Pozmění-li poskytovatel v rámci plnění této smlouvy IS SD tak, že dokumentace přestane zachycovat skutečný stav IS SD, je povinen neprodleně upravit dokumentaci tak, aby opětovně odpovídala skutečnému a konečnému stavu IS SD, a poskytnout ji objednateli vč. licence v rozsahu dle čl. X smlouvy. V rámci podpory běžného provozu podle čl. VI smlouvy tak poskytovatel činí bezplatně.
Dokumentace IS SD obsahuje následující součásti:
1. Příručka uživatele, obsahující:
1.1 popis aplikace a způsobu práce s aplikací pro uživatele v českém jazyce (tj. popisy podle uživatelských rolí).
2. Příručka věcného správce, obsahující:
• způsob administrace aplikace a dále funkční a technická specifikace v českém nebo anglickém jazyce (tj. postupy administrace IS SD – správa uživatelů apod.),
• detailní popis nahrání (vložení) nového procesu IT Service Management nebo Facility Management do IS SD, a to bez nutnosti asistence poskytovatele nebo jiné třetí osoby,
• správa uživatelů a rolí,
• a další potřebné informace a postupy pro administraci systému.
3. Příručka technického správce, obsahující:
• provozní postupy pro správce infrastruktury (postupy instalace a patchování, postupy při provozu, nastavení omezení přístupu, konfiguraci, bezpečnostní nastavení, základní každodenní činností obsluhy IS SD, spuštění, zastavení, případně restart systému apod.),
• podklady pro recovery plán obsahující všechny nezbytné informace pro pracovníky objednatele, jak mají postupovat v případě řešení krizových stavů (např. obnova po havárii IS SD) a jakou součinnost mají poskytovateli poskytovat v případě, že krizový stav řeší poskytovatel (např. jako vadu),
• umístění nezbytných záznamů (logů) vedoucí k bližší identifikaci závady a základní informace o tom, jak logy analyzovat (případně informaci, že konkrétní log je určen pro analýzu ve vyšších stupních podpory, a jak se tento log dá uložit do souboru, aby mohl být odeslán např. e-mailem),
• informace o postupech při typických závadách a chybových hlášeních a popis postupu/ů, jak blíže identifikovat závadu. V této části by měl být uveden popis typických závad, které
mohou nastat a mohou být odstraněny pracovníky objednatele. Rozsah těchto typických závad bude záviset na složitosti navrženého IS SD,
• informace o postupech při atypických závadách (např. informaci o tom, že se má
kontaktovat poskytovatel),
• informaci, jak zprovoznit příslušné komponenty IS SD v náhradní lokalitě,
• ostatní informace a postupy nutné pro technické zajištění provozu systému.
4. Technická dokumentace, obsahující:
• popis aplikačního programového rozhraní (dokumentace pro programátora k API),
• datový model (dokumentace datového modelu databáze, na základě kterého musí být možné vytvořit dotaz na konkrétní data obsažená v databázi. Na úrovni datového modelu musí být řešeny i vazby mezi entitami),
• komentář ke zdrojovému kódu doprogramovaných částí (resp. komentovaný zdrojový kód
doprogramovaných částí),
• popis interface na jiné systémy,
• a dále jakékoliv další podklady nezbytné pro úpravu IS SD v budoucnosti.
Dokumentace, vyjma komentáře ke zdrojovému kódu doprogramovaných částí, musí být objednateli předána nejpozději před zahájením akceptace díla podle přílohy č. 9 kap. 1.2 a komentář ke zdrojovému kódu nejpozději před zahájením ověřovacího provozu podle přílohy č. 9 kap. 2.
Akceptace a ověřovací provoz
Příloha č. 9
Poskytovatel umožní objednateli kontrolovat plnění dle smlouvy prostřednictvím akceptace jednotlivých níže určených částí plnění, a to jak formálně, tak za pomoci testovacího provozu IS SD v testovacím prostředí. Dále poskytovatel umožní objednateli zkontrolovat plnění dle smlouvy provedením ověřovacího provozu IS SD plně v systémovém prostředí objednatele (viz příloha č. 2) a zejména v produkčním prostředí (viz kap. 3.4.1 realizační studie). Za účelem uvedeného poskytne poskytovatel objednateli nezbytnou součinnost.
1. Akceptace
Akceptaci podléhá dílo vyjma částí podle čl. I odst. 9 písm. f) a h), avšak realizační studie bude akceptována v odlišném časovém rámci než ostatní části díla, neboť její akceptace podmiňuje realizaci ostatních částí díla.
O akceptaci realizační studie bude sepsán akceptační protokol, který podepíše alespoň jedna pověřená osoba za každou smluvní stranu.
O akceptaci zbylých částí díla bude sepsán akceptační protokol, který podepíše alespoň jedna pověřená osoba za každou smluvní stranu.
Pro akceptační protokoly se použije vzor uvedený v části „Vzor akceptačního protokolu“ této přílohy.
Průběh akceptace, ani její opakování či opakování jakékoliv její části, nemá vliv na lhůty
a doby podle smlouvy, resp. na jejich plynutí, nestanoví-li smlouva jinak.
1.1. Akceptace realizační studie
1.1.1. Podmínky zahájení akceptace realizační studie:
• poskytovatel předal objednateli realizační studii v elektronické podobě ve formátech editovatelných aplikacemi MS Word 2016 nebo MS Excel 2016, a to buď zasláním na e-maily pověřených osob, nebo předáním na obecně užívaném paměťovém médiu (např. CD, DVD, USB flashdisk) do podatelny objednatele v místě plnění a společně s informací o předání realizační studie, zaslanou na e-maily všech pověřených osob objednatele.
1.1.2. Průběh akceptace realizační studie:
Objednatel ověří, že realizační studie má touto smlouvou (vč. příloh) stanovený obsah, neobsahuje vnitřní logické rozpory a je technicky i jazykově jednoznačná (včetně prověření pravopisné a gramatické správnosti realizační studie).
1.1.3. Výsledek akceptace realizační studie:
Do 10 pracovních dnů od naplnění podmínek pro zahájení akceptace realizační studie informuje kterákoliv z pověřených osob objednatele e-mailem pověřené osoby poskytovatele že:
• realizační studie je bez závad, a je tedy akceptována; nebo
• realizační studie obsahuje závady, a tedy není akceptována; v takovém případě sdělí objednatel k realizační studii připomínky.
Do 6 pracovních dnů od sdělení připomínek objednatele k realizační studii zapracuje poskytovatel tyto připomínky do realizační studie; poté se opakuje akceptace realizační studie obdobně podle kap. 1.1 této přílohy.
Akceptace realizační studie se může opakovat, avšak není-li realizační studie akceptována ani po třetí akceptaci, objednatel od smlouvy odstoupí podle čl. XV odst. 5 písm. a) smlouvy.
1.2. Akceptace díla
1.2.1. Podmínky zahájení akceptace díla:
• byla akceptována realizační studie (vč. popisu testovacího prostředí
a vývojového prostředí v kap. 3.4.1 realizační studie),
• poskytovatel předal objednateli testovací scénáře v elektronické podobě ve formátech editovatelných aplikacemi MS Word 2016 nebo MS Excel 2016, a to buď zasláním na e-maily pověřených osob, nebo předáním na obecně užívaném paměťovém médiu (např. CD, DVD, USB flashdisk) do podatelny objednatele v místě plnění a společně s informací o předání testovacích scénářů, zaslanou na e-maily všech pověřených osob objednatele,
• poskytovatel předal objednateli dokumentaci, vyjma komentáře ke zdrojovému kódu doprogramovaných částí, v elektronické podobě ve formátech editovatelných aplikacemi MS Word 2016 nebo MS Excel 2016, a to buď zasláním na e-maily pověřených osob, nebo předáním na obecně užívaném paměťovém médiu (např. CD, DVD, USB flashdisk) do podatelny objednatele v místě plnění a společně s informací o předání dokumentace, zaslanou na e-maily všech pověřených osob objednatele,
• poskytovatel implementoval IS SD do testovacího prostředí a vývojového prostředí a provedl konfiguraci IS SD v testovacím prostředí (popisy testovacího prostředí a vývojového prostředí se nacházejí v kap. 3.4.1 realizační studie),
• poskytovatel provedl migraci dat z Původního SD do testovacího prostředí ve shodě s realizační studií,
• poskytovatel provedl školení pro technické správce a školení pro testery
objednatele podle přílohy č. 6,
• poskytovatel informoval e-mailem všechny pověřené osoby objednatele, že je možno započít s akceptací díla.
1.2.2. Průběh akceptace díla – dokumentace:
Objednatel ověří, že dokumentace má touto smlouvou (vč. příloh) stanovený obsah, neobsahuje vnitřní logické rozpory a je technicky i jazykově jednoznačná (včetně prověření pravopisné a gramatické správnosti dokumentace).
Pozmění-li poskytovatel v rámci akceptace IS SD tak, že dokumentace přestane zachycovat skutečný stav IS SD, je povinen pozměnit do ukončení akceptace příslušným způsobem i dokumentaci.
1.2.3. Průběh akceptace díla – IS SD a integrita migrovaných dat:
Objednatel ověří, že IS SD je funkční, že naplňuje všechny funkční a nefunkční požadavky podle přílohy č. 1, že vykazuje všechny další vlastnosti, které jsou v příloze č. 1, v dalších přílohách nebo v této smlouvě uvedeny, jakož i že IS SD odpovídá akceptované realizační studii, že migrovaná data z Původního SD nevykazují závady v integritě a že IS SD jako celek je způsobilý k implementaci do systémového prostředí objednatele (viz příloha č. 2), resp. produkčního prostředí (viz kap. 3.4.1 realizační studie).
Ověření podle předchozího odstavce proběhne zejména:
• Provozem IS SD v testovacím prostředí (viz kap. 3.4.1 realizační studie) – testovacím provozem.
• Provedením testovacích scénářů, jejichž obsah musí odpovídat čl. I odst. 9 písm. b) smlouvy. Objednatel si vyhrazuje právo vybrané testovací scénáře neprovést či v jejich provedení učinit změny.
• Užíváním IS SD a všech jeho funkcionalit při testovacím provozu při různých stupních zátěže.
• Ověřením integrity migrovaných dat IS SD v testovacím prostředí mimo jiné porovnáním s daty v Původním SD a prací s těmito daty v IS SD.
• Provedením penetračních testů a skenování známých zranitelností objednatelem nebo třetími osobami (externími subjekty, které zajistí objednatel).
Během akceptace díla dle kap. 1.2.3 této přílohy je poskytovatel povinen zajistit přítomnost pracovníků poskytovatele v dostatečném počtu, nejméně však jednoho pracovníka, a to zejména při provádění testovacích scénářů. Pověřená osoba objednatele může rozhodnout, kterých částí akceptace díla dle kap. 1.2.3 této přílohy se pracovníci poskytovatele nezúčastní.
Ověření vč. testovacího provozu se bude provádět zásadně na úrovni jednotlivých rolí a nikoliv pod účtem systémového administrátora a takovým způsobem, při kterém se projeví případné nekonzistence z hlediska přístupových práv apod.
1.2.4. Průběh akceptace díla – kategorizace vad:
Během ověření podle kap. 1.2.2 i 1.2.3 této přílohy je poskytovatel povinen
průběžně odstraňovat zjištěné závady díla.
Každé zjištěné závadě díla, která nebude odstraněna poskytovatelem bezprostředně po jejím zjištění, bude přidělena kategorie:
• A – kritická závada – velmi vážná závada, která znemožňuje práci s IS SD nebo díky níž IS SD nesplňuje zadání, tzn. že splňuje alespoň jednu z níže uvedených charakteristik:
▪ IS SD a integrita migrovaných dat:
• nedodržení či neprokázání realizace nebo jen částečná realizace některého z požadavků uvedeného ve smlouvě nebo jejích přílohách,
• znemožňuje používání IS SD jako celku nebo znemožňuje používání základních funkcí dodaného řešení podle jeho dokumentace,
• vyplývá z nedodržení závazných právních předpisů,
• zapříčiní ztrátu dat nebo nekonzistenci dat,
• způsobuje, že použití dodaného řešení by nebylo bezpečné nebo řešení vykazuje technickou zranitelnost při penetračním testu,
• ohrožuje provoz nebo dostupnost ostatních aplikací nebo samotného dodaného řešení v provozním prostředí objednatele,
• způsobuje, že dodané řešení není schopno pracovat při běžné provozní zátěži,
• za provozních podmínek vede k omezení funkcionality systému s dopadem na významný počet uživatelů,
• projevuje se stále, občas nebo náhodně a splňuje některou z výše popsaných charakteristik,
• B – významná závada – závada, kterou je možno dočasně vyřešit organizačním či jiným opatřením, tzn. že splňuje alespoň jednu z níže uvedených charakteristik:
▪ dokumentace:
• chybějící textová část vyplývající z definované struktury,
• textová část neodpovídá skutečnosti popisované entity (např. systému, procesu, chybové zprávě),
▪ IS SD a integrita migrovaných dat:
• rozpor s některým z povinných požadavků, nebo vítaných požadavků, které se poskytovatel zavázal realizovat, na systém (příloha č. 1), ale je možné pro její překonání nalézt odpovídající alternativu, která je akceptovatelná objednatelem,
• projevuje se stále, občas nebo náhodně a splňuje některou z výše popsaných charakteristik,
• C – ostatní závada – závada, která nemá vliv na provoz systému, tzn. že splňuje alespoň jednu z níže uvedených charakteristik:
▪ dokumentace:
• nejednoznačnost textové části, nevhodné formátování apod.,
▪ IS SD a integrita migrovaných dat:
• její výskyt neovlivňuje zásadním způsobem aktivity uživatelů
a výstupy z těchto aktivit,
• projevuje se stále, občas nebo náhodně a splňuje některou z výše popsaných charakteristik,
• ostatní vady výše nepopsané.
O kategorizaci závady rozhodne s konečnou platností objednatel.
Poskytovatel je povinen bez zbytečného odkladu odstranit jakoukoliv zjištěnou závadu díla znemožňující pokračování v akceptaci díla nebo jeho části. Celkový čas odstraňování závad, které znemožňují pokračování v akceptaci díla nebo kterékoliv jeho části, nesmí během akceptace přesáhnout 20 pracovních dnů.
1.2.5. Výsledek akceptace díla:
Do 10 pracovních dnů od naplnění podmínek pro zahájení akceptace díla informuje kterákoliv z pověřených osob objednatele e-mailem pověřené osoby poskytovatele že:
• dílo je bez závad, a je tedy akceptováno;
• dílo má závadu nebo závady, avšak je akceptováno s výhradami; v takovém případě určí objednatel, po projednání se poskytovatelem, v akceptačním protokolu pro každou ze závad, vyjma neodstranitelných závad kategorie C, závaznou lhůtu pro její odstranění; lhůta může být stanovena i s odkládací podmínkou7;
• dílo má závadu nebo závady, a tedy není akceptováno; v takovém případě sdělí objednatel k dílu své připomínky, které mohou spočívat v pouhém výčtu závad díla;
• celkový čas odstraňování závad, které znemožňovaly pokračování v akceptaci díla nebo kterékoliv jeho části, přesáhl během akceptace 20 pracovních dnů, a dílo tedy není akceptováno.
Lhůta podle předchozího odstavce neběží po dobu, po kterou není možno provádět akceptaci:
• Protože poskytovatel neposkytuje potřebnou součinnost, zejména jeho pracovník či pracovníci nejsou přítomni testovacímu provozu.
• Vyskytla se závada díla znemožňující pokračování v akceptaci díla nebo jeho části a nebyla doposud poskytovatelem odstraněna (zejména, avšak nikoliv výlučně, závady IS SD kategorie A, zabraňující pokračovat v testovacím provozu či provedení testovacího scénáře).
Dílo bez závad musí objednatel akceptovat.
Dílo s jakoukoliv závadou kategorie A, více jak 5 závadami kategorie B nebo více jak 10 závadami kategorie C nesmí objednatel akceptovat, a to ani s výhradami.
Dílo nemající více jak 3 závady kategorie C nebo neodstranitelnou závadu kategorie C musí objednatel akceptovat s výhradami; v takovém případě může objednatel určit lhůty pro odstranění závad i bez projednání se poskytovatelem.
Do 6 pracovních dnů od sdělení připomínek objednatele k dílu poskytovatel odstraní závady díla, resp. upraví dílo podle připomínek; poté se opakuje akceptace díla obdobně podle kap. 1.2 této přílohy.
Akceptace díla se může opakovat, avšak není-li dílo akceptováno nebo akceptováno s výhradami ani po třetí akceptaci, objednatel od smlouvy odstoupí podle čl. XV odst. 5 písm. b) smlouvy.
7 Např. do 5 pracovních dnů poté, co výrobce programového prostředku (SW) vydá příslušný update nebo patch,
nejpozději do 2 týdnů, nebude-li předán postup workaroundu, jinak do 6 měsíců atd.
2. Ověřovací provoz
Ověřovací provoz nelze zahájit, není-li dílo akceptováno, popř. akceptováno s výhradami.
Objednatel zkontroluje konečný stav díla před jeho převzetím provedením ověřovacího provozu IS SD plně v systémovém prostředí objednatele (viz příloha č. 2), resp. produkčním prostředí (viz kap. 3.4.1 realizační studie). Při ověřovacím provozu se ověřuje, že IS SD naplňuje všechny funkční i nefunkční požadavky podle přílohy č. 1, že vykazuje všechny další vlastnosti, které jsou v příloze č. 1, v dalších přílohách nebo v této smlouvě uvedeny, jakož i že IS SD odpovídá akceptované realizační studii, že migrovaná data z Původního SD nevykazují závady v integritě a především, že IS SD jako celek funguje, nevykazuje zranitelnosti a nezpůsobuje problémy v systémovém prostředí objednatele (viz příloha č. 2). Součástí kontroly konečného stavu díla je i ověření konečného stavu dokumentace.
Během ověřovacího provozu je poskytovatel povinen, na žádost kterékoliv pověřené osoby objednatele, zajistit přítomnost pracovníků poskytovatele v dostatečném počtu, nejméně však jednoho pracovníka. Pověřená osoba objednatele může rozhodnout, kterých částí ověřovacího provozu se pracovníci poskytovatele nezúčastní.
Průběh ověřovacího provozu, ani jeho opakování či opakování jakékoliv jeho části, nemá vliv
na lhůty a doby podle smlouvy, resp. na jejich plynutí, nestanoví-li smlouva jinak.
2.1.1. Podmínky ověřovacího provozu:
• dílo bylo akceptováno, popř. akceptováno s výhradami,
• poskytovatel implementoval IS SD do produkčního prostředí a vývojového prostředí a provedl konfiguraci IS SD v produkčním prostředí (popis produkčního prostředí se nachází v kap. 3.4.1 realizační studie),
• poskytovatel provedl migraci dat z Původního SD do produkčního prostředí ve shodě s realizační studií,
• poskytovatel předal objednateli dokumentaci s úpravami nezbytnými s ohledem na průběh akceptace, vyjma komentáře ke zdrojovému kódu doprogramovaných částí, v elektronické podobě ve formátech editovatelných aplikacemi MS Word 2016 nebo MS Excel 2016, a to buď zasláním na e-maily pověřených osob, nebo předáním na obecně užívaném paměťovém médiu (např. CD, DVD, USB flashdisk) do podatelny objednatele v místě plnění a společně s informací o předání dokumentace, zaslanou na e-maily všech pověřených osob objednatele,
• poskytovatel předal objednateli konfigurační soubory IS SD ve formátu čitelném IS SD nebo slovní popis postupu konfigurace IS SD v elektronické podobě ve formátech editovatelných aplikacemi MS Word 2016 nebo MS Excel 2016, a to buď zasláním na e-maily pověřených osob, nebo předáním na obecně užívaném paměťovém médiu (např. CD, DVD, USB flashdisk) do podatelny objednatele v místě plnění a společně s informací o předání uvedeného, zaslanou na e-maily všech pověřených osob objednatele,
• poskytovatel provedl školení pro věcné správce, školení procesních manažerů a školení pro klíčové uživatele objednatele podle přílohy č. 6,
• poskytovatel informoval e-mailem všechny pověřené osoby objednatele, že je možno započít s ověřovacím provozem.
2.1.2. Průběh ověřovacího provozu:
Ověřovací provoz bude probíhat zejména:
• Provozem IS SD v produkčním prostředí (viz kap. 3.4.1 realizační studie).
• Užíváním IS SD a všech jeho funkcionalit bez omezení v systémovém prostředí objednatele (viz příloha č. 2) při různých stupních zátěže.
• Ověřením integrity migrovaných dat v produkčním prostředí porovnáním s daty v Původním SD, s daty IS SD v testovacím prostředí a prací s těmito daty v IS SD.
• Provedením penetračních testů a skenování známých zranitelností objednatelem nebo třetími osobami (externími subjekty, které zajistí objednatel).
• Zkušebním použitím konfiguračních souborů IS SD nebo postupu konfigurace IS SD podle slovního popisu.
• Ověřením, že dokumentace má touto smlouvou (vč. příloh) stanovený obsah, neobsahuje vnitřní logické rozpory a je technicky i jazykově jednoznačná (včetně prověření pravopisné a gramatické správnosti dokumentace).
Pozmění-li poskytovatel v rámci ověřovacího provozu IS SD tak, že dokumentace přestane zachycovat skutečný stav IS SD, je povinen pozměnit do ukončení ověřovacího provozu příslušným způsobem i dokumentaci.
2.1.3. Průběh ověřovacího provozu – kategorizace vad:
Během ověřovacího provozu je poskytovatel povinen průběžně odstraňovat zjištěné vady díla.
Každé zjištěné vadě díla, která nebude odstraněna poskytovatelem bezprostředně
po jejím zjištění, bude přidělena kategorie:
• A – odpovídající kategorii havárie podle čl. VII odst. 2 písm. a) smlouvy s tím, že vady zjištěné penetračním testováním nebo skenováním známých zranitelností je možno zařadit do této kategorie i bez ohledu na jejich další charakteristiku,
• B – odpovídající kategorii významná vada podle čl. VII odst. 2 písm. b) smlouvy s tím, že za vady kategorie B se dále považují rovněž vady, kdy část textového obsahu neodpovídá skutečnosti popisovaného systému, procesu, oblasti apod., jehož výklad však neznemožňuje používání systému,
• C – odpovídající kategorii ostatní vada podle čl. VII odst. 2 písm. c) smlouvy.
O kategorizaci vady rozhodne s konečnou platností objednatel.
Poskytovatel je povinen bez zbytečného odkladu odstranit jakoukoliv zjištěnou vadu díla znemožňující pokračování v ověřovacím provozu nebo ověřovací provoz omezující. Celkový čas odstraňování vad, které znemožňují pokračování v ověřovacím provozu nebo ověřovací provoz omezují, nesmí přesáhnout 30 pracovních dnů.
2.1.4. Výsledek ověřovacího provozu:
Do dvou měsíců od naplnění podmínek pro zahájení ověřovacího provozu díla informuje kterákoliv z pověřených osob objednatele e-mailem pověřené osoby poskytovatele že:
• dílo je bez vad nebo vykazuje nejvýše 10 vad kategorie C, které objednatel považuje za plně a snadno odstranitelné, včetně jejich výčtu, a tedy ověřovací provoz byl ukončen úspěšně;
• dílo vykazuje vadu/y kategorie C, kterou/é objednatel považuje
za neodstranitelné nebo odstranitelné pouze obtížně, včetně jejich výčtu:
• avšak jejich počet nepřekračuje 10 a objednatel je považuje za natolik nevýznamné, že zájem na předání a převzetí díla převažuje, a tedy ověřovací provoz byl ukončen úspěšně;
• a objednatel je považuje za natolik významné, že s nimi nelze dílo převzít, nebo jejich počet překračuje 10, a tedy ověřovací provoz byl ukončen neúspěšně;
do počtu vad kategorie C podle tohoto odstavce se zahrnou i neodstranitelné závady kategorie C, s nimiž objednatel akceptoval dílo s výhradami.
• dílo vykazuje vadu/y kategorie A nebo vadu/y kategorie B, včetně jejich výčtu,
a tedy ověřovací provoz byl ukončen neúspěšně;
jako vada B se zahrne též závada kategorie B, nerozhodne-li pověřená osoba objednatele jinak u závady kategorie B, jejíž lhůta pro odstranění je uvedena v protokolu o akceptaci díla s odkládací podmínkou;
• celkový čas odstraňování vad, které znemožňovaly pokračování v ověřovacím provozu nebo ověřovací provoz omezovaly, přesáhl 30 pracovních dnů, a tedy ověřovací provoz byl ukončen neúspěšně.
Lhůta podle předchozího odstavce neběží po dobu, po kterou není možno provádět ověřovací provoz:
• Protože poskytovatel neposkytuje potřebnou součinnost, zejména jeho pracovník či pracovníci nejsou přítomni ověřovacímu provozu.
• Vyskytla se vada díla znemožňující pokračovat v ověřovacím provozu nebo ověřovací provoz omezující a nebyla doposud poskytovatelem odstraněna (zejména, avšak nikoliv výlučně, vady IS SD kategorie A).
Do 10 pracovních dnů od neúspěšně ukončeného ověřovacího provozu poskytovatel odstraní vady, které vedly k neúspěchu, a informuje e-mailem všechny pověřené osoby objednatele, že je možno opakovat ověřovací provoz; poté se opakuje ověřovací provoz obdobně podle kap. 2 této přílohy.
Ověřovací provoz se může opakovat, avšak není-li úspěšně ukončen ani po třetím provedení, objednatel od smlouvy odstoupí podle čl. XV odst. 5 písm. c) smlouvy. Objednatel od smlouvy rovněž odstoupí podle čl. XV odst. 5 písm. c) smlouvy, pokud poskytovatel po neúspěšném ukončení ověřovacího provozu prohlásí, že nehodlá odstraňovat vady, které vedly k neúspěchu.
Poskytovatel není oprávněn dílo předat a objednatel není povinen dílo převzít,
nebyl-li ověřovací provoz nebo opakovaný ověřovací provoz ukončen úspěšně.
Vzor akceptačního protokolu
Akceptační protokol
Poskytovatel | Objednatel |
Česká národní banka | |
Na Příkopě 28 | |
115 03 Praha 1 | |
IČO: | IČO: 48136450 |
DIČ: | DIČ: CZ48136450 |
Evidenční číslo smlouvy v ČNB | |
Název smlouvy | |
Předmět akceptace: |
Závěr akceptace
Shrnutí obsahu akceptace.
Z výše uvedených důvodů byla akceptace uzavřena s výsledkem:
Akceptováno s výhradami/Akceptováno
Následné kroky, např.: Poskytovatel akceptoval uvedené vady s tím, že odstraní vady uvedené v příloze č.1
ve lhůtách tam uvedených atd.
V Praze dne ……………………
Za poskytovatele: Za objednatele:
Akceptační protokol – Příloha č.1
Seznam vad a lhůty k odstranění vad
ID | Kategorie | Popis vady | Lhůta k odstranění vady |
Vzor předávacího protokolu
Předávací protokol
Poskytovatel | Objednatel |
Česká národní banka | |
Na Příkopě 28 | |
115 03 Praha 1 | |
IČO: | IČO: 48136450 |
DIČ: | DIČ: CZ48136450 |
Evidenční číslo smlouvy v ČNB | |
Název smlouvy | |
Předmět předání: |
Dne …………………… poskytovatel předal a objednatel převzal ……………………
• ……………………
• ……………………
dle smlouvy …………………… (evidenční číslo ČNB ).
Převzato bylo s výhradami/bez výhrad.
Následné kroky, např.: Poskytovatel akceptoval uvedené vady s tím, že odstraní vady uvedené v příloze č.1
ve lhůtách tam uvedených atd.
V Praze dne ……………………
Za poskytovatele: Za objednatele:
Předávací protokol – Příloha č.1
Seznam vad a lhůty k odstranění vad
ID | Kategorie | Popis vady | Lhůta k odstranění vady |