21. srpna 2015 14:46 CN=Ing. Lenka Zahálková OU=99587, serialNumber=26 138 241 ISSUER CN=PostSignum Qualified CA 2
VÁŠ DOPIS ZN.
ČÍSLO JEDNACÍ
SPISOVÁ ZNAČKA
LCR099/39/00001783/2015
DATUM
21.8.2015
VYŘIZUJE
TELEFON
GSM
FAX
E-MAIL
Zahálková
956 999 203
724 623 712
495 262 391
[email protected]
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 508740 Zadavatel Lesy České republiky, s.p., se sídlem Přemyslova 1106/19, Nový Hradec Králové, 500 08 Hradec Králové, IČO: 42196451 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 7. 7. 2015): 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í :
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 10.7.2015): 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 10.7.2015 byl publikován na profilu zadavatele. Název upraveného dokumentu: „02 Příloha č. 1 ZD - Technická specifikace IP_úprava_20150710“. V souvislosti s podanou informací byla zadavatelem prodloužena lhůta pro podání nabídek – konec lhůty byl stanoven na 2.9.2015 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 31. 7. 2015): 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 31. 7. 2015 rovněž publikován na profilu zadavatele jako příloha č. 3 zadávací dokumentace – Úvodní list nabídky (vzor)_ver20150731. 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.
Informace č. 3 - poskytnutá zadavatelem bez předchozí žádosti dle § 49 odst. 4 ZVZ (poskytnuta 31. 7. 2015): 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í cenové 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 E-mail:
[email protected] Mob. +420 724 071 426 Building Alfa, BB Centrum, Vyskočilova 1461/2a, 140 00, Praha 4 Kontaktní osoba společnosti SoftwareONE Czech Republic, s.r.o.: Petr Pánek | BDM E-mail:
[email protected] Mob. +420 606 739 519 SoftwareONE Czech Republic, s.r.o., Želetavská 1448/7, 140 00 Praha 4 Informace č. 4 - poskytnutá zadavatelem bez předchozí žádosti dle § 49 odst. 4 ZVZ (poskytnuta 31. 7. 2015): 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 9.9.2015 do 10,00 hod. Tento termín už není aktuální – viz dále.
Dotaz č. 5 (obdržen 10. 8. 2015): 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 14.8.2015): 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 11. 8. 2015): 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 14.8.2015): 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
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 14. 8. 2015):
nové
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 21.8.2015):
nové
Č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 14. 8. 2015):
nové
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?
Odpověď na dotaz č. 8 (poskytnuta 21.8.2015):
nové
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 14. 8. 2015):
nové
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 21.8.2015):
nové
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 14. 8. 2015): nové 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 21.8.2015): nové 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 14. 8. 2015): nové 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 21.8.2015):
nové
Ne, moduly třetích stran lze považovat za standardní řešení. Dotaz č. 12 (obdržen 14. 8. 2015): nové Úč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
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 21.8.2015):
nové
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 14. 8. 2015): nové 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 21.8.2015):
nové
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 14. 8. 2015): nové 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 21.8.2015):
nové
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 14. 8. 2015): nové 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 21.8.2015):
nové
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 14. 8. 2015): nové Jaké certifikáty budou používány pro zajištění autentizace pomocí SSL?
Odpověď na dotaz č. 16 (poskytnuta 21.8.2015):
nové
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 14. 8. 2015): nové 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 21.8.2015): nové 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 14. 8. 2015): nové 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 21.8.2015):
nové
Zadavatel uvádí, že se jedná o chybu v psaní, správná formulace je SFTP, resp. zabezpečené FTP.
Dotaz č. 19 (obdržen 14. 8. 2015): nové Můžete specifikovat využití registru služeb UDDI v rámci systémového prostředí Lesy ČR? Odpověď na dotaz č. 19 (poskytnuta 21.8.2015):
nové
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 14. 8. 2015): nové Specifikujte prosím pojem "funkční objektový model"
Odpověď na dotaz č. 20 (poskytnuta 21.8.2015): nové 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 14. 8. 2015): nové 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 21.8.2015):
nové
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 14. 8. 2015): nové 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 21.8.2015): nové 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 14. 8. 2015): nové 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 21.8.2015): nové 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 14. 8. 2015): nové Dotaz ke smlouvě: V odstavci 6.2.7 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 6.2.5 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?
Odpověď na dotaz č. 24 (poskytnuta 21.8.2015): nové 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 14. 8. 2015): nové 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 21.8.2015): nové 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 14. 8. 2015): nové Dotaz ke smlouvě: V odstavci 9.2.4 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 21.8.2015): nové 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 17. 8. 2015): nové 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ě
hlavními dodavateli platforem ESB opouštěn. Moderní produkty ESB přechází na specifikaci SRAMP. 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 21.8.2015):
nové
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 17. 8. 2015): nové 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 21.8.2015): nové 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 17. 8. 2015): nové 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?
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 21.8.2015): nové 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 17. 8. 2015): nové 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 21.8.2015): nové 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 17. 8. 2015): nové 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"?
Odpověď na dotaz č. 31 (poskytnuta 21.8.2015):
nové
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 17. 8. 2015): nové 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 21.8.2015): nové 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 17. 8. 2015): nové 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 21.8.2015): nové 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 17. 8. 2015): nové 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
testovací a provozní prostředí). Odpověď na dotaz č. 34 (poskytnuta 21.8.2015): nové 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 17. 8. 2015): nové 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 21.8.2015): nové Ano, více standardizovaných produktů, případně produkty od více dodavatelů zadavatel připouští.
Dotaz č. 36 (obdržen 17. 8. 2015): nové 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 nové 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 21.8.2015):
nové
Ad 36.1.: Zadavatel požaduje dodání nové 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 10.3.1.0 Oracle SOA Suite 11g 11.1.1.4.0 Ad 36.2.: Zdrojové kódy současných služeb nebudou vybranému dodavateli poskytnuty. Dotaz č. 37 (obdržen 17. 8. 2015): nové 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í
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 21.8.2015):
nové
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 17. 8. 2015): nové 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 21.8.2015): nové Ano, Zadavatel připouští využití OpenSource produktů, ke kterým je poskytována podpora dodavatelem / vývojářskou komunitou. Informace č. 39 - poskytnutá zadavatelem bez předchozí žádosti dle § 49 odst. 4 ZVZ (poskytnuta 21. 8. 2015): nové 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 15.2. zadávací dokumentace uvedený specifický symbol 508744 zadavatel nahrazuje specifickým symbolem
508740, 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 508744, aby o tom zadavatele před koncem lhůty pro podání nabídek písemně informovali – postačí e-mailem zaslaným na adresu
[email protected]. (Pozn.: Původně uvedený specifický symbol 508744 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: nové S ohledem na povahu poskytnutých informací a rovněž s ohledem na skutečnost, že odpovědi na dotazy č. 7 – 26 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ě:
Zadavatel ruší termín konce lhůty pro podání nabídek stanovený na 9. 9. 2015 do 10,00 hodin a termín otevírání obálek s nabídkami původně stanovený na 9. 9. 2015 od 10,00 hodin a nově stanoví termín konce lhůty pro podání nabídek na 14. 9. 2015 do 10,00 hodin a termín otevírání obálek s nabídkami na 14. 9. 2015 od 10,00 hodin.
S pozdravem Ing. Lenka Zahálková vedoucí odboru zadávání veřejných zakázek
