SMLOUVA O POSKYTOVÁNÍ SLUŽEB
SMLOUVA O POSKYTOVÁNÍ SLUŽEB
(dále jen „Smlouva“)
uzavřená v souladu s ustanovením § 1746 odst. 2 zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „OZ“) za přiměřeného použití ustanovení § 2586 a násl. téhož zákona
Smluvní strany
Objednatel:
Statutární město Brno
Zastoupen: JUDr. Xxxxxxxx Xxxxxxxx, primátorkou
Se sídlem: Dominikánské náměstí 1, 602 00 Brno
IČO: 44992785
DIČ: CZ44992785
Bankovní spojení: Česká spořitelna, a.s.
Olbrachtova 1929/62, 140 00 Praha 4
Číslo účtu: 111211222/0800
Ve věcech technických
je oprávněn jednat: Xxx. Xxx Xxxxxxxxx, správce AIS
Ve věcech smluvních
je oprávněn jednat: Xxx. Xxxxx Xxxxxx, vedoucí OMI MMB
Xxxxx Xxxxxxx:
Poskytovatel:
[Doplní poskytovatel]
Zastoupen: _______________________
Se sídlem: _______________________
IČO: _______________________
DIČ: _______________________
Společnost zapsaná v OR vedeném u_______________________
Bankovní spojení: _______________________
Číslo účtu: _______________________
Ve věcech technických je
oprávněn jednat: _______________________
Ve věcech smluvních
je oprávněn jednat: _______________________
Xxxxx Xxxxxxx: _______________________
Pro účely Smlouvy se uvedené smluvní strany označují jako Objednatel a Poskytovatel.
Smlouva byla uzavřena na základě výsledku výběrového řízení na veřejnou zakázku s názvem „Pronájem a implementace systémů Service desk a CMDB“ (dále jen "Veřejná zakázka"), zadávanou Objednatelem jako zadavatelem mimo režim zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „ZZVZ“), neboť nabídka Poskytovatele podaná v rámci výběrového řízení na Veřejnou zakázku byla Objednatelem vyhodnocena jako nejvýhodnější.
Účel a předmět Xxxxxxx
Účelem Smlouvy je využití zdrojů, know-how a organizačních schopností Poskytovatele k zajištění pronájmu, implementace, školení, migrace konfiguračních dat, provozu, údržby a zálohování informačních systémů Service Desk (dále jen „SD“) a konfigurační databáze (dále jen „CMDB“) na základě požadavků Objednatele.
Předmětem Smlouvy je závazek Poskytovatele:
implementovat a konfigurovat SD a CMDB v prostředí Objednatele dle podmínek uvedených v Příloze č. 1 Specifikace Expertních služeb a dle Přílohy č. 2 Harmonogram plnění a platební milníky této Smlouvy;
poskytnout Objednateli licence potřebné k provozování SD a CMDB dle podmínek uvedených ve Smlouvě;
pronajímat SD a CMDB po dobu 4 let ode dne protokolárního předání a převzetí implementovaného SD a CMDB, a to včetně údržby a provozu.
(souhrnně dále jen „Expertní služby“);
v souladu se všemi relevantními závaznými právními předpisy, jakož i se Smlouvou sjednanými podmínkami, a současně závazek Objednatele zaplatit Poskytovateli cenu stanovenou v čl. 4 Smlouvy za řádné poskytnutí předmětu plnění Smlouvy.
Poskytovatel se zavazuje realizovat předmět plnění Smlouvy v rozsahu a za podmínek uvedených ve Smlouvě a v zadávací dokumentaci Veřejné zakázky. Poskytovatel tímto prohlašuje, že veškeré podmínky a požadavky Objednatele vymezené v zadávací dokumentaci Veřejné zakázky jsou pro něj závazné a jsou součástí Smlouvy. Pokud by některá ustanovení Smlouvy byla v rozporu s podmínkami a požadavky Objednatele vymezenými v zadávací dokumentaci Veřejné zakázky, mají přednost ustanovení zadávací dokumentace Veřejné zakázky.
Poskytováním Expertních služeb se rozumí veškerá činnost Poskytovatele dle Smlouvy směřující k provádění činností v rozsahu dle Přílohy č. 1 Specifikace Expertních služeb, a to i v případě, že výsledek činnosti Poskytovatele má charakter díla ve smyslu § 2587 OZ nebo autorského díla ve smyslu § 2 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 „AZ“). Poskytovatel se zavazuje řídit volbami a rozhodnutími Objednatele.
Lhůta, způsob a místo plnění
Poskytovatel se zavazuje poskytovat Expertní služby způsobem a ve lhůtách (termínech) dle Smlouvy. Místem předání plnění je sídlo Objednatele nebo jiná budova, v níž sídlí Magistrát města Brna. Expertní služby, které lze řešit vzdáleně, budou po dohodě s Objednatelem poskytnuty v sídle Poskytovatele.
Cena
Cena bez DPH: Doplní poskytovatel Kč
DPH (21 %): Doplní poskytovatel Kč
Cena včetně DPH: Doplní poskytovatel Kč
Cena za řádnou a včasnou migraci konfiguračních dat je stanovena dohodou smluvních stran ve výši:
Cena bez DPH: Doplní poskytovatel Kč
DPH (21 %): Doplní poskytovatel Kč
Cena včetně DPH: Doplní poskytovatel Kč
Cena za licence je stanovena dohodou smluvních stran ve výši:
Cena bez DPH: Doplní poskytovatel Kč
DPH (21 %): Doplní poskytovatel Kč
Cena včetně DPH: Doplní poskytovatel Kč
Cena za měsíční pronájem, údržbu a provoz SD a CMDB je stanovena dohodou smluvních stran ve výši:
Cena bez DPH: Doplní poskytovatel Kč
DPH (21 %): Doplní poskytovatel Kč
Cena včetně DPH: Doplní poskytovatel Kč
Ceny dle čl. 4 odst. 4.1 až 4.4 jsou sjednány jako ceny nejvýše přípustné a závazné po celou dobu plnění Smlouvy a zahrnují veškeré náklady nutné nebo Poskytovatelem vynaložené pro řádné splnění předmětu Smlouvy.
V případě jiné sazby DPH bude Poskytovatel Objednateli účtovat sazbu DPH ve výši odpovídající platným a účinným právním předpisům ke dni zdanitelného plnění. Cena za plnění bez DPH tímto není dotčena. Poskytovatel odpovídá za to, že sazba DPH je stanovena v souladu s platnými právními předpisy.
Platební podmínky
Jednotlivá dílčí plnění vymezená jako Platební milníky v příloze č. 2 Smlouvy, jež představují ve smyslu příslušných ustanovení zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů (dále jen „zákon o DPH“) samostatná zdanitelná plnění, se považují za uskutečněná dnem převzetí příslušných plnění dle čl. 7 Smlouvy Objednatelem.
Poskytovateli vzniká právo fakturovat plnění za jednotlivé Expertní služby označené jako Platební milníky dle čl. 5 odst. 5.1 Xxxxxxx, tj. vystavit daňový doklad (fakturu) Objednateli, ve výši sjednané za příslušnou Expertní službu podle čl. 4 Smlouvy, po jeho řádném poskytnutí, nejdříve však po převzetí plnění Objednatelem (akceptace) za podmínek uvedených v čl. 7 Smlouvy.
Cena plnění dle čl. 4 odst. 4.4 Smlouvy bude Objednatelem hrazena měsíčně na základě faktury Poskytovatele, kterou Poskytovatel vystaví vždy do 15. dne kalendářního měsíce následujícího po měsíci, v němž bylo plnění poskytnuto.
Faktura musí obsahovat číslo Smlouvy, všechny náležitosti řádného účetního a daňového dokladu ve smyslu příslušných zákonných ustanovení, zejména zákona o DPH a § 435 OZ a bude doručena do datové schránky Objednatele.
Splatnost faktury je stanovena na 30 dnů ode dne jejího doručení Objednateli.
V případě, že faktura nebude splňovat zákonné nebo smluvené náležitosti, včetně jejího doručení do datové schránky, je Objednatel oprávněn zaslat ji ve lhůtě splatnosti zpět Poskytovateli k doplnění, aniž se tak dostane do prodlení se splatností; lhůta splatnosti počíná běžet znovu od opětovného doručení náležitě doplněného či opraveného dokladu.
Povinnost zaplatit sjednanou cenu plnění je splněna dnem odepsání příslušné částky z účtu Objednatele ve prospěch účtu Poskytovatele. Všechny částky poukazované v Kč vzájemně smluvními stranami na základě Smlouvy musí být prosté jakýchkoliv bankovních poplatků nebo jiných nákladů spojených s převodem na jejich účty.
Platba bude poukázána na bankovní účet Poskytovatele uvedený ve faktuře. Uvedený bankovní účet musí být zveřejněn správcem daně způsobem umožňujícím dálkový přístup. V případě, že účet tímto způsobem zveřejněn nebude, je Objednatel oprávněn uhradit Poskytovateli cenu na úrovni bez DPH, DPH Objednatel poukáže správci daně.
Objednatel neposkytuje Poskytovateli na předmět plnění Smlouvy jakékoliv zálohy.
Součinnost, práva a povinnosti smluvních stran
Objednatel se zavazuje Poskytovateli poskytovat součinnost vyplývající ze Smlouvy, a to pouze v nezbytně nutném rozsahu, a nikoliv nad rámec součinnosti jinak obvyklé při poskytování obdobného druhu plnění.
Poskytovatel je povinen postupovat při plnění předmětu Xxxxxxx s odbornou péčí, podle nejlepších znalostí a schopností a sledovat a chránit oprávněné zájmy Objednatele.
Poskytovatel je povinen v průběhu poskytování Expertních služeb neprodleně upozornit Objednatele na nevhodnost jeho pokynů nebo předané dokumentace. Toto upozornění musí mít písemnou formu. V takovém případě je Objednatel povinen se k tomuto upozornění bez zbytečného odkladu písemně vyjádřit a je povinen učinit veškerá opatření, aby Poskytovatel mohl pokračovat v poskytování Expertních služeb řádně.
Objednatel je oprávněn kdykoliv kontrolovat provádění smluvní činnosti Poskytovatele. Zjistí-li, že Poskytovatel realizuje povinnosti vyplývající ze Xxxxxxx v rozporu s povinnostmi stanovenými obecně závaznými právními předpisy nebo Smlouvou, je oprávněn požadovat, aby Poskytovatel bezplatně a bezodkladně odstranil vady vzniklé z této činnosti a činnost prováděl řádným způsobem.
Předání a převzetí
Předání a převzetí všech dílčích plnění (Expertních služeb) vymezených v příloze č. 2 Smlouvy bude probíhat postupně dle dohodnutých termínů jako Platební milník a je splněno jejich řádným ukončením a úspěšným protokolárním předáním a převzetím Objednatelem.
Průběh předání a převzetí (akceptační řízení) probíhá v těchto krocích:
Současně s předáním plnění Poskytovatelem stvrdí Objednatel svým podpisem jeho předání na Poskytovatelem předloženém protokolu o předání a převzetí. Tímto podpisem v příslušné části protokolu o předání a převzetí nevyjadřuje souhlas přebírající smluvní strana s obsahem předmětu předání, nýbrž pouze potvrzuje skutečnosti, že k takovému předání došlo.
Objednatel následně do 5 pracovních dnů od předání plnění stvrdí svým podpisem akceptaci plnění v příslušné části protokolu o předání a převzetí, a to s následujícím výsledkem:
bez výhrad (akceptace bez výhrad), pokud předané plnění je bez jakýchkoliv vad či nedodělků;
s výhradami (akceptace s výhradami), pokud předané plnění má sice vady či nedodělky, nicméně nejde o takové vady či nedodělky, které brání užití či převzetí plnění; případně
nepřevzetí plnění (neakceptace), pokud předané plnění má takové vady či nedodělky, které brání užití či převzetí plnění.
Při převzetí plnění s výhradami je Objednatel povinen uvést na protokolu o předání a převzetí písemný seznam vad či nedodělků nebránících užití či převzetí plnění a požadovaný termín jejich odstranění s tím, že pokud se smluvní strany nedohodnou v konkrétním případě na jiném termínu odstranění vad či nedodělků, je Poskytovatel povinen případné vady či nedodělky odstranit nejpozději do 5 pracovních dnů od jejich oznámení ze strany Objednatele v rámci protokolu o předání a převzetí.
Při nepřevzetí plnění je Objednatel povinen uvést na protokolu o předání a převzetí písemný seznam vad či nedodělků bránících užití či převzetí plnění a Poskytovateli bude poskytnuta přiměřená lhůta k jejich odstranění a dohodnut nový termín předání plnění; uvedeným není dotčena odpovědnost Poskytovatele za včasné poskytnutí Expertních služeb v termínech dle Smlouvy.
Podpis protokolu o předání a převzetí v části týkající se akceptace Objednatelem, a to s výsledkem bez výhrad či s výhradami je podmínkou pro vznik oprávnění Poskytovatele vystavit fakturu za poskytnutí příslušné části Expertních služeb dle Smlouvy, je-li takové plnění platebním milníkem dle Smlouvy.
Změnové řízení
Každá smluvní strana může kdykoli během doby trvání Smlouvy požádat o jakoukoli změnu v rozsahu, typech nebo parametrech Expertních služeb. Žádná smluvní strana není povinna navrhovanou změnu přijmout. Poskytovatel se však zavazuje přijmout za přiměřených podmínek změny požadované Objednatelem v případě, že se jedná o změny související se změnou legislativy.
Poskytovatel pro zachování kontinuity poskytovaných Expertních služeb vede řádnou a úplnou dokumentaci všech provedených změn poskytovaných Expertních služeb.
Změnové řízení se zahajuje písemnou žádostí na změnové řízení podanou osobou oprávněnou jednat ve věcech smluvních nebo technických a doručenou druhé smluvní straně. V oznámení musí být definován alespoň rámcově rozsah požadované úpravy Expertních služeb.
Poskytovatel zpracuje v součinnosti s Objednatelem podklady na změnové řízení.
Smluvní strany se dohodnou o změně, způsobu jejího řešení a o jejích důsledcích do Smlouvy.
Pokud má změna dopad do Smlouvy, musí být provedena formou písemného dodatku ke Smlouvě nebo uzavřením nové smlouvy, přičemž musí být vždy respektován ZZVZ.
Poskytovatel bude realizovat změny či doplňky poskytovaného plnění pouze v tom případě, že bude v rámci změnového řízení dosaženo dohody v otázkách změn termínů a ceny, jakož i dohody o případných dalších podmínkách.
Nevyjádří-li se Objednatel ke změnám navrhovaným v rámci změnového řízení bezodkladně, nejdéle však do deseti pracovních dnů platí, že s navrhovanou změnou nesouhlasí a Poskytovatel bude pokračovat v poskytování plnění podle původně sjednaných podmínek.
Odpovědnost za škodu, odpovědnost za vady, záruka, sankční ujednání
Smluvní strany se zavazují k vyvinutí maximálního úsilí k předcházení škodám a k minimalizaci vzniklých škod. Smluvní strany nesou odpovědnost za škodu dle platných právních předpisů a Smlouvy. Poskytovatel odpovídá za škodu rovněž v případě, že část plnění poskytuje prostřednictvím poddodavatele.
Žádná ze smluvních stran není odpovědná za škodu vzniklou porušením povinnosti ze Smlouvy, prokáže-li, že mu ve splnění takové povinnosti dočasně nebo trvale zabránila mimořádná nepředvídatelná a nepřekonatelná překážka vzniklá nezávisle na jeho vůli. Překážka vzniklá ze škůdcových osobních poměrů nebo vzniklá až v době, kdy byl škůdce s plněním smluvené povinnosti v prodlení, ani překážka, kterou byl škůdce podle smluvené povinnosti povinen překonat, ho však povinnosti k náhradě nezprostí. Smluvní strany se zavazují upozornit druhou smluvní stranu bez zbytečného odkladu na vzniklé překážky bránící řádnému plnění Smlouvy a dále se zavazují k vyvinutí maximálního úsilí k jejich odvrácení a překonání.
Poskytovatel se zavazuje udržovat v platnosti a účinnosti po celou dobu účinnosti Xxxxxxx pojistnou smlouvu, jejímž předmětem je pojištění odpovědnosti za škodu způsobenou Poskytovatelem třetí osobě s limitem pojistného plnění vyplývající z pojistné smlouvy, který nesmí být nižší než 1 000 000,- Kč (slovy: jeden milion korun českých). V případě, že při činnosti prováděné Poskytovatelem dojde ke způsobení škody Objednateli nebo třetím osobám, která nebude kryta pojištěním sjednaným ve smyslu tohoto odstavce Smlouvy, bude Poskytovatel povinen tyto škody uhradit z vlastních prostředků.
Poskytovatel přebírá závazek a odpovědnost za vady plnění Expertních služeb (vady zjevné, skryté i právní), jež bude takové plnění či jeho část mít v době předání a převzetí Objednateli – zjevné vady je Objednatel povinen vytknout při převzetí plnění, vady skryté je Objednatel povinen vytknout bez zbytečného odkladu po jejich zjištění a dále v rozsahu uvedeném v čl. 9 odst. 9.5 Smlouvy i za vady, které se na plnění dle Xxxxxxx (či jeho dílčí části) vyskytnou v průběhu záruční doby.
Poskytovatel, tam kde je to relevantní vzhledem k povaze plnění předmětu Smlouvy, poskytuje Objednateli záruku za jakost plnění předmětu Smlouvy ve smyslu ust. § 2113 OZ v délce 48 měsíců, která začíná plynout od akceptace takového plnění Objednatelem. Záruční doba se prodlužuje o dobu, která uplyne od písemného uplatnění řádné reklamace do doby odstranění reklamovaných vad či nedodělků. Případné vady či nedodělky plnění Poskytovatel na své náklady řádně odstraní, případně nahradí plněním bezvadným a to tak, že pokud se smluvní strany nedohodnou v konkrétním případě na jiném termínu odstranění vad či nedodělků, je Poskytovatel povinen případné vady či nedodělky odstranit nejpozději do 5 pracovních dnů od jejich oznámení ze strany Objednatele.
V případě prodlení Objednatele s plněním peněžitého závazku uhradí Objednatel na výzvu Poskytovatele úrok z prodlení ve výši 0,05 % z dlužné fakturační částky za každý
i započatý den prodlení po době splatnosti daňového dokladu.V případě prodlení Poskytovatele týkajícího se předání dílčích plnění (tj. uceleného rozsahu Expertních služeb vymezených v příloze č. 2 Smlouvy a vztažených k Platebnímu milníku) v termínu uvedeném v těchto přílohách jako Termín ukončení prací, uhradí Poskytovatel Objednateli smluvní pokutu ve výši 0,05 % z ceny včas nedodaného dílčího plnění, a to za každý i započatý den prodlení, maximálně však do výše ceny včas nedodaného plnění. K předání plnění musí dojít v souladu s čl. 7 Smlouvy.
V případě prodlení Poskytovatele s odstraněním vad či nedodělků v rámci předání a převzetí ve lhůtách dle čl. 7 odst. 7.2 bodu 7.2.3 Smlouvy uhradí Poskytovatel Objednateli smluvní pokutu ve výši 5.000 Kč (slovy: pět tisíc korun českých) za každý i započatý den prodlení a jednotlivý případ.
V případě prodlení Poskytovatele s odstraněním záručních vad či nedodělků ve lhůtách dle Smlouvy uhradí Poskytovatel Objednateli smluvní pokutu ve výši 5.000 Kč (slovy: pět tisíc korun českých) za každý i započatý den prodlení a jednotlivý případ.
Ustanovením o smluvní pokutě není, jakkoliv, dotčeno či omezeno právo na náhradu škody, oprávněná smluvní strana je oprávněna uplatnit nárok na náhradu škody vedle smluvní pokuty v plné výši. O náhradě škody platí dále obecná ustanovení OZ.
Jakákoliv ustanovení týkající se dotčení či omezení výše či druhu škody jsou neúčinná.
Práva duševního vlastnictví
Pokud je výsledkem činnosti Poskytovatele podle Xxxxxxx plnění, které naplňuje znaky díla ve smyslu AZ, poskytuje Poskytovatel Objednateli a Objednatel od Poskytovatele získává veškerá práva související s ochranou duševního vlastnictví vztahující se k takovému dílu, a to v rozsahu nezbytném pro řádné užívání takového díla Objednatelem po celou dobu trvání příslušných autorských práv. Objednatel zejména nabývá od Poskytovatele dnem poskytnutí autorského díla Objednateli (nejpozději však ke dni podpisu protokolu o předání a převzetí Expertních služeb dle Xxxxxxx, jichž je takové autorské dílo součástí) veškerá majetková práva, a to formou následujícího licenčního ujednání.
Poskytovatel poskytuje licenci jako:
licenci k veškerým známým způsobům užití autorského díla jako celku, a to alespoň v rozsahu nezbytném pro řádné užívání Expertních služeb Objednatelem;
nevýhradní licenci k těm částem autorského díla, u nichž je Xxxxxxxxxxxx sám autorem či vykonavatelem autorských práv k dílu zaměstnaneckému;
licenci neomezenou územním či množstevním rozsahem a rovněž tak neomezenou způsobem nebo rozsahem užití;
licenci na dobu určitou, a to po celou dobu trvání majetkových práv autorských k dílu;
licenci neodvolatelnou;
licenci, kterou není Objednatel povinen využít, a to ani zčásti;
licence je udělena s právem udělení podlicence či postoupení licence jakékoliv Objednatelem ovládané společnosti;
licenci, která umožňuje Objednateli užívání autorského díla všemi známými způsoby užití pro vnitřní potřebu bez omezení.
Poskytovatel rovněž uděluje Objednateli oprávnění dílo dle čl. 10 odst. 10.1 Smlouvy bez omezení zveřejnit, upravovat, zpracovávat, překládat, či měnit jeho název, a že je též oprávněn takové dílo spojit s dílem jiným a zařadit jej do díla souborného. Oprávnění dle tohoto odstavce Xxxxxxx se rovněž vztahuje na třetí osobu, kterou Objednatel určí k realizaci oprávnění zde uvedených, a to pro Objednatelovu interní potřebu.
Smluvní strany se výslovně dohodly, že odměna za veškerá oprávnění poskytnutá Objednateli dle tohoto článku Smlouvy je již zahrnuta v ceně dle čl. 4 Smlouvy, zejména odměna za poskytnutí licence a za udělení oprávnění ve smyslu předchozích odstavců.
Objednatel je oprávněn pořizovat pro vlastní potřebu rozmnoženiny veškeré dokumentace předané Poskytovatelem v listinné i elektronické podobě a používat text veškerých dokumentací předaných Poskytovatelem pro přípravu dalších technických dokumentací a uživatelských příruček.
Poskytovatel je povinen zajistit, aby výsledkem jeho plnění nebo jakékoliv jeho části nebyla porušena práva třetích osob. Pro případ, že užíváním předmětu plnění nebo jeho dílčí části nebo prostou existencí předmětu plnění nebo jeho dílčí části budou v důsledku porušení povinností Poskytovatele dotčena práva třetích osob, nese Poskytovatel vedle odpovědnosti za takovéto vady plnění i odpovědnost za veškeré škody, které tím Objednateli vzniknou.
Poskytovatel je povinen zajistit pro Objednatele licence k autorským dílům svým i třetích osob. Náklady na tyto licence jsou součástí ceny Expertních služeb dle Smlouvy.
Povinnost týkající se licence a jejího rozsahu dle tohoto článku Smlouvy platí pro Poskytovatele i v případě zhotovení části autorského díla dle čl. 10 odst. 10.1 Smlouvy poddodavatelem. Poskytovatel podpisem Smlouvy prohlašuje, že vlastní veškerá oprávnění k autorskému dílu dle předchozího odstavce Smlouvy, zejména, že získal veškerá oprávnění autorů či třetích osob k takovému dílu a je oprávněn je poskytnout Objednateli.
Poskytovatel je povinen poskytnout Objednateli licenci nebo podlicenci bez právních vad. Licence nebo podlicence poskytnutá Objednateli Poskytovatelem má právní vady zejména tehdy, pokud vyjde najevo, že Poskytovatel nebyl oprávněn poskytnout licenci či podlicenci ve výše uvedeném rozsahu, případně pokud poskytnutá licence či podlicence bude úspěšně zpochybněna jakoukoliv třetí osobou nebo v případě, že ve smyslu ust. § 2360 odst. 2 OZ v rozporu se Smlouvou ani nevznikla.
Poskytovatel je povinen Objednateli uhradit jakékoli majetkové škody a nemajetkové újmy vzniklé v důsledku toho, že Objednatel nemohl předmět plnění Smlouvy užívat řádně a nerušeně dle Smlouvy. Jestliže Poskytovatel poruší jakoukoliv povinnost stanovenou v tomto článku Smlouvy nebo se ukáže jakékoliv jeho prohlášení uvedené v tomto článku Smlouvy jako nepravdivé, neúplné nebo zavádějící, jedná se o podstatné porušení Smlouvy. Současně má Objednatel v takovém případě oprávnění požadovat po Poskytovateli uhrazení smluvní pokuty ve výši 500.000,- Kč (slovy: pět set tisíc korun českých) za každý jednotlivý případ takového porušení Smlouvy. Zaplacením smluvní pokuty není dotčeno, ani omezeno právo Objednatele na náhradu škody, kterou lze vymáhat vedle smluvní pokuty v plné výši.
Další a závěrečná ustanovení
Poskytovatel se zavazuje plnění předmětu Smlouvy provést sám, nebo s využitím poddodavatelů, uvedených spolu s rozsahem jejich plnění v nabídce Poskytovatele na realizaci Veřejné zakázky. Poskytovatel je povinen písemně informovat Objednatele o všech svých poddodavatelích (včetně jejich identifikačních a kontaktních údajů a o tom, které služby pro něj v rámci předmětu plnění každý z poddodavatelů poskytuje) a o jejich změně, a to nejpozději do 10 pracovních dnů ode dne, kdy Poskytovatel vstoupil s poddodavatelem ve smluvní vztah či ode dne, kdy nastala změna, avšak nejpozději před zahájením plnění poddodavatelem.
Byl-li k prokázání kvalifikace ve výběrovém řízení Veřejné zakázky užit poddodavatel, případně byla-li podána společná nabídka, je Poskytovatel oprávněn takového (pod)dodavatele nahradit pouze ze závažných objektivních důvodů, a to při splnění těchto podmínek:
nový (pod)dodavatel disponuje minimálně stejnou kvalifikací, kterou prokázal nahrazovaný (pod)dodavatel za Poskytovatele;
Objednatel s nahrazením (pod)dodavatele vysloví předchozí souhlas v písemné formě;
Poskytovatel se zavazuje zachovávat po celou dobu plnění předmětu Smlouvy profesionální složení realizačního týmu v souladu s požadavky stanovenými v zadávací dokumentaci veřejné zakázky;
Poskytovatel se zavazuje zabezpečovat plnění předmětu Smlouvy prostřednictvím osob, jejichž prostřednictvím prokázal v rámci výběrovéhoho řízení na Veřejnou zakázku splnění kvalifikačních požadavků (profesní a technické kvalifikační předpoklady). V případě změny těchto osob (členů realizačního týmu) je Poskytovatel povinen vyžádat si předchozí písemný souhlas Objednatele; tento souhlas je oprávněna vydat odpovědná osoba Objednatele. Nová osoba Poskytovatele musí splňovat příslušné požadavky na kvalifikaci stanovené v zadávací dokumentaci Xxxxxxx zakázky, což je Poskytovatel povinen Objednateli doložit odpovídajícími dokumenty;
Objednatel si vyhrazuje právo na odmítnutí nebo akceptaci změn ve složení realizačního týmu v době plnění Smlouvy. Současně si Objednatel vyhrazuje právo požádat o výměnu člena realizačního týmu pro opakovanou nespokojenost s kvalitou jím odváděné práce nebo pro nedostatečnou komunikaci s Objednatelem. Veškeré případné náklady související s výměnou člena realizačního týmu nese výlučně Poskytovatel.
Zadání provedení části plnění dle Smlouvy poddodavateli Poskytovatele nezbavuje Poskytovatele jeho výlučné odpovědnosti za řádné provedení takového plnění vůči Objednateli. Poskytovatel odpovídá Objednateli za plnění předmětu Smlouvy, které svěřil poddodavateli, ve stejném rozsahu, jako by jej poskytoval sám.
Tato Xxxxxxx nabývá platnosti dnem jejího podpisu oběma smluvními stranami a účinnosti uveřejněním prostřednictvím registru smluv ve smyslu zákona č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv (zákon o registru smluv), ve znění pozdějších předpisů (dále jen „ZoRS“). Podle XxXX bude tato Smlouva Objednatelem zveřejněna v registru smluv. Smlouva se uzavírá na dobu určitou, v trvání čtyř let ode dne předání a převzetí implementovaného SD a CMDB (ode dne produktivního provozu SD a CMDB).
Smlouva představuje úplnou dohodu smluvních stran o předmětu Smlouvy a všech náležitostech, které smluvní strany měly a chtěly ve Smlouvě ujednat, a které považují za důležité pro závaznost Smlouvy. Smlouvu lze měnit či doplňovat pouze písemnými dodatky odsouhlasenými oběma smluvními stranami.
Smluvní strany se podpisem Smlouvy dohodly, že vylučují aplikaci ustanovení § 557 OZ.
Smluvní strany si nepřejí, aby nad rámec výslovných ustanovení Smlouvy byla jakákoliv práva a povinnosti dovozovány z dosavadní či budoucí praxe zavedené mezi smluvními stranami či zvyklostí zachovávaných obecně či v odvětví týkajícím se předmětu plnění Smlouvy, ledaže je ve Smlouvě výslovně sjednáno jinak. Vedle shora uvedeného si smluvní strany potvrzují, že si nejsou vědomy žádných dosud mezi nimi zavedených obchodních zvyklostí či praxe.
Pro vyloučení pochybností Poskytovatel výslovně potvrzuje, že je podnikatelem, uzavírá Xxxxxxx při svém podnikání, a na Smlouvu se tudíž neuplatní ustanovení § 1793 OZ.
Poskytovatel na sebe v souladu s ustanovením § 1765 odst. 2 OZ přebírá nebezpečí změny okolností. Tímto však nejsou nikterak dotčena práva smluvních stran upravená ve Smlouvě.
Je-li nebo stane-li se jakékoli ustanovení Smlouvy neplatným, nezákonným nebo nevynutitelným, netýká se tato neplatnost a nevynutitelnost zbývajících ustanovení Smlouvy. Smluvní strany se tímto zavazují nahradit do 5 pracovních dnů po doručení výzvy druhé smluvní strany jakékoli takové neplatné, nezákonné nebo nevynutitelné ustanovení ustanovením, které je platné, zákonné a vynutitelné a má stejný nebo alespoň podobný obchodní a právní význam.
Objednatel je oprávněn od Smlouvy písemně odstoupit z důvodu jejího podstatného porušení Poskytovatelem, přičemž za podstatné porušení Smlouvy se bude považovat prodlení Poskytovatele s poskytováním Expertních služeb (či jejich dílčí části) v termínech stanovených Smlouvou delším než 20 dnů.
Možnost odstoupení smluvních stran od Xxxxxxx se dále řídí příslušnými ustanoveními OZ. Odstoupení od Smlouvy je platné dnem doručení oznámení o odstoupení druhé smluvní straně.
Smlouvu lze ukončit písemnou výpovědí bez uvedení důvodů. V takovém případě činí výpovědní lhůta 3 měsíce a běží od prvého dne měsíce následujícího po doručení písemné výpovědi druhé smluvní straně.
Poskytovatel je oprávněn vstupovat do objektů Objednatele v souvislosti s plněním Smlouvy jen se souhlasem nebo v přítomnosti oprávněné osoby Objednatele.
Záležitosti ve Xxxxxxx výslovně neupravené se řídí příslušnými ustanoveními OZ a příslušnými právními předpisy souvisejícími. Veškeré případné spory ze Smlouvy budou v prvé řadě řešeny smírem (tento postup se nevztahuje na vymáhání finančních pohledávek vzniklých z porušení povinnosti zaplatit pohledávku). Pokud smíru nebude dosaženo během 30 dnů, všechny spory ze Smlouvy a v souvislosti s ní budou řešeny věcně a místně příslušným soudem v České republice.
Smluvní strany se zavazují vzájemně informovat o všech organizačních změnách (název, sídlo, tel., fax., apod.).
Smluvní strany jsou povinny zachovat mlčenlivost o všech skutečnostech, údajích a informacích, týkajících se druhé smluvní strany, které mají povahu jejich obchodního tajemství v rozsahu a za podmínek § 504 OZ, a o kterých se dozví v souvislosti s plněním Smlouvy. Poskytovatel i Objednatel se zavazují, že tyto skutečnosti nesdělí, ani jiným způsobem neposkytnou, žádné třetí osobě a zajistí jejich přiměřenou ochranu a utajení.
Poskytovatel je dle zákona č. 110/2019 Sb., o zpracování osobních údajů, v platném znění, a dle Nařízení Evropského Parlamentu a Rady (EU) 2016/679, o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů, povinen zachovávat mlčenlivost o osobních údajích a o bezpečnostních opatřeních, jejichž zveřejnění by ohrozilo zabezpečení osobních údajů v informačním systému Objednatele. Povinnost mlčenlivosti trvá i po ukončení účinnosti Smlouvy. Poskytovatel odpovídá Objednateli v plné míře za škodu, kterou mu způsobí porušením tohoto ustanovení.
Objednatel je při nakládání s veřejnými prostředky povinen dodržovat ustanovení zákona č. 106/1999 Sb., o svobodném přístupu k informacím, ve znění pozdějších předpisů.
Smlouva je vyhotovena ve čtyřech vyhotoveních, z nichž dvě vyhotovení obdrží Objednatel a dvě vyhotovení obdrží Poskytovatel.
Nedílnou součástí Smlouvy jsou následující přílohy:
Příloha č. 1 Specifikace Expertních služeb
Příloha č. 2 Harmonogram plnění a platební milníky
Příloha č. 3 Vzor Akceptačního protokolu
Smluvní strany shodně prohlašují, že se seznámily s obsahem Smlouvy, který je dostatečně určitý a srozumitelný, a že se Smlouvou souhlasí v plném rozsahu. Smluvní strany uzavírají Xxxxxxx na základě vážné a svobodné vůle prosté omylu a na důkaz toho připojují své vlastnoruční podpisy.
Doložka:
Smlouva byla schválena Radou města Brna na schůzi R8/ dne .
V Brně dne ________ V ________ dne ________
Za Objednatele: Za Poskytovatele:
_______________________________ _________________________________
za Statutární město Brno za [doplní Poskytovatel]
Xxx. Xxxxx Xxxxxx
vedoucí OMI MMB
Příloha č.1
Specifikace Expertních služeb
Poskytovatel bude poskytovat pro Objednatele následující Expertní služby zahrnující následující dílčí plnění uvedené ve výzvě k podání nabídek v Příloze č. 1 – Technické zadání:
Část A Service desk
Systém Service desk (dále též jako „SD“) je obecné softwarové řešení pro implementaci systému řízení, kontroly, popisu, standardizace, formalizace a automatizace procesů, sledování identifikátorů výkonnosti (KPI), monitorování s kontrolou stavu procesů a určení odpovědnosti v konkrétních krocích.
Systém SD musí podporovat užití principiálně libovolných datových struktur, přičemž nad těmito strukturami lze provádět libovolné operace, definovat libovolné procesy, sledovat a vyhodnocovat vývoj všech konfiguračních položek (aktiv) a tiketů v čase.
Systém SD musí obsahovat nástroje a funkcionality umožňující obecnou definici procesů, datových tříd, činností a úkolů, tiketů a obecnou definici vzájemných vazeb mezi všemi těmito entitami. Současně SD obsahuje temporální databázi, ve které jsou trvale evidovány všechny změny provedené v čase nad libovolnou datovou položkou. Na stav této datové položky lze nahlížet v konkrétním čase.
Systém SD musí obsahovat též nástroje pro nastavení procesů, pracovních postupů (definice rolí, stavů a vazeb mezi nimi) a funkcionalit pro jejich následné vykonávání v elektronickém prostředí.
Uživatelská rozhraní
Je vyžadována:
plná podpora různých typů rozhraní definovaných zejména dle typu přihlášeného uživatele a jeho role v systému (možnost přepínání rolí i jednotlivých rozhraní),
implementace prostředí pro různá mobilní zařízení, včetně podpory více jazykových verzí, přičemž základním používaným jazykem je čeština.
V rámci přístupů jednotlivých typů uživatelů musí mít rozhraní definováno tyto úrovně:
zákaznické – rozhraní určené podporovaným uživatelům,
řešitelské – rozhraní, určené uživatelům podílejícím se na řešení případů,
administrátorské – rozhraní určené pro správu a konfiguraci systému SD, umožnit vytváření reportů pomocí reportovacího nástroje.
Podpora a přístup do rozhraní
Systém musí být koncipován pro přistup uživatelů přes "tenkého klienta" a musí podporovat všechny standardní webové prohlížeče (Microsoft Edge, Microsoft Internet Explorer, Chrome, Firefox, Safari a další). Je tedy možné k němu přistupovat z jakéhokoliv PC, NB i mobilního zařízení, připojeného do sítě (k internetu).
Typy rozhraní
Základní typy rozhraní:
Zákaznické rozhraní
Toto rozhraní musí uživatelům SD (bez předchozích zkušeností a pomocí jednoduchého a intuitivního interface) umožnit:
zakládat nové požadavky, vkládat k nim komentáře či přílohy,
jednoduchý přístup do svých aktuálně řešených tiketů, či do tiketů, které jsou již vyřešeny,
zobrazit pouze jím založené tikety,
zobrazit různá aktuální oznámení (např. o plánovaných výpadcích služby),
přístup k základním informacím jako jsou fronty tiketů, konfigurační položky,
základní kategorizaci, případně specifikovat požadavek popisem,
přístup ke katalogu materiálů a služeb.
Toto rozhraní je vytvořeno v českém jazyce.
Řešitelské rozhraní
Toto rozhraní musí být přizpůsobeno především pro efektivní práci s řešenými tikety. Každý řešitel musí mít k dispozici stromovou strukturu menu pro nejčastěji používané pohledy na data. Musí být umožněno přednastavit strukturu pro konkrétní role. Jednotlivé volby menu mají řešiteli umožnit standardní zobrazení:
seznamu a detailu tiketů aktuálně řešených,
seznamu a detailu tiketů s vyšším stupněm naléhavosti,
konfiguračních položek,
znalostních dokumentů
přehledu o řešených požadavcích a incidentech.
Dále musí umožňovat:
práci se znalostní bází, CMDB a ostatními komponentami
práci s reportovacími nástroji
Mobilní rozhraní
Mobilní rozhraní zajistí přístup k SD z mobilních chytrých zařízení uživatelů, kterým umožní:
zakládat nové tikety, podpora fulltextového vyhledávání a automatické nabízení relevantních kategorií,
provádět veškeré potřebné operace s tikety – např. editace, vložení komentáře a přílohy.
Toto rozhraní musí umožňovat implementaci i dalších funkčností, jako je:
doplnit automaticky do tiketu lokalitu daného uživatele pomocí GPS mobilního zařízení,
přímo z mobilní aplikace volat na číslo SD, pokud je v systému definováno,
možnost SMS notifikací.
E-mailové rozhraní
Tohoto rozhraní musí zajišťovat:
E-mail notifikace v rámci životního cyklu tiketů,
spojení s konkrétním tiketem.
Autentizace
Umožnit podporu těchto autentizačních metod:
vůči internímu seznamu účtů a hesel vedených v systému SD,
vůči Active directory,
vůči adresářové službě LDAP,
vůči MS Azure Active Directory.
vůči externímu autentizačnímu mechanismu (autentizační brána),
vícefaktorové ověření
Autorizace
Umožnit podporu úrovní přístupu na základě množiny přidělených autorizačních rolí.
Možnost stanovení:
přístupu konkrétních rolí k hierarchickým sekcím systému SD,
uživatelských rozhraní jednotlivým uživatelům (rolím),
přístupu rolí k seznamům, k detailům položek seznamů (nabídky, záložky),
přístupu rolí k formulářům, položkám formulářů (pole, nabídky, záložky),
práv rolí k záznamům (zakládání, archivace, modifikace, pouze pro čtení), omezení přístupu k datům - např. na základě lokality, organizace atp.
Podpora procesů obecně
Pro podporu obecných procesů musí systém obsahovat:
správu požadavků – tiketů,
správu katalogu služeb,
reportovací nástroje,
nástroj pro definici a řízení workflow,
portálové řešení pro zákazníky,
portálové řešení pro řešitele.
Systém musí být:
uživatelsky ovladatelným nástrojem umožňujícím v administrativním prostředí konfigurovat libovolná workflow zahrnující jak manuální kroky přidělované uživatelům (např. vyplnění formuláře, změna stavu), tak automatizované akce v systému SD, nebo v externích aplikacích (např. notifikace, zjištění údajů, aktualizace údajů),
společným reportovacím nástrojem umožňujícím definovat dashboardy, předdefinované reporty i analytické ad-hoc reporty.
Systémové konfigurace a číselníky
Systém musí umožnit definování a modifikování základních konfiguračních nastavení:
globální nastavení,
nastavení parametrů pro role a uživatele,
lokalizace,
nastavení menu a úvodních obrazovek,
notifikační kanály.
Konfigurační položky
Systém musí splňovat požadavky na definice Konfiguračních položek (dále jen „KP“) a to bez ohledu, zda se jedná o Místa, Lokality, Kontakty, Organizace, organizační složky atd.:
KP bude možno definovat v libovolné struktuře v požadovaném rozsahu,
všechny KP bude možno hierarchicky strukturovat, definovat závislosti, modelovat reporty,
umožňovat naplnění a synchronizaci hodnot KP z externích zdrojů (informace typu zaměstnanec, telefon, organizační složka apod.).
Systém bude obsahovat minimálně tyto KP:
Lokality (skupiny objektů) - název, popis, kontaktní osoba,
Objekty – popis objektů (adres), název, adresa, kontaktní osoba,
Obecné položky (stroje, přístroje, inventář…) – název, umístění (lokalita, objekt), kontaktní osoba, třída položky, výrobce, dodavatel, sériové/licenční číslo, inventární číslo, úroveň služby, další informace specifické pro danou třídu obecné položky,
Kontakty (uživatelů a kontaktní osoby u dodavatelů) - jméno, příjmení, telefon, mobilní telefon/pager, název uživatelského účtu pro autentizaci a autorizaci, e-mail, typ kontaktu (zákazník, řešitel, dodavatel), lokalita, organizace, skupina, způsob upozornění na události (e-mail, SMS, systémová zpráva, atd), úroveň služby (SLA), omezení působnosti (např. technika, řešitele apod.) na definované objekty správy,
Organizace (údaje o organizacích v interakci se systémem) - název, popis, IČO, kontaktní jméno, telefon, mobil, lokalita, nákladové středisko,
Dodavatelé – název dodavatele, typ dodavatele (poskytovatel služby, pronajímatel zařízení apod.), kontaktní jméno,
Servisní kontrakty - (podpora skupin více zákazníků, kterým mohou být služby SD poskytovány).
Správa požadavků obecně
Systém musí splňovat následující požadavky
podpora evidence požadavků (tiketů) v celém životním cyklu, a to včetně záznamu auditní stopy s blokací odstranění záznamu po akceptaci registrace tiketu,
životní cyklus tiketu je řízen uživatelsky modifikovatelným workflow, a to od založení, přes identifikaci zainteresovaných uživatelů, přidělování řešitelům a pracovním skupinám až po jednotlivé kroky řešení a akceptaci vyřešení požadavku uživatelem-zákazníkem,
definovat strukturu menu pro specifické role i pro jednotlivé uživatele
uživatelský monitoring stavu řešení v čase,
možnost prioritizace,
evidence historie aktivit,
možnost minimálně administrátorského (optimálně uživatelského) nastavení notifikací,
uživatelský reporting.
Pracovní příkazy, obchodní případy
Je požadována:
podpora generování pracovních příkazů nebo obchodních případů z jednoho či více požadavků (tiketů),
podpora automatického vzniku pracovních příkazů nebo obchodních případů, založených na definovaných podmínkách.
Vyhledávání
Systém musí obsahovat nástroj pro identifikaci hledaných klíčových slov či frází (fulltextové vyhledávání), a to skrz všechny tikety či konfigurační položky.
Uživatelské reporty
V oblasti reportingu umožnit následující funkcionality:
podpora nastavení práv rolí/uživatelů s právy definovat standardní reporty i případové (ad-hoc reporty) na vyžádání,
nástroje pro tvorbu reportů jsou provozovány v intuitivním prostředí, umožňující vytvářet definice reportů bez hlubších zkušeností s programováním, generovat a zasílat reporty automaticky, nebo v definovaných periodách.
Šablony
Zajistit podporu využití uživatelsky generovatelných a editovatelných šablon s možností defaultního nastavení hodnotami atributů specifickými pro určitý typ případu.
Přílohy
Zajistit podporu způsobu vedení elektronických příloh ve formě dokumentu uloženého ve specifikovaných úložištích, případně URL odkazu, a to s možnostmi stanovení maximální velikosti přikládaného souboru, stanovení maximálního počtu přikládaných souborů a s možností stanovení povolených typů souborů.
Katalog služeb/pořízení majetku nebo materiálu
Systém musí umožňovat vytvoření (migraci) editaci, a správu obecných katalogů minimálně v rozsahu:
Katalog služeb
Katalog pořízení majetku
Katalog materiálů
Katalog služeb, katalog pořízení majetku i katalog materiálů musí být koncipovány jako jednotná místa pro správu všech služeb a nákupů, které jsou poskytovány servisními odděleními napříč organizací (IT oddělení, personální oddělení, správa budov, správa vozového parku apod.). Cílem správy jednotlivých katalogů je zajistit, aby katalogy reflektovaly skutečný stav v organizaci a aby služby i nákupy byly dostupné těm uživatelům (žadatelům), kteří mají právo dané služby i nákupy využívat na základě přiděleného oprávnění.
Struktura katalogů
Katalogy mají být strukturovány logicky podle agend jednotlivých oddělení a odborů.
Správa katalogů
Veškerá administrace bude probíhat za pomoci administračních nástrojů. Bude též možnost přidávat do SD nové katalogy.
Reporting
Předdefinované reporty
Systém musí podporovat využití předdefinovaných reportů:
grafické reporty,
textové reporty,
analytické reporty.
Tyto reporty budou soustředěny v předdefinovaných sadách reportů.
Systém musí podporovat možnosti tvorby ad-hoc reportů za pomoci reportovacích nástrojů, přičemž musí disponovat nástroji pro customizaci reportů (pro hierarchické zobrazení konfiguračních položek v reportech), disponovat nástroji pro grafické zobrazení reportu a umožnit filtrování dat při tvorbě sestav.
Podpora procesů řízení IT služeb
V kapitole 3 jsou popsány specifické požadavky na systém pro podporu a řízení oblasti IT služeb:
Podpora procesů
správa servisních požadavků,
správa incidentů,
správa problémů,
řízení změn,
správa znalostní báze,
správa konfigurací (CMDB) – systém musí umožňovat případné propojení SD a CMDB,
správa katalogu služeb,
Service Level Management,
nástroje pro vzdálenou podporu koncových stanic,
reportovací nástroje,
nástroj pro definici a řízení workflow v grafickém administrativním prostředí,
portálové řešení pro koncové uživatele,
portálové řešení pro řešitele,
podpora ITIL procesů (ITIL V3 a novější).
Systém umožní:
na základě servisní politiky definovat, které požadavky na služby budou splněny v rámci daného konkrétního tiketového cyklu, a ty, které budou generovat následné procesy,
identifikovat problémy a příležitosti pro zlepšení, na jejichž základě dojde ke změnovému řízení a následné implementaci opatření, aby se dosáhlo optimálnějších měřitelných hodnot plnění služeb a využilo výhod automatizace.
Životní cyklus tiketů
Systém musí zajišťovat podporu tiketů ve všech stavech životního cyklu servisních požadavků a incidentů, definovaných procesem a implementovaných nastaveným workflow, a to zejména:
registrace případů,
identifikace ovlivněných uživatelů a kontaktů na ně,
identifikace konfigurace jejich IT prostředí (používaná zařízení, software, služby atd.),
sledováni stavu řešení,
přímý přístup do znalostní databáze
přidělování řešitelům a pracovním skupinám,
systém musí umožňovat vytváření řešitelských skupin uživatelů s různými rolemi (uživatelskými přístupy)
evidence historie aktivit a vytvářeni reportu,
řazení případu do příslušné fronty podle typu, priority, naléhavosti apod.,
upozornění pracovníků na významné aktivity při řešení problému (e-mail).
Kategorizace
Zajistit podporu kategorizace tiketů hierarchickým číselníkem tak, aby je na základě těchto kategorií bylo možné automatizovaně přiřazovat příslušnému řešiteli nebo řešitelské skupině dle různých kritérií, případně přiřadit odpovídající SLA.
Prioritizace
Uplatňovat prioritizaci dle kritérií, jako jsou:
naléhavost řešení,
priorita,
závažnost problému,
dopad na celkové množství práce.
Správa incidentů
Systém musí obsahovat nástroj pro správu incidentů podle ITIL. Tímto budou zajištěny:
standardizované metody a procedury k efektivní a rychlé odpovědi, analýze, dokumentaci, průběžné správě incidentů a k informování o nich,
viditelnost a komunikace incidentů pro zákazníky a zaměstnance podpory,
informování zákazníka o nastalých incidentech a jejich řešení.
Systém musí umožňovat podporu způsobů evidence a řízení životního cyklu standardních změn, zejména:
registrace požadavků na provedení změny,
přímý přístup do znalostní databáze
generování pracovních příkazů a individuálních úkolů k zajištění požadavku,
monitorování a řízení sledu prací,
tvorbu příslušných šablon pro požadavky na změny,
přidělování požadavků i pracovních příkazů příslušným pracovníkům,
upozornění pracovníků na významné aktivity (notifikační e-mail).
Stav řešení požadavku
Systém musí zajišťovat podporu požadavků na změnu ve všech stavech životního cyklu.
Kategorie změn
Systém musí obsahovat podporu kategorizace změn hierarchickým číselníkem tak, aby na základě těchto kategorií bylo možné podle předdefinovaných údajů automatizovaně přiřazovat workflow pracovních příkazů, spolu s příslušnými řešiteli nebo řešitelskými skupinami a příslušná SLA na změnu jednak jako celek i na jednotlivé pracovní příkazy.
Další úkony spojené s řešením změny
Umožnit podporu dalších úkonů řešitele spojených s řešením, jako jsou:
zpětný kontakt koncového uživatele,
hledání v dokumentaci,
záznam komentáře,
převedení problému na jiného řešitele nebo skupinu,
manuální upozornění,
eskalace (zvýšení priority),
připojení požadavku na změnu,
připojení události pro účely monitorování požadavku,
změna atributu stav.
Veškeré úkony, spojené s řešením budou de-facto dané funkčním zadáním, definicí procesu a bude je možno kdykoliv dle požadavku modifikovat. To se bude týkat zejména notifikací a eskalací, monitorování či změny stavů.
Pracovní příkazy
Zajistit podporu pracovních příkazů tvořících workflow potřebné pro zavedení příslušné kategorie:
označení a popis příkazu,
pořadí ve workflow pro danou kategorii změn,
řešitel úkolu nebo řešitelská skupina,
stavy postupu plnění pracovního příkazu,
akce spojené se změnou stavu (např. upozornění uživatele na neschváleni změny).
Konfigurační položky
Zajistit podporu způsobu výběru položek ovlivněných změnou z konfigurační databáze.
Typ úrovně služby
Zajistit podporu přidělování SLA na základě:
konfigurační položky,
žadatele,
organizace žadatele,
kategorie,
priority,
řešitelské skupiny,
možnost ad-hoc definice SLA pro konkrétní tiket.
Hierarchie požadavků
Zajistit podporu potřebných hierarchií více změn.
Šablony
Zajistit podporu využiti formulářů s přednastavenými (automaticky vyplněnými) hodnotami atributů specificky shodnými pro určit typ změny.
Notifikační metody
Zajistit podporu notifikací pro významné události v životním cyklu řešení tiketů:
identifikaci případu,
charakteristiku události,
kontaktní informace,
další specifické informace (např. události SLA, změny stavu tiketu, změna v konkrétním poli).
Zajistit podporu využiti standardních notifikačních metod:
systémová zpráva v SD,
e-mail,
SMS.
Systém umožní nadefinovat pro notifikace podrobná pravidla s různými podmínkami a seznamy uživatelů, kterým bude zpráva zaslána. V přehledném grafickém editoru bude možno vytvářet šablony zpráv pro notifikace v HTML formátu.
Dále musí podporovat:
časově podmíněné akce, upozornění, urgence, eskalace aj.,
akce podmíněné daty (aktuálními, historickými, odvozenými / transformovanými).
Události
Umožnit podporu automatického vzniku událostí, založených na definovaných podmínkách na základě získaných dat tiketů (aktuálních, historických, odvozených či transformovaných) či vzniku událostí definovaných časovými podmínkami, jako jsou:
podmínky – specifikované hodnoty atributů tiketu,
automatické akce (např. změna stavu, odeslání notifikace, spuštění externí integrace).
Typ úrovně služby
Bude zajištěna podpora garantovaných parametrů služby (SLA), které mohou být smluvně uzavřeny:
mezi dodavateli a poskytovatelem služeb – včetně služeb poskytovaných formou outsourcingu,
mezi poskytovatelem služby a zákazníky.
Podpora eskalačních procedur:
automatické identifikace úrovně služby žádané pro danou kategorii případu,
včasného varováni při blížícím se porušeni SLA,
identifikace porušení SLA,
vytváření reportů o dodržováni a porušování SLA.
Podpora kalendářů požadované doby provozu a podpory určující:
dny v týdnu,
rozsah kalendářních dat,
denní dobu,
kdy může k dané události dojít, či kdy je příslušné SLA v platnosti.
Evidence servisních kontraktů
Systém musí obsahovat evidenci servisních kontraktů svázaných s konkrétními dodavateli servisních služeb a smlouvami, kterými bude zajištěno poskytování servisních služeb. Servisní kontrakt bude evidovat:
kontakt s tímto dodavatelem,
metadata dodavatele,
smlouva,
definici SLA dle smlouvy,
servisní kategorie,
příslušné konfigurační položky a jiné.
Znalostní báze
SD bude zajišťovat znalostní bázi založenou na vyhledávání pomocí nástroje pro identifikaci hledaných klíčových slov či frází.
Bude zajištěna podpora ukládání zvolených tiketů, a tím tvořena vědomostní báze s možností schvalování, publikování, revize a aktualizace či časové expirace údajů dle předem definovaného procesu. V rámci kteréhokoliv dokončeného tiketu bude možno určit, zda bude zařazen do uvedené znalostní databáze či nikoliv.
Lze nastavit, že proces revizí a aktualizací může být systémem automaticky kontrolován dle definovaného plánu a může upozorňovat garanta/správce formou notifikací na nutnost zásahu (např. provést revize).
Uživatelské reporty
Bude zajištěna podpora nastavení práv rolí/uživatelů s právy definovat standardní reporty i případové (ad-hoc reporty) na vyžádání.
Možnosti pro budoucí tvorbu reportů:
spouštět základní reporty přímo ve formulářovém zobrazení, tj. online pohledy na aktuální data, např.: aktuálně registrované tikety, tikety, u kterých hrozí porušení SLA nebo počty požadavků přidělených na specifické řešitelské skupiny,
jednoduché ad hoc pohledy pomocí funkce vyhledávání s použitím konkrétních filtrů,
možnost exportovat výsledek vyhledávání pomocí tlačítka do Excelu.
použití reportovacího nástroje, který bude umožňovat přistupovat k reportům přímo z prostředí SD
z hlediska přístupu k datům bude možno nastavit stejná omezení, jaká mají uživatelé v SD
vytvořený report bude možno exportovat do PDF, nebo excelovských tabulek a následně odeslat na email. Standardní tabulkové sestavy a formuláře bude možno doplnit o detailně definovatelné grafy, jejichž vzhled bude možno vybrat z předdefinovaných šablon. Bude možno vytvářet periodické reporty, které budou automaticky generovány, převedeny do PDF a zaslány na vybrané emailové adresy
všechny reporty bude možno exportovat do dalších formátů (CSV / Excel / HTML / PDF / DOCX a další).
průvodce pro tvorbu reportů bude poskytovat dostatečně intuitivní prostředí pro jejich definici, a to i bez hlubších zkušeností s programováním. Případné generování a zasílání reportů bude možno provádět automaticky i v definovaných periodách.
Administrace systému SD a operace s daty
Většina úkonů pro administraci a konfiguraci systému SD bude prováděna pomocí přehledného administrátorského rozhraní, které bude přístupné stejně jako řešitelské či zákaznické rozhraní pomocí podporovaných internetových prohlížečů.
SD bude možno plně administrovat odkudkoliv (dle příslušných přístupových práv). Pomocí exportních a importních nástrojů a strukturovaných textových souborů bude možno jednoduše a bezpečně provádět migraci dat z/do systému. V této oblasti bude možno využit rozhraní webových služeb. Tyto nástroje budou použity při implementaci a plnění systému SD a CMDB aktuálními daty.
SD bude umožňovat provádění jednorázových nebo pravidelných archivací starých záznamů ve formě strukturovaných textových souborů, které bude možno v případě potřeby jednoduše importovat zpět. Tímto způsobem bude možno archivovat např. historické tikety nebo obsáhlé tabulky obsahující záznamy o přihlášení a odhlášení uživatelů apod. V administrátorském rozhraní bude možno měnit schéma objektů systému SD - např. přidání nových polí nebo tabulek. Po takové změně budou automaticky provedeny úpravy v databázi. Na úrovni objektů bude možno také definovat speciální obslužné procedury.
SD bude umožňovat přehlednou správu jednotlivých formulářů a obrazovek, definování jejich vzhledu a obsahu. Pro tyto úpravy bude použito rozhraní, které nevyžaduje znalosti programování. V systému SD bude možno upravovat formuláře i přímo pomocí libovolného textového editoru. Upravené formuláře bude možno v systému SD otestovat na produkčních datech, aniž by bylo potřeba jejich nasazení do produkčního provozu. SD bude umožňovat jednoduchou lokalizaci obsahu všech formulářů i systémových hlášení, a to až do úrovně obsahu logů.
Integrace externích systémů
Systém musí obsahovat nástroje a funkcionality pro interakci systému SD s okolím, tedy datové provázání s programy a aplikacemi třetích stran, operace s tikety, správu CMDB a další operace v systému bude tedy možno případně provádět, aktivovat a řídit i vnějšími podněty.
Bude zajištěna podpora pro množství integračních nástrojů a konektorů, umožněny automatické (i periodicky se opakující) komunikace s externími systémy (např. formou datového podkladu či prostřednictvím webových služeb).
Umožnit integrace s jakýmkoli systémem třetí strany, který má standardizované API (Oracle databáze, MSSQL databáze, Active Directory & LDAP, ServiceNow, VMware a další).
Realizace integrací na konkrétní systémy třetích stran se předpokládá pro 3 subjekty.
Speciální úpravy, provoz systému SD
V SD je nutno rovněž provést implementaci speciálních úprav. Jedná se především o tyto úpravy.
upravené zákaznické rozhraní v češtině,
přihlášení do systému z interních a externích lokalit,
upravená notifikační pravidla,
v kategorizaci tiketů lze aktivovat speciální možnost přiřazení požadavku příslušnému řešiteli ve skupině dle kritéria popořádku v pořadí dle členů ve skupině,
záznam pracnosti pro požadavek,
nastaveni pravidel SLA, úprava pro sběr dat do znalostní databáze a vyhledávací pole pro hledání v logu požadavků,
integrace se systémy třetích stran, viz kap. Integrace externích systémů,
speciální filtry na zobrazování požadavku pomoci vytvořených uložených dotazů,
reporty pro výpisy požadavků, např. k auditu ISO,
modul Úklid budov,
použití předdefinovaných textů.
SD bude provozován ve dvou instancích (testovací a produkční). Během implementace SD bude řešena migrace dat otevřených tiketů, znalostní databáze a nastavení systémové konfigurace a číselníků.
Nefunkční požadavky
Spolehlivost a podpora provozu
Je třeba zajistit:
průběžnou údržbu a zaručení dalšího rozvoje dle životního cyklu vývoje a doporučení dodavatele,
podporu provozu 24/7/365 mimo běžnou pracovní dobu (Po – Pá 17:00 – 7:00; So, Ne), s časem odezvy na provozní incident/nedostupnost SD do následujícího pracovního dne, začátku pracovní doby,
zvýšenou podporu provozu 24/7/365 v průběhu pracovní doby (Po – Pá 7:00 – 17:00) s časem odezvy na provozní incident/nedostupnost do 4 hodin.
Bezpečnost
Je třeba zajistit:
podporu přístupových práv autentizovaných uživatelů systému SD k jednotlivým objektům a komponentám systému pomoci autorizačních rolí,
podporu šifrování, anonymizace a pseudoanonymizace dat, autentizace, autorizace, bezpečnostní model a řízení přístupů na základě rolí,
prostředky pro podporu bezpečnostních funkcí,
plnou podporu přístupových práv, založených na autentizaci uživatele. Dle definovaných rolí uživatelů (či konkrétních uživatelů), jsou pak řízena privilegia pro povolení (či naopak odebrání) přístupu k funkcionalitám systému, a to v různých úrovních (modifikované volby nabídek, úroveň přístupu k datům, přístup k reportům atd.),
aby každá role v systému mohla mít jinou sadu formulářů, obsah nápovědy apod. Každý uživatel může mít přiděleno více rolí a má mít možnost mezi nimi jednoduše přepínat bez nutnosti odhlašování, aby se role a jejich oprávnění mohly konfigurovat, případně výčet rolí a oprávnění rozšiřovat (v uživatelském režimu s příslušnými právy).
Část B Konfigurační databáze
Konfigurační databáze bude sloužit jako centrální úložiště dat a metadat, popisujících veškerá aktiva související s IT prostředím Magistrátu města Brna (dále jen „MMB“), jeho řízením a správou. Struktura těchto dat bude poplatná Enterprise Architektuře MMB a procesním potřebám MMB – aktuálně v rozsahu korespondujícím s požadavky ITIL a ISMS, potenciálně zákonem č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti), ve znění pozdějších předpisů a případným dalším, vycházejícím z platné legislativy nebo budoucích potřeb zákazníka.
Základní funkční požadavky
Z pohledu dat musí řešení:
umožňovat ukládání a manipulování s daty strukturovanými dle definovaného logického datového modelu, který bude možno postupem času doplňovat a rozšiřovat,
umožňovat definici libovolného typu a počtu konfiguračních položek a jejich atributů,
umožňovat definici libovolného typu a počtu vazeb mezi konfiguračními položkami,
podporovat standardní datové typy pro ukládání a práci s čísly, řetězci, textem, výčtovými typy a obecnými binárními daty (mj. i pro potřeby evidence smluv a servisních kontraktů, manuálů, směrnic, operačních procedur aj.),
podporovat temporální způsob práce s daty, minimálně v rozsahu "ukládání stavu aktiva v čase" a "dotazování se na stav aktiva pro definované časové období", s transakčním logováním, zajištěním auditní stopy a nepopiratelnosti,
umožňovat definici rolí a řídit přístup k datům (konfiguračním položkám, jejich atributům, vazbám aj.) na základě těchto rolí (RBAC),
umožňovat evidenci osob, jim příslušných rolí a vazeb k aktivům v závislosti na logickém datovém modelu formou atributů i vazeb.
Z pohledu reportů a sestav musí řešení:
umožňovat strukturované vyhledávání konfiguračních položek dle zadaných atributových a vazebních podmínek,
umožňovat fulltextové vyhledávání v textových datech,
umožňovat generování hierarchických reportů a pohledů dle typů konfiguračních položek, jejich atributů a vazeb (například typu "fyzický pohled na infrastrukturu", "logický pohled na infrastrukturu", "pohled na infrastrukturu z pohledu řízení služeb", "pohled na infrastrukturu z pohledu servisních smluv" atp.),
umožňovat definování struktury a obsahu těchto reportů,
mít možnost plánování úloh a dávkového zpracování (například periodické generování reportů a jejich rozesílání definovaným osobám atp.),
umožňovat definici výstupního formátu pro potřeby interaktivního (typicky HTML, PDF aj.) i strojového zpracování (typicky TXT, CSV, XML, JSON aj.).
Z pohledu interoperability a integrace s nástroji třetích stran musí řešení:
podporovat napojení na standardní autentizační mechanismy (Active Directory, LDAP, Radius, SQL-based) a některá řešení pro multifaktorovou autentizaci,
podporovat napojení na relační databáze pro import i export dat,
podporovat API webových služeb (SOAP, REST) pro import i export dat,
umožňovat definici datových pump pro potřeby hromadného importu a exportu dat, ETL procesů a ELT procesů,
podporovat federaci a vazby na systémy třetích stran, obsahujících konfigurační položky nebo pro konfigurační položky evidujících dodatečné atributy (například evidence majetku, evidence kontraktů), případně i tiketovací systémy třetích stran.
Z pohledu interaktivní práce musí řešení:
umožňovat víceuživatelský paralelní přístup,
umožňovat škálovatelnost do té míry, že lze maximální počet paralelně pracujících uživatelů libovolně navyšovat pouze za cenu posilování infrastruktury a dostupných zdrojů,
umožňovat buď
plnohodnotný způsob práce pomocí webového rozhraní s responzivním designem (tedy i na zařízeních typu tablet, mobilní telefon apod., v jejich nativních webových prohlížečích),
nebo alternativně plnohodnotný způsob práce pomocí tlustého klienta, dostupného pro všechny požadované platformy (MS Windows, MacOS, Linux, Android, iOS atd.).
Rozšířené funkční požadavky
Podpora testování konzistence dat a jejich souladu s procedurálními a procesními požadavky na úrovni konfiguračních položek, jejich atributů a vzájemných vazeb.
Řešení tedy musí být schopno:
u obligatorních pravidel vyžadovat jejich plnění, například "každá služba musí mít garanta, každý operační systém musí mít správce, pro každý hardware musí být definovaný servisní kontrakt",
reportovat nesoulad s doporučeními, např. porušení pravidel "na každém systému musí běžet alespoň jedna aplikace, každá aplikace musí být součástí nějaké služby".
Podpora dynamicky se měnícího IT prostředí a automatická aktualizace dat.
Řešení musí být možno provázat s řídícími, orchestračními a dalšími nástroji, v jejichž rámci probíhá údržba a rekonfigurace IT prostředků. Řešení musí být z těchto nástrojů schopno vyčítat aktuální stav a v závislosti na něm aktualizovat konfigurační databázi. Typicky se může jednat například o:
přesun virtuální instance mezi hostiteli v rámci clusteru; automaticky dojde k aktualizaci příslušné vazby mezi hostitelem a virtuální instancí,
přesun sdíleného diskového svazku mezi systémy; automaticky dojde k aktualizaci příslušné vazby,
přepojení fyzického serveru mezi aktivními prvky; dojde k detekci změny adresy a aktualizaci informace o propojení mezi fyzickým serverem a aktivním prvkem, respektive jeho portem.
Podpora průběžného vyhledávání, detekce a autoregistrace konfiguračních položek.
Řešení průběžně skenuje IT prostředí (síťové segmenty, řízení hypervisoru, cloud orchestrátory. CAM tabulky aktivních prvků aj.) a ověřuje, že jsou veškerá detekovaná aktiva známá. V případě objevení neznámého aktiva provede automatickou registraci, případně notifikuje správce konfigurační databáze.
Upřesnění technologických požadavků
Napojení na relační databáze
typ interní relační databáze, je-li aplikací využívána, není omezený a je na volbě poskytovatele; taková databáze / licence musí být součástí nabízeného řešení a nabídkové ceny,
u externích relačních databází lze předpokládat podporu ODBC nebo ekvivalentního nativního připojení.
Požadavky na temporální databázi
nabízené řešení musí na aplikační úrovni podporovat temporální způsob práce s daty, jak je popsáno výše,
záleží na poskytovateli řešení, jak toto zajistí; stejně tak je na jeho zodpovědnosti případná volba a správné zalicencování externí temporální databáze, bude-li využívána,
v případě pochybností bude považován za dostačující temporální způsob práce s daty v rozsahu dle normy SQL:2011 - ISO/IEC 9075:2011.
Požadavky na interoperabilitu
nad rámec v textu explicitně uvedených a poptávaných funkcionalit a technologií se v případě pochybností nabízené řešení považuje za integrovatelné, podporuje-li výměnu binárních dat minimálně v kódování Base64, textových dat minimálně v kódování UTF-8 a strukturovaných dat ve formátech XML nebo JSON, a to pomocí protokolů SOAP a REST.
Nefunkční požadavky
Dimenzování a výkonnost:
licenčně neomezený počet konfiguračních položek a uložených dat; technologické omezení pouze na základě poskytnutých IT zdrojů,
licenčně neomezený počet napojených externích systémů,
licenčně neomezený počet evidovaných aktivních uživatelů,
možnost plné souběžné interaktivní práce s definovanou maximální dobou odezvy v řádech jednotek sekund pro minimálně 20 konkurenčních uživatelů,
škálovatelnost, možnost zvětšovat počty paralelně pracujících uživatelů apod. přidáváním IT zdrojů.
Spolehlivost a podpora provozu:
průběžná údržba a záplatování řešení, dle životního cyklu vývoje a doporučení dodavatele,
provoz řešení v major verzi ekvivalentní k last-stable a s maximálním tolerovaným zpožděním nasazení minor verze na last-stable (-1) / (-2) dle doporučení dodavatele,
aplikace kritických záplat dodavatele do 2 dnů od jejich zveřejnění,
podpora provozu 24/7/365, s OLA alespoň 92% a časem odezvy na provozní nebo bezpečnostní incident do 4 hodin,
zvýšená podpora provozu v průběhu pracovní doby, s OLA alespoň 96% a časem odezvy na provozní incident do 2 hodin a na bezpečnostní incident do 1 hodiny,
možnost provozování řešení na virtualizační platformě MMB (VMWare),
možnost hromadné instalace softwarových komponent určených koncovým uživatelům standardními prostředky; dle cílové platformy - např. Microsoft / System Center, Android / Google Play, iOS / App Store aj.
Bezpečnost
uživatelské rozhraní musí být bezpečné do té míry, že ho je možné bez dodatečného zabezpečení třetí stranou (hardering, aplikační firewall, filtrace provozu apod.) zpřístupnit do internetu,
pokud jsou komponenty a funkcionality řešení dodávány formou webových služeb, musí být zabezpečeny proti běžným útokům dle doporučení OWASP,
řešení musí obsahovat dodatečné prvky pro posílení bezpečnosti při práci z nedůvěryhodných zdrojů, zejména neznámých veřejných IP adres,
pro interaktivní práci se za takové prvky považují například vícefaktorová autorizace, autorizace pomocí krypto-tokenů apod.,
pro strojové zpracování se za takové prvky považují například serverové certifikáty,
veškerá komunikace musí být šifrovaná (například SSL/TLS, VPN apod.
Příloha č. 2
Harmonogram plnění a platební milníky
Poskytovatel se zavazuje provádět Expertní služby po jednotlivých fázích tvořících dílčí plnění. Fáze provádění Expertních služeb jsou stanoveny v následující tabulce:
Název fáze |
Výstupy fáze (předané plnění) [seznam] |
Termín ukončení fáze (termín převzetí plnění) [T + t]*) |
Platební milník (k termínu ukončení fáze) [ano/ne] |
Cena za dílčí plnění k platebnímu milníku [Kč bez DPH] |
Definice projektu |
Zakládací listina projektu |
Doplní poskytovatel |
Doplní poskytovatel |
Doplní poskytovatel |
Návrh řešení |
Návrh architektury systému Detailní návrh systému Návrh provozu systému Předávací protokol |
|
|
|
Poskytnutí licencí |
Předávací protokol |
|
|
|
Realizace |
Protokol o výsledcích jednotkových (unit) testů |
|
|
|
Příprava provozu |
Seznam proškolených osob Implementační protokol Protokol o výsledcích uživatelských testů Protokol o výsledcích integračních testů |
|
|
|
Ověřovací provoz |
Protokol o zahájení produktivního (ostrého) provozu SD a CMDB Vyhodnocení ověřovacího provozu SD a CMDB Protokol o závěrečné akceptaci implementovaného SD a CMDB jako celku |
|
ano (povinný) |
|
CENA CELKEM |
|
|||
*) T – datum účinnosti Smlouvy
t – počet kalendářních dnů od data účinnosti Smlouvy
Měsíční pronájem, včetně údržby a provozu SD a CMDB bude probíhat po dobu 4 let ode dne předání a převzetí implementovaného SD a CMDB (ode dne produktivního provozu SD a CMDB). Tato Expertní služba bude hrazena měsíčně na základě faktury Poskytovatele, kterou Poskytovatel vystaví vždy do 15. dne kalendářního měsíce následujícího po měsíci, v němž bylo Expertní služba poskytnuta.
Příloha
č. 3
Vzor Akceptační protokolu
číslo:
Název projektu:
Číslo smlouvy MMB:
Etapa / fáze / období: Název etapy / fáze
Xxxxxxxxxxx projektu: jméno, příjmení a funkce zpracovatele
Název zprávy / plnění: odkazy na smlouvu (katalog služeb), forma akceptace, ceny bez DPH
číslo služby |
popis služby (odkaz na smlouvu) |
celkem za službu Kč |
výsledek akceptace (A/N/V)* |
|
|
|
|
|
|
|
|
|
|
|
|
Celkem Kč |
|||
*) A = akceptováno, N = neakceptováno, V = akceptováno s výhradou
Předání plnění dne: datum předání
Za poskytovatele |
Podpis |
Xxxxx a příjmení odpovědné osoby Poskytovatele |
|
Za objednatele |
Podpis |
Xxxxx a příjmení odpovědné osoby Objednatele |
|
Komentář (popis zjištěných nedostatků)
Případné výhrady a zjištěné nedostatky v plnění poskytovatele, případné návrhy na jejich odstranění včetně termínů, případné vyčíslení sankcí. Je-li seznam akceptačních výhrad v samostatném souboru, uvede se zde tento soubor jako příloha akceptačního protokolu.
Shrnutí řešení (splnění kritérií) – závěr akceptace (hodící se zakroužkujte)
A |
Při akceptaci nebyly zjištěny nedostatky |
V |
Při akceptaci byly zjištěny nedostatky, jejichž seznam je uveden dále / je uveden v příloze. Tyto nedostatky nebrání akceptaci. |
N |
Při akceptaci byly zjištěny nedostatky, jejichž seznam je uveden dále / je uveden v příloze. Tyto nedostatky brání akceptaci. |
A = akceptováno, N = neakceptováno, V = akceptováno s výhradou
Převzetí plnění dne: datum převzetí
Za objednatele převzal (akceptoval) |
Podpis |
Xxxxx a příjmení odpovědné osoby Objednatele |
|
Stránka 29 z 29