DODATEČNÉ INFORMACE č. 8 k zadávacím podmínkám

MĚSTSKÁ ČÁST PRAHA 4 ÚŘAD MĚSTSKÉ ČÁSTI Odbor právní Oddělení veřejných zakázek

DODATEČNÉ INFORMACE č. 8 k zadávacím podmínkám v zadávacím řízení č. VZN/15/004 vedeném v užším řízení k zadání nadlimitní veřejné zakázky na služby uveřejněné ve věstníku veřejných zakázek pod evid. číslem 516945: „Zajištění externího správce, tj. outsourcing informačních technologií a služeb“ Níže uvedený zadavatel tímto sděluje dodatečné informace v souladu s ust. § 49 zákona č. 137/2006 Sb., o veřejných zakázkách, v platném znění (dále jen zákon): Identifikační údaje veřejného zadavatele: Název zadavatele: Sídlo zadavatele: IČ: DIČ: Právní forma: Osoba oprávněná jednat jménem zadavatele:

Městská část Praha 4 Praha 4, Antala Staška 2059/80b 00063584 CZ00063584 městská část hlavního města Prahy JUDr. Pavel Šimice, vedoucí odboru právního

Zadavatel obdržel dne 28. 1. 2016 následující dotazy dodavatele k zadávacím podmínkám ve shora uvedeném zadávacím řízení a sděluje tímto své odpovědi na tyto dotazy. Dotaz č. 1 (přesné znění): Prosíme o upřesnění těchto nejasností zadávací dokumentace, konkrétně Přílohy č.3 ZD – Technická specifikace: - Na str. 44: Primární cluster bude zajišťovat běžný provoz virtuální infrastruktury s kritickými aplikacemi v počtu celkových 6 ks virtualizačních serverů typu blade. - Na str. 45 je v tabulce požadavků na licence Vmware uvedeno: Bod 3.: Licence pro Primární virtualizační cluster v rozsahu min. 5 serverů / 10 CPU socketů. Prosíme o vyjasnění této nejasnosti v počtu serverů primárního virtualizačního clusteru. Odpověď zadavatele na dotaz č. 1: Zadavatel v rámci kontextu Přílohy č. 3 ZD – Technická specifikace opravuje chybu psaní na str. 45 bod3: „Licence pro Primární virtualizační cluster v rozsahu min. 6 serverů / 10 CPU socketů“.

Dotaz č. 2 (přesné znění): Prosíme o upřesnění těchto nejasností zadávací dokumentace, konkrétně Přílohy č.3 ZD – Technická specifikace: - Na str. 44: Licence Disaster Recovery řešení bude vyžadována pro minimálně 25 virtuálních serverů. - Na str. 45 je v tabulce požadavků na licence Vmware uvedeno: Licence pro automatickou replikaci minimálně 70 virtuálních serverů… Prosíme o vyjasnění této nejasnosti v počtu virtuálních serverů pro DR řešení. Odpověď zadavatele na dotaz č. 2: Zadavatel opravuje chybu psaní na str. 44: „Licence Disaster Recovery řešení bude vyžadováno pro minimálně 70 virtuálních serverů.“ Dotaz č. 3 (přesné znění): Prosíme o upřesnění těchto nejasností zadávací dokumentace, konkrétně Přílohy č.3 ZD – Technická specifikace: - Na str. 56, bod 3 „Zálohované prostředí a konfigurace“: Minimálně 6 ks ESX virtualizačních serverů s on-line konzistentním zabezpečením všech provozovaných VM s OS Windows a Linux Zřejmě se jedná pouze o zálohování primární lokality. Nicméně např. na str. 40 se uvádí, že v záložní lokalitě budou „běžet doplňkové servery“. Zálohování tedy nemusí počítat se zálohováním i záložní lokality? Odpověď zadavatele na dotaz č. 3: Ano, není nutno řešit zálohování záložní lokality. Dotaz č. 4 (přesné znění): Prosíme o upřesnění těchto nejasností zadávací dokumentace, konkrétně Přílohy č.3 ZD – Technická specifikace: - Na str. 52: Důkladné zabezpečení zálohovaných dat na cílových médiích je tak zajištěno integrovanou enkrypcí jak na diskovém zálohovacím zařízení, tak na LTO6 magnetopáskových mechanikách. V tabulce závazných požadavků na str. 52 „W. Zálohovací systém - magnetopásková knihovna“ však není kryptování na páskách nikde upřesněno a požadováno. Je tedy požadováno kryptování na páskách? Odpověď zadavatele na dotaz č. 4: Zadavatel tímto opravuje nepřesnost v textu na str. 52. poslední odstavec Přílohy č. 3 zadávací dokumentace: „Důkladné zabezpečení zálohovaných dat na cílových médiích je zajištěno integrovanou enkrypcí na diskovém zálohovacím zařízení, ne však na LTO6 magnetopáskových mechanikách.“

- 2/7 -

Dotaz č. 5 (přesné znění): Prosíme o upřesnění těchto nejasností zadávací dokumentace, konkrétně Přílohy č.3 ZD – Technická specifikace: - Na str. 54, bod 7 „Stabilita a zabezpečení“: Možnost, aby zařízení disponovalo funkcionalitou pro šifrování ukládaných data metodou data-atrest. Zařízení musí disponovat funkcionalitou pro šifrování ukládaných data metodou data-at-rest. Má tedy šifrování dat být zahrnuto už v nabídce, nebo má jít o možnost rozšíření do budoucna? Odpověď zadavatele na dotaz č. 5: Zadavatel z důvodu jednoznačnosti ruší na str. 54 v bodě 7 „Stabilita a zabezpečení“ původní texty: - „Možnost, aby zařízení disponovalo funkcionalitou pro šifrování ukládaných data metodou data-at-rest - „Zařízení musí disponovat funkcionalitou pro šifrování ukládaných data metodou data-atrest“ a nahrazuje je oba tímto zněním: - „Zařízení musí do budoucna disponovat možnosti rozšíření o funkcionalitu pro šifrování ukládaných dat metodou data-at-rest“ Dotaz č. 6 (přesné znění): Prosíme o upřesnění těchto nejasností zadávací dokumentace, konkrétně Přílohy č.3 ZD – Technická specifikace: - Na str. 56, bod 12 a další neočíslovaný: Podpora zálohování on-line aplikací Oracle, SQL, Exchange, SharePoint ve fyzickém i virtuálním prostředí Možnost zálohování on-line aplikací Oracle, SQL, Exchange, SharePoint ve fyzickém i virtuálním prostředí Má tedy nabízené řešení obsahovat i licence pro tyto aplikace, nebo má jít o možnost o rozšíření v budoucnu? Odpověď zadavatele na dotaz č. 6: Zadavatel z důvodu jednoznačnosti ruší na str. 57 v bodě 12 „Požadované funkcionality“ a v dalším neočíslovaném původní text: - „Podpora zálohování on-line aplikací Oracle, SQL, Exchange, SharePoint ve fyzickém i virtuálním prostředí“ - Možnost zálohování on-line aplikací Oracle, SQL, Exchange, SharePoint ve fyzickém i virtuálním prostředí“ a nahrazuje je oba jedním bodem s tímto zněním: - „Do budoucna musí být zachována možnost rozšíření o podporu zálohování on-line aplikací Oracle, SQL, Exchange, SharePoint ve fyzickém i virtuálním prostředí“. Dotaz č. 7 (přesné znění):

- 3/7 -

Prosíme o upřesnění těchto nejasností zadávací dokumentace, konkrétně Přílohy č.3 ZD – Technická specifikace: V úvodu kapitoly 4 technické specifikace (Popis požadavků na outsourcing, převzetí správy IT systémů) je jako základní požadavek uveden „Provoz systému HelpDesk zadavatele, poskytnutí HotLine“. Znamená to, že uchazeč kompletně převezme provoz systému HelpDesk (aplikace HelpDesk včetně hlasového kanálu a služeb operátorů)? Odpověď zadavatele na dotaz č. 7: V zadávací dokumentaci v kapitole 4.1 Základní komunikační pravidla a požadavky na organizaci pro poskytování outsourcingových služeb je uvedeno, že základním komunikačním kanálem je aplikační systém HelpDesku ve vlastnictví zadavatele. Zadavatel tedy předpokládá, že v rámci poskytování outsourcingových služeb uchazeč nepřevezme provoz ani administraci aplikačního systému HelpDesk. Pro hlasový kanál je možno využít pevných pobočkových linek provozovaných v rámci PBX úřadu. Jelikož zadavatel vychází z principů poskytování outsourcingových služeb, předpokládá, že služby operátorů budou zajištěny v rámci tohoto vztahu. Dotaz č. 8 (přesné znění): Prosíme o upřesnění těchto nejasností zadávací dokumentace, konkrétně Přílohy č.3 ZD – Technická specifikace: V kapitole 4.3.2.1 technické specifikace (HelpDesk, CallDesk, „Trouble management“ ) je uvedeno, že „Služba je podporována využitím systému HelpDesku ve vlastnictví zadavatele“. V požadavcích na specifikaci služby v nabídce uchazeče je uveden požadavek na „Popis služby HelpDesk“. Žádáme o sdělení, jaký systém MČ PRAHA 4 používá pro zajištění administrace incidentů, popis jeho funkčností. V případě, že systém HelpDesk bude obsluhován zaměstnanci zadavatele, žádáme o sdělení, jakým způsobem bude tým podpory uchazeče o incidentech informován (mailem, telefonicky, přístupem na HelpDesk???) a jakým způsobem bude zpětně podávat zprávy o řešení problému. Odpověď zadavatele na dotaz č. 8: Zadavatel využívá RT (Request Tracker) verze 4.2.8 od Best Practical. Pro potřeby popisu služeb v oblasti HelpDesk, CallDesk a Trouble management zadavatel poskytuje přehled funkcí systému HelpDesk: Evidence TT trouble ticket – požadavek (dále také TT) a jejich stavů (otevřený, v řešení apod.). Úvodní přehled zobrazuje nejnovější TT jejich vlastníka/řešitele a termín dokončení. Možnost přidělit/změnit řešitele TT. Členění požadavků podle front (každá fronta má vlastní e-mailovou adresu pro příjem TT). U jednotlivých front je možnost nastavení různých termínů pro dokončení TT. Upozornění na přijetí nového TT nebo při příjmu nové informace do TT. Při přijmu/založení TT možnost automatického přeposlaní upozornění. Dokumentace všech příchozích/odchozích zpráv a komentářů v TT. Zprávy a komentáře jsou v TT řazeny dle časové posloupnosti. Správa uživatelů systému (zakládání nových uživatelů apod.), možnost nastavení oprávnění k frontám a funkcím. Funkce vyhledávaní v TT (podle různých parametrů, např. stav TT, čas založení, vlastník apod.).

- 4/7 -

HelpDesk systém v kontextu odpovědi na dotaz č. 7 bude obsluhován zaměstnanci uchazeče. Předpokladem je, že vlastní organizace činností je na straně uchazeče. Zde zadavatel očekává popis procesů organizace činností v předložené nabídce uchazečem v rámci „Popis služeb v oblasti HelpDesk, CallDesk a Trouble management“. Zadavatel požaduje zaznamenání veškerých informací o řešení problému do systému HelpDesk, ze kterého bude moci čerpat informace o stavu řešených problému. Dotaz č. 9 (přesné znění): Prosíme o upřesnění těchto nejasností zadávací dokumentace, konkrétně Přílohy č.3 ZD – Technická specifikace: V rámci služby Evidence umístění HW a SW u zadavatele (kapitola 4.4.2 technické specifikace) je uchazeč povinen evidovat každý pohyb svěřeného, vráceného i umístěného HW/SW, přičemž zadavatel musí mít do této evidence „on-line přístup, prostřednictvím aplikace Helpdesku.“. V zadávací dokumentaci se dále uvádí, že „V rámci HelpDesku je definován proces, zajišťující provedení aktualizace evidence místa uložení, kde je výsledkem procesu generovaný úkol pro zaznamenání této změny místa uložení v majetkové evidenci úřadu.“ Rozumíme zadání správně tak, že evidence HW nebude vedena v aplikaci HelpDesk (ve vlastnictví zadavatele) ale v aplikaci uchazeče, do které bude mít zadavatel přístup prostřednictvím odkazu uvedeného v systému HelpDesk? Žádáme o vysvětlení a popis procesu v aplikaci HelpDesk, který zajišťuje aktualizaci evidence místa uložení. Jestliže má být výsledkem tohoto procesu aktualizace umístění SW a HW úkol zadaný do aplikace HelpDesk, žádáme o informaci, zda bude mít tým podpory uchazeče oprávnění k založení úkolu v aplikaci HelpDesk přímo, nebo tak bude činit jinou formou (mailem, telefonicky). Odpověď zadavatele na dotaz č. 9: Zadavatel předpokládá, že poskytne v elektronické podobě ze systému GINIS ve kterém je vedena evidence majetku úřadem uchazeči majetek, který bude předán ke svěřené správě. Uchazeč rozumí správně, že evidence jim spravovaného svěřeného majetku bude vedena v aplikaci uchazeče, ke kterému bude mít rovněž přístup zadavatel. Předpokladem je, že pokud dojde při řešení jakéhokoli požadavku ke změně místa uložení svěřeného majetku, má v rámci procesu řešení požadavku uchazeč povinnost toto místo uložení změnit v aplikaci. V rámci uvedeného procesu je na úrovni aplikace (zasláním strukturovaného e-mailu) o této skutečnosti vygenerován úkol v systému Helpdesk pro zaměstnance úřadu, kteří spravují v rámci ekonomických systému tento majetek. Dotaz č. 10 (přesné znění): V Zadávací dokumentaci v kapitole 4.1. je uvedena věta: „Uzavření a účinnost smluv na plnění jednotlivých částí (termín zahájení poskytnutí dodávek a poskytování služeb) této veřejné zakázky zadavatel předpokládá bezprostředně po ukončení zadávacího řízení, nejpozději však ke dni 1. 3. 2016.“ Tento termín je nereálný z několika důvodů: a) termín pro odevzdání nabídek je stanoven na 2. 3. 2016 b) Zadavatel po tomto termínu musí nabídky vyhodnotit a následně (do 5 pracovních dnů) odeslat oznámení o výběru nejvhodnější nabídky všem dotčeným zájemcům a všem dotčeným uchazečům.

- 5/7 -

c) dle § 82, odst. 1 zadavatel nesmí před uplynutím lhůty pro podání námitek proti rozhodnutí o výběru nejvhodnější nabídky podle § 110 odst. 4 uzavřít smlouvu s uchazečem, jehož nabídka byla vybrána jako nejvhodnější. Upraví zadavatel text Zadávací dokumentace tak, aby byla v souladu se Zákonem o veřejných zakázkách? Odpověď zadavatele na dotaz č. 10: Zadavatel v této věci sděluje, že uzavření a účinnost smluv na plnění jednotlivých částí má přímou vazbu na výsledek předmětného zadávacího řízení, stejně tak jako konkrétní termíny jejich ukončení, uvedené v zadávací dokumentaci a jejích přílohách. Stanovení shora uvedeného termínu 1. 3. 2016 byl předpokladem zadavatele při zahájení druhé fáze tohoto zadávacího řízení. Tento předpoklad potvrzuje druhý odstavec zmiňované kapitoly zadávací dokumentace, kde si zadavatel vyhrazuje právo předmětné termíny ve vztahu k těmto smlouvám posunout na pozdější dobu. Zadavatel tedy v tomto ohledu nebude zadávací dokumentaci upravovat. Dotaz č. 11 (přesné znění): V Zadávací dokumentaci v kapitole 4.1. je uvedena věta: „Termín ukončení účinnosti smluv pro všechny části této veřejné zakázky zadavatel předpokládá nejpozději ke dni 31. 3. 2021.“ Dle Přílohy č. 5 – Návrh rámcové smlouvy se však rámcová smlouva i První prováděcí smlouva uzavírá na dobu do 31. 12. 2020. Může Zadavatel sjednotit Zadávací dokumentaci a Návrh rámcové smlouvy? Odpověď zadavatele na dotaz č. 11: Zadavatel konstatuje písařskou chybu uvedenou v odst. 1 čl. IV Doba poskytování služeb v roce ukončení rámcové smlouvy, stejně jako v její příloze č. 3 v odst. 1 čl. V Závěrečná ustanovení První prováděcí smlouvě. V obou těchto případech byl v době zahájení druhé fáze zadávacího řízení předpoklad jejich ukončení v termínu do 30. 4. 2021. Zadavatel ovšem stále upozorňuje, stejně jako v předchozí své odpovědi na dotaz č. 10, že se jedná o předpokládaný termín, který se s ohledem na současný průběh zadávacího řízení posune ve vazbě na výsledek ukončení předmětného zadávacího řízení. Pro zvýšení jistoty uchazečů zadavatel sděluje, že délka trvání smluvního vztahu (vztahuje se k oběma částem veřejné zakázky) je stanovena na 5 let. Dotaz č. 12 (přesné znění): V Návrhu Rámcové smlouvy v Příloze č. 3 – První prováděcí smlouvě v čl. III, odst. 4 je uvedena věta: „Poskytovatel je povinen pečovat o zařízení uvedené v předchozím odstavci 7 a odpovídá za tato zařízení jako skladovatel (§ 2415 a násl. občanského zákoníku).“ Uchazeč však v této příloze žádný předchozí odstavec 7 nenašel. Uchazeč se domnívá, že se jedná o administrativní chybu a zde by měl být odkaz na předchozí odstavec 3. Upraví zadavatel návrh smlouvy tak, aby obsahoval správný odkaz?

- 6/7 -

Uchazeč žádá zadavatele o zřetelné vyjasnění výše uvedené skutečnosti, která může zásadně ovlivnit konstrukci nabídky uchazeče. Odpověď zadavatele na dotaz č. 12: Zadavatel tímto potvrzuje domněnku uchazeče a opravuje tímto písařskou chybu v chybném odkazu na číslo předchozího odstavce. Správné číslo předchozího odstavce v odkazu je odstavec č. 3. Nově tedy odstavec č. 4 čl. III. Způsob poskytování služeb v První prováděcí smlouvě, jež tvoří přílohu č. 3 rámcové smlouvy zní: „Poskytovatel je povinen pečovat o zařízení uvedené v předchozím odstavci 3 a odpovídá za tato zařízení jako skladovatel (§ 2415 a násl. občanského zákoníku). Poskytovatel bere na vědomí, že v těchto prostorách je umístěn i hardware dodaný na základě smlouvy uzavřené podle první části veřejné zakázky (dále jen „HW“) a že k tomuto zařízení musí mít přístup pracovníci dodavatele HW. Je proto povinen těmto pracovníkům umožnit na jejich žádost přistup do prostor, v nichž je HW umístěn tak, aby mohli plnit povinnosti dodavatele HW. Další podrobnosti týkající se této povinnosti stanoví rámcová smlouva.“ S ohledem na charakter a termín poskytnutí shora uvedených odpovědí zadavatele, se prodlužuje lhůta pro podání nabídek o 5 dní, tj. do 7. 3. 2016 do 12,00 hod. V této souvislosti se mění termín otevírání obálek a to dne 7. 3. 2016 od 13,00 hod. Místo konání otevírání obálek zůstává beze změny. V Praze dne 3. 2. 2016

JUDr. Pavel Šimice, v.r. vedoucí odboru právního Úřadu městské části Praha 4

- 7/7 -