Dodatečné informace k zadávacím podmínkám veřejné zakázky č. 4 Informace o prodloužení lhůty pro podání nabídek

Transkript

1 VÁŠ DOPIS ZN. ČÍSLO JEDNACÍ SPISOVÁ ZNAČKA DATUM LCR099/39/ / VYŘIZUJE TELEFON GSM FAX Zahálková Dodatečné informace k zadávacím podmínkám veřejné zakázky č. 4 Informace o prodloužení lhůty pro podání nabídek Název veřejné zakázky, evidenční číslo VZ Dodávka a implementace integrační platformy Ev. č. VZ Zadavatel Lesy České republiky, s.p., se sídlem Přemyslova 1106/19, Nový Hradec Králové, Hradec Králové, IČO: Zadavatel výše uvedené veřejné zakázky zadávané dle zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů (dále jen ZVZ ), tímto v souladu s 49 ZVZ poskytuje dodatečné informace, a to všem dodavatelům, kteří požádali o poskytnutí zadávací dokumentace nebo kterým byla zadávací dokumentace poskytnuta. Zadavatel současně uveřejnil dodatečné informace včetně přesného znění žádosti stejným způsobem, jakým uveřejnil zadávací dokumentaci (tzn. na profilu Zadavatele). V zájmu zachování přehlednosti zadavatel poskytuje v tomto dokumentu i všechny již dříve poskytnuté dodatečné informace k výše uvedené veřejné zakázce. Dotaz č. 1 (obdržen ): Prosíme o upřesnění požadavku INP_22 na integrační platformu. Cílem Zadavatele je zřejmě získat řešení, které dokáže fungovat jako jeden celek a tato schopnost je garantována výrobcem a otestována. Současná formulace požadavku k tomuto cíli může, ale nemusí nutně vést a naopak může omezit jiná řešení. Chceme se proto konkrétně zeptat, zdali je možné akceptovat i následující :

2 1/ Modul BPM je nativním konektorem napojen na ESB, a součinnost ESB s BPM je výrobcem otestovaná a podporovaná. 2/ Modul BPM je dodáván jako OEM komponenta ESB pod obchodní značkou výrobce ESB. Je tedy podporovanou součástí platformy, ale původní výrobce BPM je jiný než výrobce ESB. Odpověď na dotaz č. 1 (poskytnuta ): Ad1) Ano, řešení, které bude garantovat nativní integraci (propojení) komponent BPM a ESB, respektuje cíl Zadavatele tj. mít možnost v budoucnu získat ucelené integrované řešení včetně komponenty BPM, která nicméně není v tuto chvíli předmětem implementace a dodávky. Uchazeč uvede v nabídce popis způsobu integrace. Ad2) Ano, takové řešení je možné dodavatel musí nabídnout možnost (garantovat schopnost) budoucího rozšíření ESB o produkt pro podporu obchodních procesů (BPM) dle principů SOA. Uchazeč uvede v nabídce popis způsobu integrace. Zadavatel se rozhodl upravit popis požadavku INP_022, tento nově zní: INP_022 BPM Řešení musí umožňovat budoucí integraci s produktem pro podporu obchodních procesů (BPM), odpovídajícím principům SOA. Dodávka produktu BPM není součástí předmětu plnění této veřejné zakázky, výběr produktu BPM bude v případě potřeby v budoucnu proveden v samostatné soutěži. Tvorba strojových procesů v produktu BPM bude v jazyce BPEL. V případě budoucího rozšíření o produkt BPM Zadavatel pro tento účel poskytne dodatečnou HW a SW infrastrukturu. Zadavatel výše uvedenou změnu popisu požadavku INP_022 zapracoval do přílohy č. 1 ZD Technická specifikace. Upravený dokument je poskytován jako součást této dodatečné informace, dne byl publikován na profilu zadavatele. Název upraveného dokumentu: 02 Příloha č. 1 ZD - Technická specifikace IP_úprava_ V souvislosti s podanou informací byla zadavatelem prodloužena lhůta pro podání nabídek konec lhůty byl stanoven na do 10,00 hod. Tento termín už není aktuální viz dále. Informace č. 2 - poskytnutá zadavatelem bez předchozí žádosti dle 49 odst. 4 ZVZ (poskytnuta ): Zadavatel v zájmu usnadnění zpracování nabídky poskytuje jako přílohu této dodatečné informace podrobnější podobu vzoru úvodního listu s doplněnými tabulkami pro uvedení nabídkové ceny (v požadované struktuře) a dalších číselných údajů, které jsou předmětem hodnocení. Přiložený dokument byl dne rovněž publikován na profilu zadavatele jako příloha č. 3 zadávací dokumentace Úvodní list nabídky (vzor)_ver V zájmu jednoznačnosti zadavatel dále uvádí, že krycím listem, zmiňovaným v článku 10 zadávací dokumentace, je míněn úvodní list nabídky, jehož vzor je obsažen v Příloze č. 3 zadávací dokumentace.

3 Informace č. 3 - poskytnutá zadavatelem bez předchozí žádosti dle 49 odst. 4 ZVZ (poskytnuta ): Zadavatel v článku 2.1 zadávací dokumentace uvádí pro oblast pořízení licencí produktů Microsoft následující: V případě SW produktů společnosti Microsoft zadavatel požaduje využít smlouvu Enterprise Agreement, která zadavateli umožňuje využívat oprávnění k příslušnému SW za zvýhodněných podmínek, a to v kategorii A, tzn. pokud dodavatel nabídne řešení využívající produkty společnosti Microsoft, v rámci své nabídky bude vycházet z kategorizace zadavatele v rámci smlouvu Enterprise Agreement. Zadavatel sděluje, že došlo ke změně kategorizace zadavatele z kategorie A, uvedené v článku 2.1 zadávací dokumentace, na kategorii B dle aktuálně platné smlouvy EA zadavatele. Zadavatel dále sděluje, že vyjednal v této věci se společností Microsoft Česká republika následující postup: Společnost Microsoft Česká republika (kontaktní osoba viz níže) provede na vyžádání potenciálního dodavatele zpracování ce kalkulace licencí, které potenciální dodavatel hodlá zadavateli nabídnout v rámci nabídky na výše specifikovanou veřejnou zakázku. Dodání licencí pro zadavatele bude zajištěno formou subdodávky poskytnuté vybranému dodavateli společností SoftwareONE Czech Republic, s.r.o., která je příslušným smluvním partnerem zadavatele (Licencing Solution Partner - LSP). Kontaktní osoba společnosti Microsoft Česká republika: Ing. Stanislav Kosík Account Executive stkosik@microsoft.com Mob Building Alfa, BB Centrum, Vyskočilova 1461/2a, , Praha 4 Kontaktní osoba společnosti SoftwareONE Czech Republic, s.r.o.: Petr Pánek BDM petr.panek@softwareone.com Mob SoftwareONE Czech Republic, s.r.o., Želetavská 1448/7, Praha 4 Informace č. 4 - poskytnutá zadavatelem bez předchozí žádosti dle 49 odst. 4 ZVZ (poskytnuta ): Zadavatel v zájmu jednoznačnosti výkladu zadávacích podmínek uvádí, že v současné době disponuje plným zalicencováním uživatelského prostředí v rámci Microsoft domény LČR. Jedná se tedy o plné pokrytí tzv. User a Device CAL licencemi pro 2200 uživatelů, a to ve struktuře 2000 Device CAL licencí a 200 User CAL licencí. Pro nabízená řešení není tedy nutné počítat s klientskými licencemi pro přístup v rámci Microsoft domény LČR. Pokud dané řešení vyžaduje vlastní produktové licence na potřebný počet uživatelů nebo CPU, je nutné tyto licence zohlednit v rámci daného řešení. V souvislosti s podanými informacemi byla zadavatelem prodloužena lhůta pro podání nabídek konec lhůty byl stanoven na do 10,00 hod. Tento termín už není aktuální viz dále.

4 Dotaz č. 5 (obdržen ): Zadavatel požaduje v kap. 5.4 (Technické kvalifikační předpoklady dle ust. 56 ZVZ), v části a) předložit referenční projekty. Chápe dodavatel správně, že v bodě 1 zadavatel požaduje předložit referenci na rozvoj (příp. implementaci) integrační platformy, jejíž parametry jsou takové, že umožňuje současně integraci více jak 4 systémů s minimálním počtem 25 integračních služeb (procesů) celkem? Odpověď na dotaz č. 5 (poskytnuta ): Ano. Zadavatel požaduje předložit referenci na rozvoj/implementaci IP, kde proběhla integrace minimálně 4 různých systémů a celkový minimální počet integračních služeb byl celkem 25. Zadavatel nestanovuje minimální počet služeb pro jednotlivé integrované systémy. Dotaz č. 6 (obdržen ): V kapitole 9.2. je popsáno, jak budou přidělovány body v rámci dílčího hodnotícího kritéria C. takto: V rámci dílčího hodnotícího nabídek dle kritéria C. Nároky na HW infrastrukturu zadavatele" se jedná o kvantitativní kritérium, u něhož jsou preferovány nižší hodnoty před vyššími (tj. nižší zatížení HW infrastruktury zadavatele, kterou zadavatel disponuje či ji musí obstarat). Bodové ohodnocení jednotlivých nabídek v rámci daného dílčího hodnotícího kritéria vznikne součtem převážených bodových hodnot dosažených v jednotlivých subkritériích tohoto dílčího hodnotícího kritéria, tj. součtem bodových ohodnocení v daných subkritériích převážených vahou příslušného subkritéria. Zaokrouhlování bude prováděno na dvě desetinná místa. Vychází-li uchazeč při výpočtu z výše uvedeného textu, tak bodové hodnoty tohoto kritéria vychází opačně, než jak zamýšlí zadavatel. Při výpočtu získají vyšší hodnoty, tedy ty které nejsou preferovány, vyšší počet bodů než preferované nižší hodnoty. Může zadavatel vysvětlit, jak zamýšlí hodnotit dílčí hodnotící kritérium C., to nejlépe formou vzorce, aby nemohlo dojít k nejasnostem v hodnocení? Odpověď na dotaz č. 6 (poskytnuta ): Zadavatel uvádí, že v rámci dílčího kritéria C. Nároky na HW infrastrukturu zadavatele", resp. všech jeho subkritérií, jsou preferovány nižší hodnoty před vyššími (stejně jako je tomu v případě nabídkové ceny). Z uvedeného důvodu hodnocená nabídka získá v rámci každého hodnotícího subkritéria bodovou hodnotu, která vznikne násobkem 100 a poměru hodnoty nejvhodnější nabídky k hodnocené nabídce. Přidělená bodová hodnota bude poté převážena vahou příslušného subkritéria. Za účelem určení celkového počtu bodů dosaženého v rámci daného dílčího hodnotícího kritéria bude součet převážených bodových hodnot dosažených v rámci jednotlivých subkritérií převážen vahou dílčího hodnotícího kritéria (tj. 15 %). V případě dílčího kritéria B. Kvalita realizačního týmu se jedná o kritérium, u něhož jsou preferovány vyšší hodnoty před nižšími (tj. vyšší kvantifikovatelná úroveň zkušeností členů realizačního týmu před nižšími zkušenostmi). Z uvedeného důvodu hodnocená nabídka získá v rámci

5 každého hodnotícího subkritéria bodovou hodnotu, která vznikne násobkem 100 a poměru hodnoty hodnocené nabídky k nejvhodnější nabídce. Přidělená bodová hodnota bude poté převážena vahou příslušného subkritéria. Za účelem určení celkového počtu bodů dosaženého v rámci daného dílčího hodnotícího kritéria bude součet převážených bodových hodnot dosažených v rámci jednotlivých subkritérií převážen vahou dílčího hodnotícího kritéria (tj. 20 %). Dotaz č. 7 (obdržen ): Můžete specifikovat/odhadnout denní počet interakcí se službami uvedenými Příloze 2 Technické specifikace a s nimi související objem přenášených dat? Odpověď na dotaz č. 7 (poskytnuta ): Četnost a velikost zpráv (v řádech) za rok 2014: Název služby Počet voláni za rok Velikost dat /D201Portal/VytvoreniRezervaceBS tisíce desítky Kb /D500Proces/PravidloDatacomBS stovky desítky Kb /D200Portal/VykazLes801BS stovky stovky Kb /D500Proces/CirkevniRestituceBS tisíce desítky Kb /D201Portal/ZneplatneniRezervaceBS stovky desítky Kb MailDatacom stovky tisíc desítky Mb S50013CCSMonitor_PollAdapter desítky tisíc stovky Kb S50014KontrolaSeznamuBS stovky desítky Kb /D200Portal/GeoObjectBS stovky desítky Mb /D200Portal/OrgJednotkaBS deseti tisíce stovky Kb /D200Portal/ZamKontaktInfoPLBS stovky desítky Kb /D100DMS/EvidenceVozidelBS stovky desítky Kb /D200Portal/S20008CUzemniCelek tisíce desítky Kb /D200PortalS20002Katastr desítky milionů stovky Kb D201Portal/OsivoBS deseti tisíce stovky Kb DMS/DocInfo,DMS/GetFile stovky tisíc jednotky Mb Dotaz č. 8 (obdržen ): NEF_050 požaduje podporu zálohování dat. Jaká konkrétně data procházející ESB jsou určena k záloze? Jak stará a jak častá je požadovaná záloha?

6 Odpověď na dotaz č. 8 (poskytnuta ): Položky (data), u kterých je požadována realizace záloh, jsou následující: Konfigurační soubory a nastavení systému Zdrojový kód k vytvořeným službám/rozhraním/konektorům Transakční logy jednotlivých služeb/rozhraní/konektorů Soubory, které jsou přenášeny pomocí ESB, nejsou předmětem zálohy. Dle požadavků NEF_050 a NEF_051, řešení musí umožňovat zálohu dat pomocí nástroje TSM (Tivoli Storage Management) a musí umožňovat plnou a inkrementální zálohu. Provedení zálohy zajišťuje zadavatel, obdobně pak zadavatel definuje její rozsah a četnost. Zadavatel předpokládá realizaci denní zálohy transakčních logů, týdenní zálohu konfiguračních souborů a nastavení systému IP a měsíční až čtvrtletní zálohu zdrojových kódů k vytvořeným službám/rozhraním/konektorům. Dotaz č. 9 (obdržen ): Příloha č. 4 Technické specifikace uvádí jako technické standardy databáze Oracle a MS SQL. Připouští se využití jiných, efektivnějších a nákladově výhodnějších databází? Např. NoSQL databáze pro správu auditních informací, popř. alternativní databáze pro správu konfigurace řešení? Odpověď na dotaz č. 9 (poskytnuta ): Využití řešení, které není v souladu s technologickými standardy uvedenými v Příloze č. 4 Technické specifikace, Zadavatel nepřipouští. Dotaz č. 10 (obdržen ): NEF_016, reps. NED_017 popisují požadavky na řešení incidentů na straně Dodavatele. Jaký nástroj pro správu incidentů Zadavatel používá? Bude do něj Dodavateli umožněn přístup? Odpověď na dotaz č. 10 (poskytnuta ): Zadavatel požaduje, aby Dodavatel respektoval principy řízení incidentů (případně principy dalších procesů řízení IT), které jsou realizovány v prostředí Zadavatele. Nástroj, který bude využíván pro řízení incidentů, bude k dispozici před zahájením produktivního provozu předmětu plnění této VZ. Zadavatel zajistí Dodavateli přístup do tohoto nástroje. Dotaz č. 11 (obdržen ): Druhý odstavec kapitoly 2 Technické specifikace vylučuje dodatečné úpravy standardního řešení. Vylučuje se tímto i rozšíření standardní dodávky o zásuvné moduly třetích stran? Odpověď na dotaz č. 11 (poskytnuta ): Ne, moduly třetích stran lze považovat za standardní řešení. Dotaz č. 12 (obdržen ): Účelem výběrového řízení je poskytnutí licencí standardního produktu IP, jeho konfigurace a implementace v prostředí Zadavatele. Předpokládá toto výběrové řízení zároveň implementaci jednotlivých rozhraní v podobě poskytovaných služeb, mediačních sekvencí, volání konektorů atd.? Ze ZD vyplývá, že toto bude zodpovědnost Zadavatele po nasazení IP (a s ní související infrastruktury). Zároveň je ale v Příloze 3 Technické specifikace požadován popis integrace obsahující "způsob integrace na ostatní systémy nebo mezi význačnými komponentami řešení". Je

7 předmětem této zakázky implementace jednotlivých rozhraní na systémy uvedené v Příloze 2 Technické specifikace? Odpověď na dotaz č. 12 (poskytnuta ): Ano, implementace rozhraní uvedených v Příloze č. 2 Technické specifikace je předmětem plnění veřejné zakázky a nabídek uchazečů. Dotaz č. 13 (obdržen ): Dle kapitoly 2.1 ZD je obsahem Fáze 2 - Implementace "vývoj a konfigurace". Je v rámci dodávky přípustný vývoj nad rámec standardního řešení? Toto je v rozporu s odstavcem 2 kapitoly 2 Technické specifikace. Odpověď na dotaz č. 13 (poskytnuta ): Zadavatel požaduje dodání standardního řešení, které nebude upraveno vlastním vývojem a které bude požadavky zadavatele řešit prostřednictvím konfigurace a nastavení. Současně Zadavatel umožňuje využití zásuvných modulů pro standardní řešení. Uchazeč je současně oprávněn provést vývoj jednotlivých služeb/rozhraní/konektorů definovaných v Příloze č. 1 zadávací dokumentace Technické specifikaci. Dotaz č. 14 (obdržen ): Součástí požadovaných výstupů definovaných v Příloze 3 Technické specifikace je dodání testovacích scénářů a případů. Předpokládá se rovněž dodání testovacích scénářů a případů pro integrační rozhraní (služby a konektory) implementované Zadavatelem na IP? Odpověď na dotaz č. 14 (poskytnuta ): Dodání testovacích scénářů a případů je požadováno pouze pro rozhraní/služby/konektory dodané Dodavatelem v rámci dodávky předmětu řešení (definované v Příloze č. 1 Technické specifikaci). Pokud Zadavatel vlastními silami implementuje rozhraní/služby/konektory v rámci Integrační platformy (tj. nad rámec případů dle předchozí věty), nebude na tyto úpravy požadovat dodání testovacích případů a testovacích scénářů. Dotaz č. 15 (obdržen ): Dodavatel je zodpovědný za poskytnutí plánu testování a plánu nasazení. Kdo je zodpovědný za řízení testování a nasazení? Odpověď na dotaz č. 15 (poskytnuta ): Zadavatel dle Zadávací dokumentace zajišťuje vlastními silami roli systémového integrátora a současně zajišťuje řízení implementace, a to včetně testování a nasazení. Za vlastní provedení testování (mimo uživatelské testy, za jejich provedení odpovídá Zadavatel) a nasazení odpovídá Dodavatel, a to dle Zadavatelem definovaného a schváleného plánu implementace. Dotaz č. 16 (obdržen ): Jaké certifikáty budou používány pro zajištění autentizace pomocí SSL?

8 Odpověď na dotaz č. 16 (poskytnuta ): Obsah dotazu není zcela zřejmý, nicméně pokud dotaz směřuje na certifikační autoritu, zadavatel sděluje, že nepreferuje žádnou z certifikačních autorit. Dotaz č. 17 (obdržen ): INP_016 požaduje "zjištění existence souboru, kopírování, mazání, přesun, přejmenování, výpis souborů v adresáři, načtení vlastností souboru." Nejedná se o standardní operace využitelné při běžných flow ESB tak, jak je popisují EAI - jinými slovy nejde o standardní mediaci zpráv, ale spíše o operace potřebné v rámci business procesů. Dotaz 17.1.: Je možné specifikovat, které rozhraní a za jakým účelem je využívá? Dotaz 17.2.: Pro operace podobného typu doporučujeme využití business process platformy např. na bázi BPEL, která však není součástí zadání. Trvá Zadavatel na tomto funkčním požadavku i v rámci standardní ESB platformy? Odpověď na dotaz č. 17 (poskytnuta ): Ad 17.1.: Na tomto požadavku Zadavatel trvá. Jsme si vědomi, že se nejedná o standardní operace dle EAI, nicméně se domníváme, že většina současných platforem podporuje file adaptér, přes který je možné pracovat se soubory a provádět základní operace. Konkrétně se jedná o službu MailDatacom, která slouží pro přenos datových souborů z OJ (Organizační jednotka) v podobě e mailových příloh na Ředitelství LČR s uložením do definované adresářové struktury na sdíleném disku. Ad 17.2: Zadavatel na tomto požadavku s ohledem na své potřeby trvá. Dotaz č. 18 (obdržen ): Můžete specifikovat, pro jaká rozhraní je potřebná podpora protokolu TFPT? Jedná se o protokol nezabezpečený s velmi omezenou funkcionalitou používaný zejména v HW komponentách síťových zařízení, čemuž neodpovídá žádné z rozhraní uvedených v Příloze 2 Technické specifikace. Existuje důvod pro jeho využití namísto standardního FTP? Nejedná se o překlep a záměnu s SFTP? Odpověď na dotaz č. 18 (poskytnuta ): Zadavatel uvádí, že se jedná o chybu v psaní, správná formulace je SFTP, resp. zabezpečené FTP. Dotaz č. 19 (obdržen ): Můžete specifikovat využití registru služeb UDDI v rámci systémového prostředí Lesy ČR? Odpověď na dotaz č. 19 (poskytnuta ): Zadavatel (i přes nevyužívání v současném stavu) považuje UDDI za standard všeobecně využívaný pro správu webových služeb jak z pohledu této veřejné zakázky, tak i s ohledem na budoucí stav, s kterým zadavatel zamýšlí pracovat. Dotaz č. 20 (obdržen ): Specifikujte prosím pojem "funkční objektový model"

9 Odpověď na dotaz č. 20 (poskytnuta ): Jedná se o funkční a objektový model. Zadavatel požaduje dodání funkčního modelu tedy modelu propojení funkcí systému (tzv. Function model/diagram) a Zadavatel současně požaduje dodání objektového modelu tedy modelu objektů a jejich vlastností (tzv. Object model/diagram). Dotaz č. 21 (obdržen ): NEF_023 - Chápeme požadavek správně tak, že Dodavatel garantuje, že dodaný produkt bude dopředně kompatibilní se všemi (i budoucími) verzemi infrastruktury, které poskytovatel infrastruktury bude podporovat, a to po celou dobu podpory produktu? Odpověď na dotaz č. 21 (poskytnuta ): Dodavatel nesmí v době dodání, a po dobu zajištění podpory provozu řešení, použít takové komponenty, kterým (v průběhu podpory provozu řešení Dodavatelem) ze strany jejich výrobce končí podpora. Dotaz č. 22 (obdržen ): NEF_029 - V jakém formátu požaduje Zadavatel zpřístupnění datového modelu? Jaké SW vybavení má k dispozici? Odpověď na dotaz č. 22 (poskytnuta ): Zadavatel nedefinuje požadavky na formát dodaného datového modelu. Datový model musí být čitelný a zobrazitelný v rámci běžně dostupných aplikací (např. kancelářských aplikací MS Office, formátu PDF, případně v neplacené verzi nástroje/prohlížeče, ve kterém je datový model vytvořen apod.). Dotaz č. 23 (obdržen ): NEF_044 - Zadavatel nepřipouští dodatečné úpravy standardního SW a zároveň požaduje lokalizaci rozhraní a sestav, které budou uzpůsobeny podmínkám, prostředí a požadavkům Zadavatele. Trvá Zadavatel na platnosti druhého odstavce kapitoly 2 Technické specifikace? Je s požadavkem NEF_044 v rozporu. Odpověď na dotaz č. 23 (poskytnuta ): Uživatelská rozhraní jsou požadována v českém jazyce, administrátorské rozhraní je možné dodat v anglickém jazyce. Obecně Zadavatel požaduje českou lokalizaci rozhraní v případech, kdy bude mít systém interakci s koncovým uživatelem. Nejedná se o rozpor zadavatel požaduje, aby lokalizace uživatelských výstupů byla prováděna prostřednictvím konfigurace a nastavení standardního SW. Dotaz č. 24 (obdržen ): Dotaz ke smlouvě: V odstavci uvádíte: V rámci kategorizace vad a stanovování výsledků akceptačního řízení je nepřípustné vady nebo nedodělky jakkoliv sdružovat nebo slučovat (např. 2 totožné vady kategorie B nelze považovat za 1 vadu kategorie B apod.). Kategorizaci vad předávaného Plnění ve smyslu bodu Smlouvy stanovuje při akceptačním řízení výhradně Objednatel. DOTAZ: Znamená tento bod, že když 2 testeři zalogují stejnou chybu, bude započítána 2x?

10 Odpověď na dotaz č. 24 (poskytnuta ): Testování bude probíhat kontinuálně v několika fázích, přitom platí: totožná vada zjištěná ve dvou různých fázích testování (tedy od minule neopravená) = 2 vady, totožná vada zjištěná na několika místech v rámci jedné fáze testování = 1 vada. Dotaz č. 25 (obdržen ): Dotaz ke smlouvě: V odstavci 9.1 uvádíte: Poskytovatel prohlašuje, že vlastnické právo a nebezpečí škody na věci ke všem hmotným součástem plnění předmětu Smlouvy předaným Poskytovatelem Objednateli v souvislosti s plněním předmětu Smlouvy (zejména Cílový koncept) přechází na Objednatele dnem jejich předání Objednateli. DOTAZ: Ke kterým konkrétním hmotným součástem plnění se vztahuje tento bod. Předpokládáme, že v rámci této VZ se o žádnou takovou součást nejedná, prosíme o potvrzení naší domněnky. Odpověď na dotaz č. 25 (poskytnuta ): Zadavatel k tomuto dotazu uvádí, že dotaz se vztahuje k obecnému smluvnímu pravidlu ohledně vlastnického práva a nebezpečí škody na věci, přičemž tato problematika je v závazném návrhu smlouvy upravena komplexně a odpovídá požadavkům a potřebám zadavatele. Pokud tedy dodavatelem předávané plnění bude zahrnovat složku, která má hmotnou součást, přejde na zadavatele vlastnické právo k takovému hmotnému substrátu. Dotaz č. 26 (obdržen ): Dotaz ke smlouvě: V odstavci uvádíte: Současně Poskytovatel uděluje Objednateli souhlas ode dne účinnosti poskytnuté Licence dle Smlouvy provádět jakékoliv modifikace, úpravy, změny Autorského díla a dle svého uvážení do něj zasahovat, zapracovávat jej do dalších autorských děl, zařazovat jej do děl souborných či do databází apod., a to i prostřednictvím třetích osob. DOTAZ: Jak se bude posuzovat neodborný zásah zadavatele do akceptovaného plnění, pokud se po nasazení do produkčního prostředí objeví chyby? Vztahuje se na takové chyby záruka a SLA? Odpověď na dotaz č. 26 (poskytnuta ): Koncepce záruky a odstraňování vad je v závazném návrhu smlouvy upravena komplexně a odpovídá požadavkům a potřebám zadavatele. Zadavatel k tomu obecně doplňuje (aniž by předjímal interpretaci v jednotlivých případech dle konkrétních podmínek), že pokud by bylo v konkrétním případě bez nejmenších pochybností prokázáno, že chyba (vada) plnění či jeho části dodaného poskytovatelem byla skutečně způsobena neodborným zásahem zadavatele, pak se nejedná o vadu, která je kryta zárukou a stanovenými SLA. Dotaz č. 27 (obdržen ): K požadavku INP_023 (Registr služeb) V požadavku INP_023 je požadována podpora UDDI registru služeb. Standard UDDI je postupně

11 hlavními dodavateli platforem ESB opouštěn. Moderní produkty ESB přechází na specifikaci S- RAMP. Je přípustné implementovat registr služeb pouze s podporou S-RAMP namísto UDDI? Uchazeč je na základě své zkušenosti s řadou integračních projektů a se souvisejícími technologiemi přesvědčen, že striktní trvání Zadavatele na požadavku na podporu UDDI by diskvalifikovalo mnoho kvalitních produktů vhodných pro poptávané řešení. Odpověď na dotaz č. 27 (poskytnuta ): Zadavatel trvá na podpoře UDDI. Zadavatel nicméně nepožaduje implementaci prostřednictvím UDDI. UDDI je obsažen ve většině nabízených standardních produktů IP a je podporován daleko větší skupinou produktů než tazatelem uváděný S-RAMP (z časového hlediska to je poměrně mladý standard). Zadavatel samozřejmě připouští, aby dodané řešení navíc podporovalo i standard S-RAMP. Dotaz č. 28 (obdržen ): K požadavku INP_034 (Vývojové prostředí) V požadavku INP_034 Zadavatel specifikuje, že "Pro vývoj integračních rozhraní musí IP (ESB) obsahovat nebo podporovat grafické uživatelské rozhraní umožňující vývoj, ladění (testování) a simulaci jednotlivých integračních propojení. Toto grafické uživatelské rozhraní musí být kompatibilní minimálně s následujícími operačními systémy: MS Windows XP, Vista, 7, 8 a 8.1, a to ve všech edicích těchto uvedených verzí, s výjimkou edicí, které jsou výrobcem určené pro domácí použití (např. Home edice apod.) a které nejsou volně dostupné (např. Starter edice apod.); Linux, distribuce Ubuntu, Fedora, Debian a OpenSUSE, a to v posledních dostupných verzích k datu předání předmětu plnění této veřejné zakázky Zadavateli." Uchazeč spatřuje v těchto požadavcích možný rozpor s technologickými standardy zadavatele tak, jak je uvádí v "Příloze č. 4" Přílohy č. 1 ZD, a žádá tedy Zadavatele o upřesnění, jak správně chápat požadavek INP_034. Odpověď na dotaz č. 28 (poskytnuta ): Příloha č. 4 definuje pouze požadavky na produkční serverové prostředí. INP_034 definuje požadavky na vývojové stanice. Dotaz č. 29 (obdržen ): K požadavku NEF_006 (Návrh a implementace řešení v souladu s technologickými standardy Zadavatele) Dotaz 29.1.: Uchazeč se domnívá, že v odkazu na Technologické standardy ("Návrh a implementace řešení musí být zajištěna v souladu technologickými standardy Zadavatele uvedenými v příloze č. 3 tohoto dokumentu.) má být správně uvedena příloha č. 4. Příloha č.3 obsahuje "Seznam požadovaných projektových výstupů". Dotaz 29.2.: Pokud je tomu tak, znamená to, že dodavatel musí jako databázi zvolit pouze MS SQL Server 2012 a vyšší nebo Oracle 12c a vyšší? Dotaz 29.3.: Je možné, aby dodávané řešení využilo některou z již případně existujících databází Uchazeče? Dotaz 29.4.: Je možné v řešení využít některé ze současně existujících licencí Zadavatele?

12 Dotaz 29.5.: S ohledem na ochranu předchozích investic, které Zadavatel vynaložil na pořízení stávající technologické platformy (a snahu o jejich hospodárné využití) Uchazeč předpokládá, že Zadavatel uvítá maximální využití své stávající SW infrastruktury. V této souvislosti žádá Uchazeč Zadavatele, aby obdobně tak, jako uvedl pokrytí licencemi Microsoft CAL v rámci Dodatečných informací č. 2 / bodu dodatečná inf. č. 4, uvedl seznam databázových licencí, kterými disponuje a je možno je případně v rámci nabízeného řešení využít. Rovněž žádá o informaci, do jakého data zadavatel má hrazenu licenční technickou podporu k takovýmto licencím a zda předpokládá, že ji (s ohledem na využití příslušných licencí i pro jiné účely) bude hradit i nadále mimo rozpočet tohoto projektu, nebo zda cena podpory k těmto licencím od určitého data má být součástí nabídkové ceny. Odpověď na dotaz č. 29 (poskytnuta ): Ad 29.1.: Zadavatel potvrzuje, že se jedná o přílohu č. 4. Ad 29.2.: Využití řešení, které není v souladu s technologickými standardy uvedenými v Příloze č. 1 - Technické specifikaci, zadavatel nepřipouští. Ad 29.3.: Takové řešení zadavatel nepřipouští. Ad 29.4.: Pro účely této veřejné zakázky není možné využít žádné existující licence zadavatele. Ad 29.5.: Pro účely této veřejné zakázky není možné využít žádné existující databázové licence zadavatele. Dotaz č. 30 (obdržen ): K požadavku NEF_044 (jazyková verze řešení) V požadavku NEF_044 Zadavatel uvádí, že "Řešení musí být plně dostupné v českém jazyce (tj. všechny uživatelská rozhraní, sestavy, výstupy, nápovědy, dokumentace apod.)." Uchazeč žádá upřesnění, jak požadavek NEF_044 chápat v kontextu integrační platformy. Velké množství vhodných technologií neobsahuje například administrátorské rozhraní v českém jazyce. Týká se požadavek např. i administrátorského uživatelského rozhraní aplikačního serveru a FSW, nebo toto může být v anglickém jazyce, pokud výstupy typu reporty, nápověda a dokumentace budou k dispozici v češtině. Odpověď na dotaz č. 30 (poskytnuta ): Uživatelská rozhraní jsou požadována v českém jazyce, administrátorské rozhraní je možné dodat v anglickém jazyce. V případě, kdy bude mít systém interakci s koncovým uživatelem, je nutné, aby disponoval českou lokalizací právě pro tyto interakce. Dotaz č. 31 (obdržen ): K požadavku NEF_045 (Doba podpory komponent řešení) V požadavku NEF_045 Zadavatel uvádí, že "Dodavatel musí zajistit, že navrhované SW proprietární komponenty řešení musí být v době nasazení řešení do provozu na straně Zadavatele podporovány výrobcem SW komponenty." Může Zadavatel upřesnit, co chápe pod pojmem "proprietární komponenty"?

13 Odpověď na dotaz č. 31 (poskytnuta ): Proprietární komponenty představují komponenty potřebné pro provoz řešení, tzn. například operační systémy, databázové systémy, podpůrné SW nástroje atp. Dotaz č. 32 (obdržen ): K požadavku NEF_048 (Loadbalancing) V požadavku NEF_048 Zadavatel uvádí, že "IP musí být schopna pracovat v režimu vyvažování zátěže (tzv. load balancing), tzn., že nesmí dojít k zastavení systému při jakémkoli selhání jakékoliv SW nebo většiny HW komponent. Tímto není myšleno řešení výpadku HW serveru." Dotaz 32.1.: Požaduje Zadavatel implementaci v režimu vyvažování zátěže, nebo pouze řešení kompatibilní s budoucím přechodem na Load Balancing? Dotaz 32.2.: Disponuje Zadavatel prostředky (např. síťové prvky), které Load Balancing umožňují a lze tyto prvky případně využít pro dodávané řešení? Odpověď na dotaz č. 32 (poskytnuta ): Ad 32.1.: Dodané řešení musí být kompatibilní s budoucím přechodem na Load Balancing. Ad 32.2.: HW/SW infrastruktura zadavatele je plně kompatibilní s principy Load Balancingu. Zadavatel umožňuje využití této infrastruktury. Dotaz č. 33 (obdržen ): K požadavku NEF_049 (High Availability) V požadavku NEF_049 Zadavatel uvádí, že "Dodané řešení musí umožňovat automatické a transparentní převzetí služeb (tzv. failover sending) při selhání. Režim HA a load balancing jsou požadovány vždy v rámci každé geografické lokality." Dotaz 33.1.: Požaduje Zadavatel implementaci v režimu HA, nebo pouze řešení kompatibilní s budoucím přechodem na HA? Dotaz 33.2.: Do kolika lokalit předpokládá Zadavatel nasazení poptávané integrační platformy? Jak jsou tyto lokality propojeny? Odpověď na dotaz č. 33 (poskytnuta ): Ad 33.1.: Dodané řešení musí být kompatibilní s režimem High-availability. Ad 33.2.: Vysokou dostupnost požaduje režimu v Active/Passive. Infrastruktura zadavatele je rozdělena mezi dvě datová centra a požaduje, aby při výpadku jednoho datového centra bylo možná provést obnovu systému v druhém datovém centru a došlo jen k minimální ztrátě dat (např. neuložené transakce). Dotaz č. 34 (obdržen ): K požadavku NEF_052 (Instalace a zprovoznění) V požadavku NEF_052 Zadavatel uvádí, že "Dodavatel provede instalaci, konfiguraci a zprovoznění celého předmětu plnění této veřejné zakázky v prostředí Zadavatele, a to na všech serverech určených Zadavatelem pro plnění této veřejné zakázky." Uchazeč žádá o upřesnění, na která prostředí má bý řešení instalováno, konfigurováno a zprovozněno (jaká je infrastruktura pro

14 testovací a provozní prostředí). Odpověď na dotaz č. 34 (poskytnuta ): HW infrastruktura pro testovací a produkční/provozní prostředí je definována v kapitole 1.2 přílohy č. 1 Technické specifikaci. V rámci této infrastruktury bude nastaveno virtuální prostředí dle specifikace dodávaného řešení (pro obě prostředí testovací i produkční/provozní). Dotaz č. 35 (obdržen ): Ke kapitole č. 2 ZD - Architektura Zadavatel v ZD uvádí, že "Veškeré požadavky uvedené v této kapitole a jejích podkapitolách musí nabízené řešení podporovat jako svou standardní běžně dostupnou součást/vlastnost nepřipouští se splnění těchto požadavků formou dodatečných úprav standardizovaného (generického) produktu." Uchazeč žádá o upřesnění, zda zadavatel připouští v kontextu tohoto požadavku možnost, aby bylo výsledné řešení integrační platformy postaveno na více standardizovaných produktech, případně produktech od více různých dodavatelů? Odpověď na dotaz č. 35 (poskytnuta ): Ano, více standardizovaných produktů, případně produkty od více dodavatelů zadavatel připouští. Dotaz č. 36 (obdržen ): K implementovaných službám Technická specifikace uvádí výčet již realizovaných služeb ESB. Dotaz 36.1.: Uchazeč žádá o informaci, v jaké technologii jsou služby realizovány. Tuto informaci potřebuje Uchazeč pro vyčíslení nákladů na převod služeb do integrační platformy. Dotaz 36.2.: Uchazeč rovněž žádá o informaci, zda budou vybranému dodavateli poskytnuty zdrojové kódy současných služeb. Odpověď na dotaz č. 36 (poskytnuta ): Ad 36.1.: Zadavatel požaduje dodání Integrační platformy bez možností využití částí nebo celého stávajícího řešení. Jedná se technologii Oracle Service Bus 11 pro webové služby a Oracle SOA Suite 11 pro BPEL procesy, kdy v Příloze č. 1 je uvedeno (v kapitole č. 1.1 Popis stávajícího řešení) následující: Oracle Service Bus Oracle SOA Suite 11g Ad 36.2.: Zdrojové kódy současných služeb nebudou vybranému dodavateli poskytnuty. Dotaz č. 37 (obdržen ): K architektuře (požadavek NEF_041) Dotaz 37.1.: V požadavku NEF_041 je uvedena preference využití vícevrstvé architektury. Uchazeč žádá o upřesnění, co Zadavatel považuje v kontextu integrační platformy za prezentační vrstvu. Dotaz 37.2.: V hodnotících kritériích C "Nároky na HW infrastrukturu zadavatele" je v bodu B preferován co nejnižší počet fyzických či virtuálních serverů. Dle názoru Uchazeče jde toto hodnotící

15 kritérium proti zmíněnému požadavku na vícevrstvou architekturu. Minimalizace počtu serverů by vedla ke snížení zabezpečení řešení a nevhodnému návrhu architektury. Může Zadavatel upřesnit, jak chápat požadavek na vícevrstvou architekturu v kontextu zmíněného hodnotícího kritéria, které naopak preferuje co nejnižší počet serverů? Odpověď na dotaz č. 37 (poskytnuta ): Ad 37.1.: Prezentační vrstvou integrační platformy zadavatel rozumí vrstvu uživatelského rozhraní, která je v rámci požadovaného řešení odpovědná za (a umožňuje) interakci s obsluhou integrační platformy. Prezentační vrstva tedy zajišťuje správu/konfiguraci/nastavení integrační platformy a veškerých služeb/rozhraní/konektorů v uživatelsky čitelné (a přívětivé) podobě. Ad 37.2.: Zadavatel preferuje co nejnižší počet fyzických či virtuálních serverů při současném využití vícevrstvé architektury. Cílem je zajištění efektivní konfigurace infrastruktury, tedy nikoliv předimenzované a nákladově náročné řešení. Dotaz č. 38 (obdržen ): Opensource Připouští Zadavatel v rámci řešení využití OpenSource produktů, ke kterým je poskytována podpora Dodavatelem? Připouští využití OpenSource produktů, ke kterým je poskytována podpora vývojářskou komunitou? Odpověď na dotaz č. 38 (poskytnuta ): Ano, Zadavatel připouští využití OpenSource produktů, ke kterým je poskytována podpora dodavatelem / vývojářskou komunitou. Informace č poskytnutá zadavatelem bez předchozí žádosti dle 49 odst. 4 ZVZ (poskytnuta ): Zadavatel oznamuje změnu specifického symbolu pro identifikaci platby v případě poskytnutí jistoty formou složení peněžní částky na účet zadavatele. V článku zadávací dokumentace uvedený specifický symbol zadavatel nahrazuje specifickým symbolem , což je evidenční číslo veřejné zakázky Dodávka a implementace integrační platformy ve Věstníku veřejných zakázek. Zadavatel žádá dodavatele, kteří již jistotu vztahující se k této veřejné zakázce na účet zadavatele složili s původně uvedeným specifickým symbolem , aby o tom zadavatele před koncem lhůty pro podání nabídek písemně informovali postačí em zaslaným na adresu 99_ozvz@lesycr.cz. (Pozn.: Původně uvedený specifický symbol se vztahuje k veřejné zakázce Dodávka a implementace informačního systému DMS.) Informace o prodloužení lhůty pro podání nabídek: S ohledem na povahu poskytnutých informací a rovněž s ohledem na skutečnost, že odpovědi na dotazy č jsou poskytovány jeden den po uplynutí příslušné lhůty pro poskytnutí dodatečných informací, přistoupil zadavatel k přiměřenému prodloužení lhůty pro podání nabídek na plnění shora uvedené veřejné zakázky následovně:

16 Zadavatel ruší termín konce lhůty pro podání nabídek stanovený na do 10,00 hodin a termín otevírání obálek s nabídkami původně stanovený na od 10,00 hodin a nově stanoví termín konce lhůty pro podání nabídek na do 10,00 hodin a termín otevírání obálek s nabídkami na od 10,00 hodin. S pozdravem Ing. Lenka Zahálková vedoucí odboru zadávání veřejných zakázek