Odpovědi na dotazy účastníků průzkumu trhu

• "Byla ze strany projektového týmu zvažována možnost z ekonomického hlediska provozovat systém formou cloudu na platformě, kde je možné provést optimalizaci nákladů na iniciální provoz HW infrastruktury, tak provést následnou optimalizaci licencí na využívání jednotlivých platformových komponent?"
  
  Projektový tým zvažoval aplikaci Národní strategie cloud computingu České republiky na požadované řešení eSeL. Vzhledem k požadovaným termínům realizace projektu eSeL a předpokládaným termínům naplňování NSCC ČR bylo konstatováno, že minimálně ve fázi vybudování a udržitelnosti eSeL jsou tyto projekty termínově neslučitelné. Aplikování eSeL do prostředí podnikového cloudu (non-státní řešení) pak aktuálně není možné vzhledem k předpokládané klasifikaci eSeL jako významného systému VS vzhledem k Zákon č. 181/2014 Sb. - Zákon o kybernetické bezpečnosti a o změně souvisejících zákonů
   
• "Je design sieti a sietovych provkov out of scope?"
  
  Na otázku nelze odpovědět požadovaným jednoznačným způsobem. Dodavatel je povinen v návrhu technické architektury použít síťovou službu CMS, jejíž konfiguraci nebude dodavatel provádět. Design a konfiguraci síťových prvků mimo CMS nebo napojujících se na CMS však dodavatel bude provádět.
   
• "Predpokladame spravne, ze v danej casti 'eL RC1' je za eSablonu plusovu os len plny klient (ci uz online alebo offline), nie portal verzia. Chapeme spravne, ze portalova verzia eSablony je v 'eL RC3'?"
  
  Odpověď na obě otázky je ano.
   
• "Oblast pilota - Je v niektorej polozke zohladnene naklady na PR a komunikaciu s tretou stranou, resp. ostatnymi rezortami, verejnostou pod.?"
  
  Otázky financování a realizace propagace jsou řešeny mimo předmětné veřejné zakázky. Od dodavatele implementace se očekává, že bude při prezentacích projektu poskytovat obvyklou součinnost. S komunikací s třetími stranami a ostatními rezorty je nutné počítat zejména v rozsahu nutném pro zprovoznění navržených integrací, zaškolení uživatelů a intenzivní komunikací se zástupci zejména Úřadu vlády a odborného aparátu Parlamentu ČR již od počátku projektu, nejen v pilotním provozu.
   
• "Nie je uplne zrejme aky rozsah supportu pre urovni 1 a 2 bude potrebne zabezpecit dodavatelom. v poziadavkach je: Dodavatel je v souladu s Architektonickým návrhem zodpovědný za ServiceDesk řešení pro úroveň podpory 3 a 4., na workshope bola spominana aj podpora prvej urovne."
  
  1. a 2. úroveň podpory zajistí objednatel. Dodavatel zajistí 3. a 4. úroveň. Dodavatel však musí zaškolit pracovníky této podpory, viz kapitola "5.2.8.4 NP053-Školení správců systému a pracovníků podpory" Detailního návrhu a kapitola "5.1.8.1 Podpora uživatelů" Dodatku č. 1.
   
• "Náklady na provoz systému: Nie je jasne ci v tychto polozkach ma byt maintenance HW/SW, alebo len riesenia."
  
  Maintenance HW/SW je nedílnou součástí požadovaného řešení. Požadujeme rozlišit (nákladově), kde je nedílnou součástí dodané platformy (např. HW 5 let, SW 3 roky ode dne závěrečné akceptace) a provozních nákladů, tedy např. 4. a 5. rok provozu. Maintenance aplikačního řešení předpokládáme po celou dobu udržitelnosti jako součást dodávaného plnění specifikovaného v ZD.
   
• "Ma byt sucastou navrhu a nacenenie aj kontrola a ochrana vkladanych dokumentov? napriklad virus check?"
  
  Zadavatel požaduje, aby každý soubor, který bude do systému ukládán, byl před uložením prověřen na přítomnost škodlivých kódů, a to na úrovni serverové infrastruktury (nikoliv na koncové stanici uživatele). Tato procedura nesmí omezovat uživatele, který dostane pouze notifikace o tom, že dokument byl zapsán - uložen, případně odmítnut a dán do karantény pro podezřelý obsah. Komponenty systému chránícího proti škodlivým kódům na serverové infrastruktuře je nezbytné zahrnout do nabízeného řešení a nacenit.
   

• "Predpokladame spravne, ze testovacie a skoliace produkcne prostredie moze byt pouzite v navrhu ako prostredie pre zabezpecenie BCM? Odporucame aj dalsie prostredia okrem spomenutych - integracne, predprodukcne." Upřesnění: "BCM myslíme 'business continuity management' . V tomto smyslu jsme mysleli ostatní prostředí mimo produkční, které v případě výpadku, či problému v produkci lze použit pro zachování provozuschopnosti systému jako takového, tedy jako záložní prostředí apod. – v rámci řešení uvedeného BCM."
  
  "Testovací a školící prostředí" a "záložní produkční prostředí" mohou sdílet určité HW prostředky (např. síťové prvky nebo diskové pole). Konkrétní úroveň sdílení je na technickém návrhu dodavatele. Musí však být dodrženy požadavky na tato prostředí. V tomto kontextu zejména:
  - "Testovací a školící prostředí" musí být bezpečnostně odděleno od obou produkčních prostředí.
  - "Záložní produkční prostředí" musí mít stejnou výkonovou kapacitu jako "produkční prostředí v primární lokalitě".
  - Výkon "testovacího a školícího prostředí" nemusí být stejný, jako výkon "produkčního prostředí v primární lokalitě" (a "záložního produkční prostředí"), avšak neměl by být významně omezen, pokud bude produkční provoz obsluhován ze "záložního produkční prostředí". Pokud bude na "testovacím a školícím prostředí" zvýšená zátěž, nemělo by to významně ovlivnit výkon "záložního produkční prostředí".

• "Pořadovaný offline klient musí vycházet z 'tlustého plnohodnotného' klienta, který bude obsahovat omezeni proti plnohodnotnému klientu, nebo lze offline klient realizovat jako web klient, který ale bude provozovatelný i offline. Je toto technicky přijatelné pro zadavatele? Je toto přijatelné z pohledu požadované funkcionality od offline klienta (aneb offline klient bude mit 1:1 stejnou funkcionalitu jako web klient)?"
  
  Z pohledu funkčnosti je za plnohodnotného považován "tlustý klient". Omezení funkčnosti "webového klienta" a "offline klienta" jsou různá. "Webový klient" nemusí umět pracovat se složitými strukturami jako tabulky nebo obrázky (v editačním režimu), offline klient nepracuje se souvislostmi právního předpisu (všechny typy vazeb vedoucích mimo rozpracovaný právní akt apod.), avšak s tabulkami a obrázky pracovat musí. Není tedy možné, aby funkčnost "offline klienta" a "webového klienta" byla 1:1. Volba technologie implementace tlustého a offline klienta je na dodavateli. Pokud dodavatel zvládne využít webovou technologii dostatečně ergonomicky z pohledu uživatelského rozhraní a splní funkční požadavky, může ji použít i pro implementaci "tlustého klienta" a "offline klienta".

• "Digitalizace 1. část – všechny sbírky do roku 1989 včetně (Sbírky zákonů ročník 1945-1989, Úřední listy ročník 1945-1961). Je pripustne kupit tieto data digitalizovane ako eurlex, byt v jinem jazyce?“ Upřesnění: „Dotaz měl vyznít tak, zda je možné relevantní předpisy v uvedených ročnících zakoupit již hotové digitalizované v jiném jazyce, a následně jej „pouze“ přeložit do jazyka českého, bez potřeby je digitalizovat (pokud již jsou digitalizována a verifikována)."
  
  Obecně platí, že data, respektive datovou bázi jako celek není přípustné nakoupit. Datová báze musí být vytvořena a verifikována postupy popsanými v podrobném technickém řešení a jeho Dodatku č.3. Jedná se o zásadní rys koncepce. Důvodem je především auditovatelnost tvorby a možnost ověření všech jednotlivých prvků datové báze, jejíž správnost bude Ministerstvo vnitra garantovat.

•  

  "Žádáme upřesnění vazby mezi eSeL a AIS PMA. Ze zadávací dokumentace vyplývá, že AIS PMA bude zdrojem informací pro eSeL, které bude eSeL zobrazovat v relevantních případech. Na druhé straně na semináři zaznělo, že „eSeL bude zdrojem pro PMA“. Požádali bychom tedy o upřesnění této vazby ve smyslu – jaké sužby k jakému účelu bude AIS PMA vyžadovat od eSeL, a jaké informace bude eSeL předávat AIS PMA?"
  
  eSbírka a eLegislativa nebudou v této fázi integrovány s PMA. Detailní návrh integraci s PMA ještě obsahuje, ale tyto informace budou vypuštěny.

• Otázky ke tvorbě datové báze (pdf, 497 kB)

vytisknout  e-mailem  X Corp.   Facebook