Odpov di na dotazy uchaze
k ve ejné zakázce . 58/2012-17-27
„Vytvo ení registru individuálních kont pojišt nc “
1. Zajistí vytvo ení systému EDS-A zadavatel? (P íloha 1 ZD, kapitola 1 a 3.5) Zadavatel EDS-A nezajistí, EDS-A je sou ástí dodávky v rámci této ve ejné zakázky. 2. Jaká je používaná ESB platforma? Biz Talk 3. Dochází k publikování zm n v DB_INP prost ednictvím ESB? Ne. 4. Dotazování do aplikací DB_IVK, EDS-A, KE, DB_WORK je možné prost ednictvím ESB? Ano. 5. Je k dispozici algoritmus pro klasifikaci dokladu z DB_INP? Ano, bude poskytnut vít zi výb rového ízení. 6. Jaké rozhraní využívá systém WORK pro zápis nových požadavk ? Ru ní nahrání pracovníky provozu. 7. Je možné získat schéma ze strany 14 p ílohy 1 v podob se íslováním akcí odpovídajícím vysv tlivkám na stran 15? Ano, viz p íloha (soubor schéma_IKP.pdf). 8. Jaká je sou asná velikost databáze DB_INP? 43 GB 9. Kolik relevantních doklad pro prvotní migraci obsahuje databáze DB_INP? 144 mil. k 5/2012 10. Jaký po et sou asn pracujících uživatel s aplikací APV_IKP je požadován? 300 uživatel 11. Jaká je požadovaná doba odezvy aplikace? On–line (okamžité zobrazení dat o konkrétním p ípadu) 12. Jaká je požadovaná dostupnost systému IKP? 7 x 24 13. Jaká jsou požadovaná SLA systému IKP? Min. 99% 14. Jak velký je p ír stek doklad za jednotku asu v DB_INP? 10mil./rok 15. Dodání aplikace popsané v P íloze 1 kapitole 3.2.1 je ve scope projektu? Ano. 16. Zajistí úpravy systému APV_IVP popsané v p íloze 1, kapitole 3.2.4 bod 2 zadavatel? APV_IVP nefiguruje v Zadávací dokumentaci. 17. Testovací aplikace popsaná v p íloze 1, kapitole 3.2.4 bod 2 je ve scope projektu? Ano. 18. Úpravy modulu pro generování IVK(IODLP) popsaná v p íloze 1 ZD, kapitole 3.2.4 bod ** zajistí zadavatel (krom analytických prací)? Ne, je sou ástí této zakázky.
19. Lze p edpokládat možnost p ímého online p ístupu z aplikace APV_IKP do databáze DB_IVK nap íklad pro zobrazení automatizovan sestavených IVK nebo je nutné tato data replikovat? viz ZD, schéma krok . 16,17 20. Je možné získat rozhraní a popis systému PRESS? Popis bude poskytnut vít zi výb rového ízení 21. Zajistí úpravy systému APV PNP, UIP popsané v p íloze 1 ZD, kapitole 3.2.5 zadavatel? Ano. 22. Je možné získat popis modulu JDV01 zmi ovaného v p íloze 1 ZD, kapitole 3.3? Popis bude poskytnut vít zi výb rového ízení 23. Je možné získat popis systému WORK? opis bude poskytnut vít zi výb rového ízení 24. Realizace úprav systému WORK, jejichž pot eba vznikne z analytických prací dle p ílohy 1 ZD, kapitoly 3.4 zajistí zadavatel? Ne, je sou ástí této zakázky.
Bc. Ludmila Hnutová Odd lení resortního zadávání ve ejných zakázek
2
Odpov di na dotazy uchaze
k ve ejné zakázce . 58/2012-17-27
„Vytvo ení registru individuálních kont pojišt nc “
Dotaz: V zadávací dokumentaci požaduje zadavatel v kap. 3, bodu b) Seznam technik – realiza ní tým prokázat odbornost uchaze e na pozici bezpe nostní specialista certifikátem CISM. Certifika ní spole nost ISACA certifikuje odborníky v oblasti bezpe nosti a auditu srovnatelným certifikátem CISA. Uchaze má v úmyslu p edložit na tuto pozici specialistu s požadovanými zkušenostmi, který je držitelem certifikátu CISA. Uzná zadavatel k prokázání tohoto požadavku osobu s tímto certifikátem? Odpov : Nikoliv, zadavatel trvá na certifikátu CISM.
Bc. Ludmila Hnutová Odd lení centrálního zadávání ve ejných zakázek
Odpov di na dotazy uchaze
k ve ejné zakázce . 58/2012-17-27
„Vytvo ení registru individuálních kont pojišt nc “
Dotaz: Zadavatel v kapitole 3.3.5 Zadávací dokumentace ve ejné zakázky „Vytvo ení registru individuálních kont pojišt nc “ uvádí, že každá licence musí být poskytnuta i ud lena jako výhradní. Sou ástí ešení nicmén mohou být licencované standardní produkty i jejich komponenty/ ásti, u nichž by bylo ud lení výhradní licence v p ímém rozporu s licen ním ujednáním k t mto produkt m. Uchaze se tedy ptá, zda v souladu s obecn platnými pravidly pro ud lování licencí ke standardnímu software a jeho komponent m/ ástem nep ehodnotí zadavatel tento požadavek tak, aby požadavek na ud lení licence byl v ZD zm n na poskytnutí i ud lení licence nevýhradní. Všechny ostatní požadavky specifikované v rámci této kapitoly 3.3.5 ZD mohou být zachovány beze zm ny. Ud lení nevýhradní licence nijak neomezuje práva Zadavatele na využívání vyvinutého software, možnost získání zdrojových kód , jejich postoupení svému právnímu zástupci apod. jak je požadováno v kapitole 3.3.5 ZD. Odpov : Poskytnutí i ud lení licencí pro licencované standardní a obecn komponenty není vyžadováno jako výhradní.
používané produkty nebo
Dotaz: Zadavatel v zadávací dokumentaci v ásti VII. „Požadavky na prokázání kvalifikace“ vyžaduje, aby sou ástí realiza ního týmu byl „Bezpe nostní specialista“, který musí být držitelem certifikátu CISM (Certified Information Security Manager) vydaný v souladu s požadavky normy ISO/IEC 17024. Uchaze se tedy ptá, zda bude uznán i obdobný certifikát jiné certifika ní autority CISSP (Certified Information Systems Security Professional)? CISSP je taktéž vydaný a spl uje požadavky normy ANSI/ISO/IEC standardu 17024. Odpov : Certifikát CISSP jako alternativu k CISM zadavatel uzná.
Dotaz: Je sou ástí požadované ceny cena za technickou podporu? Pokud ano, sta í m sí ní sazba nebo je požadována nabídka na delší období, nap . na 3 roky? Odpov : Sou ástí nabídkové ceny je technická podpora po dobu 3 m síc produk ního prost edí zadavatele.
od nasazení dodaného ešení do
Bc. Ludmila Hnutová Odd lení centrálního zadávání ve ejných zakázek
Odpov di na dotazy uchaze
k ve ejné zakázce . 58/2012-17-27
„Vytvo ení registru individuálních kont pojišt nc “
Dotaz: že zadavatel poskytnout infrastrukturu systému z d vodu požadavku co nejv tšího p iblížení ešení ke stávajícím technologiím zadavatele? Odpov : Infrastruktura systému bude poskytnuta vít zi ve ejné zakázky. Dotaz: že zadavatel objasnit d vody barevného ozna ení v grafickém schématu v P íloze 1 ZD na stran 14, jelikož z textu není patrné, pro tomu tak je. P ípadn potvrdit, že pro vytvo ení nabídky je tato informace irelevantní? Odpov : Potvrzujeme, že barevné odlišení je pro vytvo ení nabídky irelevantní. Dotaz: V zadávací dokumentaci v ásti V. „zadavatel požaduje zahájení pln ní ve ejné zakázky do p ti dn ode dne podepsání smlouvy o dílo s vybraným uchaze em a dokon ení pln ní p edm tu VZ nejpozd ji do 9 m síc od nabytí právní ú innosti smlouvy (zahájení projektu).“ Datum zahájení projektu lze takto chápat jako datum nabytí právní ú innosti smlouvy. V ásti IV. ZD bod p) je požadováno, aby uchaze ve smlouv uvedl „ustanovení, podle kterého nabývá smlouva platnosti ke dni podpisu smlouvy a ú innosti ke dni, kdy bude uchaze i ze strany zadavatele doru eno oznámení, že zadavateli bylo schváleno stanovení výdaj financování akce ze státního rozpo tu ….“ edpokládá uchaze správn , že pro nabytí ú innosti smlouvy platí ustanovení v ásti IV.ZD bod p), tj. že „smlouva nabývá platnosti ke dni podpisu a ú innosti ke dni, kdy bude uchaze i ze strany zadavatele doru eno oznámení, že zadavateli bylo schváleno stanovení výdaj financování akce ze státního rozpo tu“ a tuto textaci m že uchaze takto uvést ve smlouv o dílo? Od data doru ení tohoto oznámení (tj. nabytí ú innosti smlouvy) by se pak po ítalo požadovaných 9 m síc pro ukon ení pln ní p edm tu VZ? Odpov : Ano, p edpoklad uchaze e je správný. Dotaz: Zajistí úpravy systému APV-UIP popsané v p íloze 1, kapitole 3.2.4 bod 2 ZD zadavatel? Odpov : Ne, je sou ástí této zakázky. Dotaz: V ZD, ást V, je specifikována etapa 2 následujícím textem: „Etapa . 2. Vytvo ení funk ního prototypu Registru IKP pro podporu:“ Bližší specifikace za dvojte kou chybí. Žádáme o dopln ní. Odpov : Dvojte ka nem la být uvedena, v ta nemá pokra ování.
Dotaz: V zadávací dokumentaci v p íloze . 2, kapitola 6 – Požadavky na výpo etní výkon je uvedeno, že uchaze má stanovit nároky na výkon databáze a využití diskové kapacity. M žete poskytnout HW specifikaci databáze (název a typ server a název a typ CPU), verzi DB, v etn option, které lze využít (Partitioning, RAC,…) a typ datového úložišt . Odpov : Informace ohledn HW, DB a typu datového úložišt budou poskytnuty vít zi výb rového ízení. Dotaz: žete specifikovat pr rný po et zm n za jednotku asu ve zdrojových systémech, které jsou relevantní pro registr IKP? a) Po et zm nových v t v KE za den? b) Po et p edpokládaných zm nových v t v EDS-A za den? c) Po et zm nových v t v systému WORK za den? Odpov
:
a) ádov desetitisíce denn b) U b žných zm n jde o desetitisíce, u valoriza ních zm n o statisíce p ípad denn c) ádov desetitisíce denn
Bc. Ludmila Hnutová Odd lení centrálního zadávání ve ejných zakázek
2
Odpov di na dotazy uchaze
k ve ejné zakázce . 58/2012-17-27
„Vytvo ení registru individuálních kont pojišt nc “
1. Jedním z kritérií hodnocení je dle bodu 10.3.2 zadávací dokumentace soulad technického ešení s konceptem IIS zadavatele. K dosažení souladu je pot ebná dokumentace, ve které je tento koncept popsán. Pro kvalifikované posouzení žádáme Zadavatele o poskytnutí dokumentace koncepce IIS. Koncept IIS bude poskytnut až vít zi ve ejné zakázky. 2. Má zadavatel k dispozici centrální ešení pro reporting? Pokud ano, žádáme uvést, o jaké ešení se jedná. Lze toto ešení využít pro pot eby projektu, nebo je pot ebné použít vlastní nástroje reportingu? Pokud je reportingem mín no zpracování statistik, pak SSZ žádný centrální nástroj pro jejich tvorbu nemá. 3. Dle funk ní specifikace je sou ástí ešení reporting. Jaký je p edpokládaný rámcový po et report ? Viz kapitola 3.2.1, p íloha . 1 ZD 4. Co je uvažováno jako posta ující funk ní prototyp ešení, který je výstupem etapy 2. Žádáme specifikaci podmnožiny funkcionality ešení, které má tento prototyp spl ovat. Má již v této etap být pln integrován na ostatní systémy? Bude up esn no v rámci Etapy . 1. „Analýza a návrh ešení“. 5. V jakém prost edí (vývojové, testovací, integra ní prost edí) má být funk ní prototyp realizován? V integra ním i testovacím prost edí. 6. Budou úpravy na stran spolupracujících systém financovány Zadavatelem na základ definované sou innosti nebo je má Dodavatel kalkulovat v nabízené cen ? Úpravy spolupracujících systém , vynucené realizací Registru IKP, jsou sou ástí této Ve ejné zakázky. 7. Pokud má Dodavatel kalkulovat úpravy stávajících systému v nabízené cen , žádáme o kontakt na dodavatele stávajících systém , kterých se týká integrace se systémem IKP. Kontakt nebude poskytnut. 8. Rozumí se Etapou 4. Realizací služeb Pilotní provoz po dobu t í m síc nebo má být pilot zahájen až po 4. Etap ? Pilotní provoz bude zahájen v rámci 4. Etapy. 9. V rámci dodávky má být vytvo en systém EDS-A jako sada služeb pro p ístup do databází na Mainframe. Má Zadavatel k dispozici standardní programové vybavení pro p ístup k t mto databázím? Pokud ano, žádáme uvést, o jaké programové vybavení se jedná. Standardní programové vybavení pro p ístup k databázím na Mainframe SSZ nemá, p ístup pro EDS-A bude vytvo en v rámci této zakázky. 10. V zadávací dokumentaci v ásti IV. Obchodní podmínky ve ejné zakázky v odst. 1 písm. m) se zadavatel odkazuje na bližší požadavky k pojišt ní odpov dnosti za škodu na ást VI. odst. 3 zadávací dokumentace. V zadávací dokumentaci se však tento bod nenachází, resp. v ásti VI. Sou innost bodu 3 je zmín na Legislativní sou innost, kde podrobnosti k pojišt ní odpov dnosti za škodu nejsou uvedeny. Mohl by zadavatel tedy blíže specifikovat povinnosti uchaze e k pojišt ní odpov dnosti za škodu? Bližší požadavky k pojišt ní odpov dnosti za škodu se nacházejí v ásti VII, odst. 3a.
11. Jakým zp sobem se p edpokládá p enos zm n vybraných údaj z mainframe d chodových systém do EDS-A. Je možné p es ESB s tím, že d chodové systémy zasílají informace o jednotlivých zm nách? enos bude probíhat dávkov . 12. V p ípad pr žn zjiš ovaných zm n (nikoli tedy na základ nového, nebo zm ného dokladu v INP) má také dojít k automatickému vyhodnocení IKP a p ípadnému automatickému požadavku na opravu do WORK? Ano, automatické vyhodnocení. 13. i pravidelném dotazování (bez konkrétního podn tu) do systém KE a IVK by byly systémy nadm rn zat žovány (dotazováním na všechny záznamy a zjiš ováním všech rozdíl ). Je možné p edpokládat, že tyto systémy budou samy aktivn informovat o zm nách? Zajišt ní takových úprav t chto systém je sou ástí této zakázky? Systém neumí prozatím aktivn informovat; ano, úpravy jsou sou ástí této zakázky. 14. Jakým zp sobem uživatel UIP, který provedl opravu konta v UIP, promítne zm ny do DB_IKP? edpokládá se, že automaticky - zápisem zm ny do INP (p ípadn IVK) což vyvolá automatické vyhodnocení a aktualizaci DB_IKP? Ano, automaticky. 15. Napln ní DB_IKP informací o nepokryté dob pojišt ní (které se stanoví na základ generování IVK a bude generována v DB_IVK a je požadováno v bod k) na str. 17) bude provedeno jednorázov v rámci prvotního napln ní registru IKP, nebo bude dopl ováno až postupn pr žn p i generování IVK? Jednorázov p i napln ní + pr žné dopl ování dle došlých podklad . 16. V jaké technologii jsou související moduly a aplikace JDV01, JDV04, WORK, APV UIP? JDV01 a JDV04 – VB6 , WORk - VB6, APV UIP - VB 6 17. Je preferováno .NET nebo Java? Je preferován .NET. 18. Existuje n jaký standard v rámci SSZ pro podporu vým ny informací o zm nách v datech mezi jednotlivými aplikacemi/moduly? Nap . publish-subscribe princip, dotazy na zm ny identifikované datem zm ny od-do. Podporují dnešní aplikace, se kterými má IKP komunikovat, n jaký konkrétní mechanizmus p edávání informací o zm nách? Pokud ne, budou muset být v rámci realizace implementovány do okolních aplikací mechanizmy navržené projektem IKP. Standardem je BizTalk. 19. Jak se promítnou zm ny provedené v povym ovací agend (PA) do registru IKP, aby se v IKP mohl zm nit p íznak pro došet ení v PA? PA zapisuje také do DB_INP? Položené otázce nerozumíme. 20. Které další systémy krom IKP zapisují nové požadavky do WORK? Další možností zápisu je pouze ru ní nahrání pomocí programu WORKINS 2.7.1. 21. Úpravy v DB_IVK, DB_INP, WORK, KE a mainframe systémech v souvislosti s podáváním informací o zm nách do registru IKP - pokud takovéto služby v sou asné dob neexistují, jsou sou ástí p edm tu zakázky, nebo je zajistí zadavatel? Ano, jsou p edm tem zakázky, krom úprav Mainframe. 22. Požadavky zapisované do WORK se týkají konkrétních doklad , nebo celého konta? Celého konta pojišt nce.
2
23. Na stran 17 zadávací dokumentace se píše „Statistiky budou podávat p ehled …. o stavu nárokových podklad a to variantn bez vazby R /E P nebo s vazbou R /E P“. Vysv tlete prosím, co je mín no variantou bez vazby na R /E P , když konto nem že existovat bez vazby na R /E P. Bez vazby na R = dle chyb, dle doklad . 24. V zadávací dokumentaci je požadováno, aby v registru IKP byly zaznamenány nap . jméno, íjmení, R /E P. SSZ p itom vychází z architektury SOA, ve které jsou údaje o osobách uloženy v KE a okolní systémy mají uloženo pouze ID osoby. Pokud v návrhu datového modelu vyjdeme z pravidel SOA a jméno, p íjmení nebudou zaznamenány v IKP, ale pouze nep ímo odkazem p es ID osoby do KE, bude takový návrh vyhodnocen jako nespl ující podmínky zadávací dokumentace? Ne, nebude vyhodnoceno jako nespl ující podmínky. 25. Existence nepokryté doby pojišt ní m že být d vodem pro zaslání do WORK a do APV UIP? Zadavatel po uchaze i požaduje, aby se v rámci ešení Registru IKP p ipravily podmínky pro další využití informací o neprokázaných dobách pojišt ní (dle ZD) 26. Je možné využít externí asova pro spoušt ní dávkových úloh? Ano, centráln SCHEDULER. 27. Pokud má být generování IVK sou ást APV UIP, bude jeho sou ástí také odeslání do PRESS? Jak se IKP dozví o seznamu IKV s chybou p i generování z APV UIP? Ano, odeslání do PRESS bude sou ástí. Zadavatel po uchaze i požaduje, aby navrhl zp sob ešení.
Bc. Ludmila Hnutová Odd lení centrálního zadávání ve ejných zakázek
3
Odpov di na dotazy uchaze
k ve ejné zakázce . 58/2012-17-27
„Vytvo ení registru individuálních kont pojišt nc “
Dotaz: Uchaze se dotazoval Žádostí o poskytnutí dodate ných informací k zadávacím podmínkám ze dne 15. ledna 2013 na souvislost odkazu uvedeného v zadávací dokumentaci ásti IV. Obchodní podmínky ve ejné zakázky v odst. 1 písm. m), týkajícího se bližší specifikace podmínek pojišt ní odpov dnosti za škodu, k jehož sjednání se uchaze má zavázat v Návrhu smlouvy, p emž "porušení tohoto závazku bude hodnoceno jako podstatné porušení smlouvy ze strany uchaze e". Odkaz na podmínky pojišt ní sm uje do ásti VI. odst. 3 zadávací dokumentace, kde se však nachází Sou innost, resp. Legislativní sou innost bez zmínky pojišt ní odpov dnosti za škodu. Dodate nou informací od zadavatele ze dne 16. ledna 2013 byl uchaze v tomto smyslu odkázán na ást VII. odst. 3a) zadávací dokumentace, který se však týká požadavk na prokázání technických kvalifika ních p edpoklad , konkrétn požadavk na p edložení seznamu významných služeb. Uchaze se pe liv seznámil se zn ním zadávací dokumentace v etn jejích p íloh a nikde nenalezl hledanou pasáž, která by hovo ila o podmínkách, které jsou ze strany uchaze e nezbytné pro spln ní požadavku na uzav ené pojišt ní odpov dnosti za škodu. Mohl by zadavatel tedy za této situace explicitn vyjád it své požadavky na pojišt ní odpov dnosti za škodu, které má uchaze zahrnout do Návrhu smlouvy a zavázat se k jeho sjednání po celou dobu trvání smluvního vztahu, nebo tento závazek z obchodních podmínek vypustit? Odpov : Zadavatel zjistil administrativní nep esnosti v ásti zadávací dokumentace týkající se pojišt ní odpov dnosti za škodu. Bohužel se do textu dostala ást týkající se jiné zakázky. Proto nyní zadavatel tuto ást zadávací dokumentace opravil a zadávací dokumentace je p ílohou této odpov di. Rovn ž je uve ejn na na profilu zadavatele. Dále byl v d sledku této opravy prodloužen termín pro podání nabídek a to na 31. 1. 2013 do 12:00 hodin.
Bc. Ludmila Hnutová Odd lení centrálního zadávání ve ejných zakázek