VYSVĚTLENÍ / ZMĚNA ZADÁVACÍ DOKUMENTACE Č. 4

VYSVĚTLENÍ / ZMĚNA ZADÁVACÍ DOKUMENTACE Č. 4

Název veřejné zakázky: Dodávka Systému IS VAK včetně zajištění rozvoje a provozu Evidenční číslo VZ: Z2022-045873

Druh zadávacího řízení: Otevřené řízení dle § 56 zákona č. 134/2016 Sb., o zadávání veřejných zakázek („ZZVZ“)

Zadavatel: Sídlem: Zastoupený:

IČO:

Česká republika – Ministerstvo zemědělství Xxxxxx 00/00, 000 00 Xxxxx 0 – Xxxx Xxxxx

Xxx. Xxx Xxxxxx, ředitel Odboru informačních a komunikačních technologií

00020478

Česká republika – Ministerstvo zemědělství jako zadavatel výše uvedené veřejné zakázky obdržel ve dnech 31. 01. 2023 až 10. 02. 2023 žádosti o vysvětlení zadávací dokumentace.

S ohledem na množství dotazů k zadávací dokumentaci se zadavatel rozhodl zadávací řízení zrušit a v nejbližší možné době připravit nové. Stávající lhůta pro podání nabídek (16. 02. 2023) tedy neplatí. Prosíme, nezasílejte své nabídky.

Níže uvádíme obdržené znění dotazů společně s odpověďmi zadavatele.

31. 01. 2023

Obecná část: Otázka č. 1

Prosíme o vysvětlení důvodu předání významné části dokumentace až při podpisu smlouvy, a nikoliv proti podpisu NDA dodavatele. Zejména pak Modelu případů a užití v SEA projektu, specifikaci rozhraní integrovaných systémů objednatele a dokument nebo odkaz na dokument aktuálně platného standardu systémové bezpečnosti MZe?

Odpověď zadavatele

Modely případů a užití v SEA projektu budou předány oproti NDA. V těchto modelech je zpracována většina případu užití dosud zmapovaných v rámci agendy VAK, vyjma oblasti kalkulace cen pro vodné a stočné, která chybí úplně.

Obecná specifikace rozhraní integrovaných systémů MZe bude předána oproti NDA. Z důvodu snížení rizika možného kybernetického útoku je dokument zpracován v obecné povaze.

Standard systémové bezpečnosti je již nyní předáván vůči NDA, v případě, že by proběhla aktualizace tohoto dokumentu obdrží ho Dodavatel opětovně po podpisu Xxxxxxx.

Otázka č. 2

Diagramy v Příloze 1 návrhu smlouvy jsou špatně čitelné. Je možné získat je v čitelnější podobě?

Odpověď zadavatele

Diagramy budou zveřejněny na profilu zadavatele v samostatném dokumentu.

Otázka č. 3

Bude nový systém implementovat stejné procesy a funkcionalitu jako stávající řešení? Půjde primárně o technologický upgrade, nebo je cílem také redesign stávajících procesů?

Odpověď zadavatele

Zadavatel by neoznačil implementaci procesních změn za redesign, neboť tyto procesy vychází a nadále budou vycházet z ustanovení platných právních předpisů. Procesy ale zároveň nebudou úplně stejné, neboť nově například bude možné podat žádost o povolení k provozování elektronicky.

Jaká je předpokládaná lhůta pro akceptaci ze strany zadavatele (Analytická fáze - “Fáze 1”)? Je třeba reflektovat náročnost, resp. rozsah analytické části, která dle zadávací dokumentace má být v rozsahu 200-400 normo stran. Bez této akceptace, se “dodavatel” vystavuje riziku víceprací, v závislosti na případných změnách vyplývajících z akceptace “zadavatele”.

Odpověď zadavatele

Zadavatel předpokládá intenzivní součinnost Smluvních stran v průběhu plnění celého předmětu veřejné zakázky. Vzhledem k tomu by většina aspektů realizace měla být mezi Smluvními stranami vyřešena v průběhu Fáze 1. V závislosti na intenzitě komunikace a spolupráce v průběhu Fáze 1 bude Zadavatel schopen provést posouzení/připomínky výstupů. V případě intenzivní spolupráce lze předpokládat, že Zadavatel na posouzení bude potřebovat cca 10 kalendářních dní.

Otázka č. 5

V sekci "1.Použité termíny a zkratky” je uveden termín BI (Business Inteligence). Předpokládá objednatel vytvoření datového skladu a s tím věcně souvisejících funkcionalit pro potřeby reportingu a obecně BI?

Odpověď zadavatele

Ne, pouze databáze IS VAK musí být realizována tak, aby umožnovala napojení takového nástroje.

Integrace: Otázka č. 1

Dle Přílohy 1 návrhu smlouvy, kapitoly 4.2, bude IS VAK integrován napřímo s různými rozhraními MZe. Znázorněny jsou také komunikace se službami MŽP. Budou tyto, a případné další integrace na systémy mimo MZe, zprostředkovány pro IS VAK prostřednictvím služeb MZe?

Odpověď zadavatele

Komunikace s externími systémy bude realizována prostřednictvím ESB platformy AgriBus (MZe) s využitím webových služeb.

Dle Přílohy 1 návrhu smlouvy, kapitoly 4.2 IS bude VAK získávat informace o uživatelích a skupinách z MZe LDAPu a CODEL DB. Nepočítá se s využitím jednotného Identity Management řešení?

Odpověď zadavatele

V budoucnu se předpokládá sjednocení identit pod jednotné IDM. Bohužel toto řešení nebude s největší pravděpodobností dostupné ke dni spuštění IS VAK do ostrého provozu. Proto je nutné identity přebírat z MZe LDAP, CODEL DB.

Otázka č. 3

Bude IS VAK realizovat veškeré odchozí notifikace (email, ISDS apod.) prostřednictvím MZe notifikačního serveru, viz např. REQ-111?

Odpověď zadavatele

Pouze část notifikací bude realizována skrze email prostřednictvím notifikačního serveru. Druhá část notifikací bude probíhat skrze ISDS a eSSL úřadu (notifikace související se správními procesy a komunikace vůči Poskytovatelům dat).

Otázka č. 4

Příloha 1 návrhu smlouvy, kap. 4.3 uvádí jako jednu z rolí i „Ministerstvo financí“. Budou uživatelé s touto rolí v MZe LDAPu a CODEL DB, nebo bude potřeba integrace s Ministerstvem financí?

Odpověď zadavatele

Integrace na identity management Ministerstva financí nebude realizována. Předání informací o uživateli bude probíhat stejně jako u uživatelů MZe (uživatelé MF budou zavedeni do LDAP MZe.)

Data: Otázka č. 1

Předpokládáme, že stávající struktura XML souborů pro importy/exporty zůstane zachována. Je k dispozici její specifikace?

Dodavatel navrhne strukturu XML souborů vyhovující potřebám a novým požadavkům IS VAK.

Otázka č. 2

Předpokládáme, že poskytnutá data stávajícího řešení jsou „čistá“ bez nutnosti jejich zpracování dodavatelem před migrací do nového IS VAK. Je náš předpoklad správný?

Odpověď zadavatele

Strukturu dat Zadavatel zveřejní na svém profilu v samostatné příloze. Historická data mají pravděpodobně jinou strukturu, než bude mít databáze navržená Dodavatelem. Lze tedy předpokládat, že bude nutné data transformovat. Co se týče správnosti dat např. překlepy, špatný formát záznamu (text, kde má být číslo) atd. jsou data čistá.

Otázka č. 3

Poskytne zadavatel data pro všechny instance, viz REQ-026, tedy poskytne data pro testování a vývoj (včetně vazeb atd.)? V jaké formě (anonymizované atp.)?

Odpověď zadavatele

Dodavatel může pro testování využít historická data IS VAK. Vzhledem k nové databázové struktuře systému navrženého Dodavatelem nelze předpokládat dodání včetně „vazeb“.

Infrastruktura a technologie: Otázka č. 1

Je očekávána dodávka pro zajištění elasticity VMware clusteru dle kapitoly 5 Přílohy návrhu smlouvy od dodavatele, nebo toto zajistí zadavatel?

Odpověď zadavatele

Požadavky v oblasti WMware zajistí zadavatel.

Otázka č. 2

Příloha 1 návrhu smlouvy, kap. 5 říká, že objednatel poskytne pro produkční prostředí databázi MS SQL jako službu. Bude databáze k dispozici i pro další prostředí, jako je vývojové a testovací?

Ano, DB bude dostupná pro všechna prostředí.

Otázka č. 3

Klade objednatel nějaká omezení na používané technologie mimo započítání licenčních nákladů, jak je uvedeno v Příloze 1 návrhu smlouvy?

Odpověď zadavatele

Zadavatel požaduje, aby software/technologie splňoval/a požadavek Req-025 dle přílohy č. 1 Smlouvy.

Otázka č. 4

Logování: Je očekáváno využití logovací infrastruktury objednatele, nebo tvorba nové s využitím např. ELK stacku?

Odpověď zadavatele

Pokud se jedná o logování činnosti uživatelů v aplikaci, navrhne a dodá řešení Dodavatel. Logování přístupů k aplikaci včetně servisních účtů zajistí Zadavatel svými prostředky.

Otázka č. 5

Je očekáváno využití monitorovací infrastruktury objednatele, nebo bude nutné vytvořit nový monitoring, např. Prometheus, Zabbix aj.?

Odpověď zadavatele

Monitoring infrastruktury bude realizován prostřednictvím nástrojů Zadavatele.

Aplikační monitoring (viz KL_VAK_01) bude realizován prostředky Dodavatele a sekundárně pro ověření i prostředky Zadavatele.

Součinnost, projekt, provoz a rozvoj: Otázka č. 1

Dle Přílohy 1 návrhu smlouvy, kap. 12.2: „Objednatel je připraven poskytnout intenzivní součinnost v celém období plánovaném pro analýzu a návrh architektury dle harmonogramu projektu uvedeného v této kapitole“ – jakými rolemi zadavatel disponuje (zejména z pohledu procesní analýzy)?

Na straně Zadavatele budou součinnost poskytovat zaměstnanci – garanti agendy s detailní znalostí procesu zpracování, dále zástupci oddělení provozu IT, oddělení kybernetické bezpečnosti (analytik kybernetické bezpečnosti), oddělení rozvoje ICT (analytik), oddělení architektury a digitalizace (architekt). Co se týče procesní analýzy bude možné spolupracovat s garanty agendy a analytikem oddělení rozvoje ICT.

Otázka č. 2

Připouští zadavatel větší/nerovnoměrné čerpání součinnosti pro jednotlivé fáze?

Odpověď zadavatele

Ano, připouští. Zadavatel předpokládá větší zatížení ve Fázi 1 a při testování výstupů Dodavatele.

Otázka č. 3

Dle Př. 1 návrhu smlouvy, kap. 12.2 dodavatel připraví Návrh harmonogramu sprintů. Předpokládáme, že v rámci každého Sprintu probíhám i akceptace daného inkrementu. Případné pozdější změny budou chápány jako změnový požadevek?

Odpověď zadavatele

V případě, že by bylo potřeba změnit funkcionalitu Sprintu (inkrementu) na základě dalšího vývoje, pak by tato pozdější změna nebyla chápána jako změnový požadavek.

V případě, že by se ale jednalo o úplně novou funkcionalitu (nad rámec výstupů Fáze 1) nebo v případě legislativně nebo technologicky podmíněné změny, by tato změna byla řešena v rámci služeb Rozvoje.

Otázka č. 4

Předpokládá dodavatel správně, že bude možné čerpat rozvojové MD i během implementační fáze?

Odpověď zadavatele

Ano, v případě, že by se jednalo o úplně novou funkcionalitu (nad rámec výstupů Fáze 1) nebo v případě legislativně nebo technologicky podmíněné změny, by tato změna byla řešena v rámci služeb Rozvoje.

Disponuje objednatel svou konfigurační databází, kterou má Poskytovatel dle Přílohy 1 pravidelně aktualizovat?

Odpověď zadavatele

Ano, zadavatel disponuje konfigurační databází, kterou bude poskytovatel aktualizovat.

Požadavky na IS VAK, kapitola 13 Přílohy 1 návrhu smlouvy: Xxxxxx č. 1

Bylo by vhodné držet identifikátory požadavku unikátní přes celou kapitolu 13. Někdy jsou duplicity identifikátorů i v rámci jedné sekce/tabulky. Je možné doplnit?

Odpověď zadavatele

Zadavatel opraví chyby v číslování požadavků v nové verzi Smlouvy.

Otázka č. 2

Architektura a výkon/REQ-001 jsou poměrně obšírné. Poskytne zadavatel jeho detailní znění k tomu, aby bylo jednoznačně definovatelné, zda byl splněn?

Odpověď zadavatele

Z pohledu Zadavatele jsou požadavky dostatečně definovány na webových stránkách xxxxx://xxxxx.xxx.xx

Otázka č. 3

Architektura a výkon/REQ-002: Jde o interní IS VAK rozhraní, nebo se jedná o rozhraní dostupné vně systému?

Odpověď zadavatele

Služby modulů ISVAK musí být přístupné přes vnější rozhraní. V případě MZe se jedná o dostupnost cestou interního ESB (AgriBus MZe).

Použitelnost /REQ-013: Co je myšleno větou „Systém musí podporovat více aplikačních rozhraní“?

Odpověď zadavatele

Jedná se o požadavek na striktní oddělení prezentační vrstvy od aplikační vrstvy, tj. možnou budoucí přípravu další prezentační vrstvy (např. pro mobilní zařízení).

Otázka č. 5

Použitelnost/REQ-014: O jaká konkrétní rozhraní se jedná?

Odpověď zadavatele

Cílem tohoto požadavku je zajistit, aby systém IS VAK poskytoval bezchybnou funkcionalitu a služby pomocí všech rozhraní zmíněných v zadávací dokumentaci (viz obrázek integrací č. 5 Přílohy č. 1 Smlouvy). Jeho splnění bude ověřeno testováním dostupnosti a bezchybným fungováním těchto rozhraní. Konkrétně v případě webových služeb se bude jednat o REST (v souladu s požadavkem REQ- 004).

Otázka č. 6

Použitelnost/REQ-011, „Soulad s design systémem MZe a pravidly stanovenými design systémem xxx.xx“: Kde jsou tato pravidla popsána?

Odpověď zadavatele

Viz příloha č. 4 Smlouvy: xxxxx://xxxxxxxxxxxx.xxx.xx/#/. Požadavky Ministerstva vnitra jsou řídícím rámcem pro tvorbu webového rozhraní.

Otázka č. 7

Spolehlivost/REQ-017: Jsou specifikovány požadavky na odezvy systému a další výkonnostní požadavky?

Odpověď zadavatele

Zadavatel doplní požadavky na odezvy systému do KL_VAK_01.

Podporovatelnost/REQ-026: Budou všechny instance (DEV, TEST, PROD) poskytnuty zadavatelem?

Odpověď zadavatele

Ano, budou.

Otázka č. 9

Podporovatelnost/REQ-026: Umožní zadavatel za účelem zrychlení dodávek provádět dodavateli vývoj na jeho vlastním prostředí?

Odpověď zadavatele

Zadavatel požaduje realizaci vývoje na DEV prostředí (MZe), z důvodu přehledu nad dodávaným rozsahem vývojových prací.

Otázka č. 10

Bezpečnost/REQ-034: Požadavek je poměrně obecný. Bude zadavatel detailně specifikovat požadavky týkající se zpracování osobních údajů, jako např. požadavky na auditní log, jejich evidenci a poskytování nadřazeným systémům a procesům v rámci MZe, mazání dat, retenci apod.? Dodavatel předpokládá, že část požadavků je v jmenném rejstříku/136-140, ale není v něm zahrnuto okolí systému.

Odpověď zadavatele

Tato problematika je v rámci zadávací dokumentace pokryta na více místech. Auditní logy a jejich obsah je uveden v REQ-048 a REQ-049. Šifrování REQ-046. Osobní údaje jsou v systému vedeny pro výkon agendy vodovodů a kanalizací a na základě platných právních předpisů není tedy nutné implementovat některé z mechanismů (pseudonymizace, žádost o výmaz, žádost o omezení zpracování atd.).

Smluvně je oblast Ochrany osobních údajů řešena dle čl. 28 Smlouvy.

Otázka č. 11

Bezpečnost/REQ-041, 042, 043: Jedná se o data poskytovaná prostřednictvím IS VAK GUI nebo jeho XML exportů?

Odpověď zadavatele

Systém bude omezovat poskytování dat dle rolí, jak pro GUI, tak pro exporty.

Otázka č. 12

Bezpečnost/REQ-044: Je požadováno, aby IS VAK kontroloval přítomnost potřebných rolí na základě LDAPu, či systém dostane seznam rolí přihlášeného uživatele v rámci SAML claimů a bude s těmito rolemi pracovat?

Odpověď zadavatele

Zadavatel požaduje, aby IS VAK byl schopen kontrolovat přítomnost potřebných rolí na základě LDAPu i prostřednictvím SAML claimů.

MZe připravuje realizaci ověřování prostřednictvím SAML 2.0, ale ta nemusí být k dispozici v době spuštění IS VAK do produkčního provozu. Vždy bude aktivní pouze jeden způsob ověření.

Otázka č. 13

Bezpečnost/REQ-046: Je vyžadováno šifrování „citlivých dat“ v rámci DB, případně logů?

Odpověď zadavatele

Ano, je požadováno šifrování dat, viz REQ-046 „během přenosu a jejich uložení“.

Otázka č. 14

Audit/REQ-081: Dle REQ-048 bude pro auditní logování využito „centrální řešení pro správu a vyhodnocování logů SIEM - HP ArcSight, které je provozováno v prostředí MZe“ a tedy řízení přístupů do tohoto logu je mimo scope IS VAK. Je tato domněnka dodavatele správná?

Odpověď zadavatele

Ano, pro auditní logování bude využito centrální řešení pro správu a vyhodnocování logů SIEM - HP ArcSight, které je provozováno v prostředí MZe.

Přístupy řídí Zadavatel.

Číselníky/REQ-099–108: Disponuje MZe centrálními číselníky, ze kterých bude moci IS VAK čerpat data a tím pádem nebudou vznikat možné nekonzistentní duplicity?

Odpověď zadavatele

IS VAK se stane centrálním systémem pro agendové číselníky agendy VAK. Sdílení číselníků s jinými informačními systémy bude realizováno prostřednictvím webových služeb.

Otázka č. 16

Integrace/REQ-112: Požadavek mluví o webovém rozhraní spojeným s formuláři, tedy bychpm očekávali GUI. Jsou ale zároveň zmiňovány requesty, odpovědi. Co přesně je tímto požadavkem myšleno?

Odpověď zadavatele

Obecně, data vyplněná uživatelem mohou podléhat kontrole, jejíž náročnost bude nad rámec toho, co by bylo vhodné implementovat přímo do webového rozhraní. Kontrolu je tak nutné provést na straně serveru. REQ-112 tedy specifikuje, že požadavky na kontroly formuláře mohou vznikat jak na straně webového rozhraní, tak na straně webového serveru.

Otázka č. 17

Export/REQ-117: Jaké datové množiny se budou formou OpenData publikovat? Jaké jsou bezpečnostní a výkonnostní požadavky na rozhraní? Jak se liší od REG-117 od požadavku REQ-172?

Odpověď zadavatele

Požadavkem MV (prostřednictvím odboru hl. architekta eGovernmentu) je poskytování maximálního množství dat. Nebudou poskytována pouze data, která by měla osobní povahu, neprošla ještě kontrolou garantů a případně by jejich zneužití mohlo ohrozit infrastrukturu VAK nebo jinak narušit fungování vodovodů a kanalizací.

Oba požadavky řeší problematiku otevřených dat. REQ-117 specifikuje požadavek na denního updatu dat. REQ-172 zejména specifikuje požadavek na formát dat a jejich publikaci a ukládání připravených souborů do dedikovaného úložiště. Zveřejněná data bude možné stahovat ve formě samostatných souborů.

Historická data/REQ-121: Jaká je motivace nepoužívat naimportovaná historická data pro předvyplňování formulářů?

Odpověď zadavatele

Motivace je naopak používat tato data pro předvyplňování formulářů. Pokud projdou implementovanými kontrolami kvality dat (viz REQ 120).

Otázka č. 19

Notifikace/REQ-126, 127: Jde o zamítnutí zaslání notifikace přes eSSL ještě před tím, než je z IS VAK na eSSL zaslána?

Odpověď zadavatele

Ano, jde o krok, který má zabránit nechtěnému odeslání/vytvoření notifikace. V případě REQ-127, jde o variantu, kdy Uživatel zastaví automatické odeslání (například z důvodu nutnosti modifikace generického textu zprávy) a odešle informaci přes eSSL sám.

Otázka č. 20

Přílohy/REQ-152: Budou přílohy ukládány v IS VAK nebo ve spisové službě MZe? Poté by byl zřejmě REQ-153 pro IS VAK transparentní.

Odpověď zadavatele

Po realizované antivirové kontrole vstupních dat budou přílohy uloženy v eSSL.

Otázka č. 21

Zpracování záznamů/REQ-158: Xxxxx formou bude systém notifikovat příslušný úřad? Jedná se o notifikace v rámci IS VAK, např. předání úkolu/zprávy roli „Garant agendy KÚ“, či je to komunikace mimo IS VAK?

Odpověď zadavatele

ISVAK připraví cestou šablony zprávu (notifikační informaci), která bude odeslána na příslušný úřad cestou eSSL MZe.

Historická data/REQ-119, REQ-120, REQ-121: Systém bude před spuštěním uživatelského testování naplněn historickými daty. Jedná se o požadavek na kompletní import dat ze současných systémů? Bude k dispozici datový model a možnost konzultací se současným dodavatelem? V jakém formátu budou data pro import dostupná případně bude možné dodavatelem zvolit formu a formát dat předávaných k importu?

Odpověď zadavatele

Zadavatel na profilu zadavatele zveřejní datovou strukturu současného IS VAK. Konzultace se stávajícím dodavatelem zajistí Zadavatel. Nejvhodnější formát dat pro předání bude projednán v rámci projektového týmu IS VAK (např. accdb nebo .mdb).

Otázka č. 23

Sestavy/REQ-115: Podpora uživatelské úpravy šablon výstupních dokumentů. Předpokládá objednatel možnost, že bude uživatel vytvářet vlastní šablony nebo pouze úpravy předdefinovaných šablon případně sdílení (“zveřejnění”) upravených šablon mezi uživateli?

Odpověď zadavatele

Zadavatel předpokládá úpravu pouze u předdefinovaných šablon.

Otázka č. 24

Sestavy/ REQ-116: Přístupnost funkcionality tvorby sestav bude omezena rolí. Tvorba sestav bude obecně probíhat nad předdefinovanou množinou dat (připravenými pohledy na vybraná data)?

Odpověď zadavatele

Ano, připravit sestavu bude možné pouze nad daty přístupnými dané roli. REQ-116 říká, že tvorbu Uživatelem definovaných sestav (např. výběr sloupců, které chce uživatel uvést v sestavě, nebo omezení, že v sestavě mají být uvedeny jen záznamy s určitým stavem), budou mít přístupnou jen zaměstnanci MZe. Ostatní Uživatelé budou mít k dispozici předdefinované sestavy.

Otázka č. 25

Číselníky/REQ-101: Systém bude připraven na vyžádání poskytnout číselník jiným informačním systémům. Týká se všech číselníků nebo jen určité skupiny číselníků (předpokládáme, že se minimálně netýká číselníků přebíraných z jiných systémů)?

Odpověď zadavatele

Funkcionalita by měla být připravena flexibilně s ohledem na možnost, že v budoucnu dojde k rozšíření požadavků na poskytování číselníků, tedy například tak, že číselníky budou mít svoje ID a dobu platnosti a na základě volání těchto konkrétních hodnot systém číselník poskytne. Dodavatel v rámci Fáze 1 může navrhnout i jiný způsob řešení než volání ID+platnost.

Otázka č. 26

Modul kontrol (4.4.5). Předpokládá objednatel funkcionalitu pro odeslání protokolu o výsledku kontroly vlastníkovi, u kterého kontrola proběhla, případně jiný způsob obeznámení vlastníka s výsledkem kontroly nebo bude řešeno na úrovni "Zpřístupnění údajů o kontrolách"? S ohledem na nečitelnost "Obrázek 17 Stavy kontrol v modulu kontrol" není toto zřejmé.

Odpověď zadavatele

Jak vyplývá z modelu, bude se jednat pouze o evidenční nástroj kontrol. Nepředpokládá se komunikace s vlastníkem a zasílání výsledků.

31.01.2023

Otázka č. 1

Zadavatel v příloze č. 1 Zadávací dokumentace Závazný text návrhu smlouvy_final uvádí To-BE stavu řešení, modely integrací apod. ve formě obrázků, které jsou nečitelné a tvoří nedílnou součást smlouvy jako takové.

Žádáme Zadavatele o zpřístupnění všech uvedených obrázků jako samostatné soubory v čitelném rozlišení, případně o zveřejnění modelů ve formátu *.archimate ?

Odpověď zadavatele

Zadavatel zveřejní na profilu zadavatele požadovaná data v čitelné podobě.

Otázka č. 2

Zadavatel v příloze č. 1 Zadávací dokumentace Závazný text návrhu smlouvy_final uvádí požadavek na migraci dat ze současného systému. Zadavatel již dále neuvádí charakter migrovaných dat, datové struktury, počty tabulek, záznamů a velikost samotných dat určených pro migraci.

Tyto údaje jsou pro odhadované náklady samotné migrace pro Uchazeče nezbytné, a proto Zadavatele žádáme o upřesnění uvedených oblastí.

Odpověď zadavatele

Zadavatel na profilu zadavatele zpřístupní charakter migrovaných dat, datové struktury, počty tabulek a velikost dat formou samostatné přílohy.

Otázka č. 3

Zadavatel v příloze č. 5 Zadávací dokumentace, Hodnocení a hodnotící kritéria, uvádí:

Hodnocení a hodnotící kritéria

Hodnocení nabídek bude provedeno dle následujících dílčích hodnotících kritérií (s využitím bodovací metody založené na stobodové stupnici):

….

V rámci dílčího hodnotícího kritéria B. „Kvalita realizačního týmu“ bude zadavatel hodnotit zkušenosti vybraných osob zapojených do realizace veřejné zakázky. Předmětem hodnocení v rámci tohoto dílčího hodnotícího kritéria budou zkušenosti níže uvedených členů týmu s problematikou implementace webových technologií, kteří prokázali splnění kvalifikace, přičemž dílčí hodnotící kritérium bude rozděleno na následující subkritéria s těmito vahami:

Zkušenosti jednotlivých členů týmu budou hodnoceny prostřednictvím počtu dokončených zakázek (projektů) definované kvality, na kterých se daná osoba v pozici, na které je navržena jako specializovaný člen týmu, podílela v posledních sedmi letech ode dne konce lhůty pro podání nabídky. Zkušenosti projektového manažera, architekta řešení a vývojáře/programátora budou ohodnoceny dle níže uvedených tabulek, kde jsou specifikovány parametry zakázek relevantních pro hodnocení a počty bodů pro účely hodnocení. Jedna konkrétní zakázka (tj. posuzovaný projekt, resp. aplikace), může být v hodnocení všech subkritérií B.1, B.2 a B.3, použita pouze jedenkrát.

Uchazeč vychází z toho, že pro prokázání zkušeností jednotlivých členů týmu (subkritérií B.1, B.2 a B.3) nemůže použít totožný projekt, ačkoli se na projektu dané osoby podílely ve zcela různých pozicích a při zcela rozdílných činnostech.

Xxxx, realizoval-li Účastník Projekt XY definované kvality, na kterém se při realizaci mj. podílel:

 Projektový manažer (subkritérium B.1), který vedl vývoj, integraci a implementaci jedné webové aplikace, jejíž celkový finanční objem za realizaci činil min. 5 mil. Kč bez DPH a počet obsluhovaných uživatelů je vyšší než 200,

 Architekt řešení (subkritérium B.2), který navrhoval architekturu či designoval implementaci jedné webové aplikace se znalostí architektonického rámce TOGAF a následně modeloval strukturu IS s využitím modelovacího jazyka Archimate. Celkový finanční objem zakázky na vytvoření aplikace/IS činil min 5,

 Vývojář/programátor (subkritérium B.3), který se podílel na realizaci webové aplikace (IS), u níž celkový finanční objem zakázky na vytvoření aplikace/IS činil min 5 mil. Kč bez DPH a počet obsluhovaných uživatelů této aplikace je vyšší než 200,

může být tento Projekt XY použit pouze pro prokázání zkušenosti jednoho člena realizačního týmu.

S ohledem na skutečnost, že se jedná o hodnocení prokázané zkušenosti a kvality člena týmu, tedy prokázání zkušeností ve zcela odlišných profesních činnostech, namítá Uchazeč proti tomu, že Zadavatel omezuje použití jednoho dokončeného projektu (např. Projektu XY) pouze na jednoho člena realizačního týmu.

Účastník takto nastavená hodnotící kritéria považuje za nepřiměřená, znevýhodňující a diskriminační, tedy za rozporná s ust. § 6 odst. 1 a 2, § 79 odst. písm. b) a § 37 odst.1 písm. a), b) a § 116 odst. 2 písm.

e) zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „ZZVZ“) zejména pro svou nepřiměřenost, diskriminaci, znevýhodnění okruhu dodavatelů účastnících se

veřejné zakázky a s ohledem na neoprávněný požadavek Zadavatele na prokázaní technické kvalifikace, který je současně kritériem kvality pro hodnocení nabídek.

Účastník žádá o úpravu hodnotících kritérií tak, aby mohla být jedna konkrétní zakázka (tj. posuzovaný projekt, resp. aplikace) použita v hodnocení subkritérií B.1, B.2 a B.3, tedy aby mohla být jedna konkrétní zakázka použita pro prokázání zkušeností projektového manažera, architekta i vývojáře, kteří se na zakázce podíleli.

V opačném případně Účastník žádá o zdůvodnění takto nastavených hodnotících kritérií.

Odpověď zadavatele

Zadavatel upraví hodnotící kritérium v příloze ZD č. 5 Hodnocení a hodnotící kritéria. Jedna konkrétní zakázka (tj. posuzovaný projekt, resp. aplikace), může být v hodnocení použita ve všech subkritériích B.1, B.2 a B.3, tzn. u jednotlivých osob (členů realizačního týmu) lze prokázat zkušenosti stejnou zakázkou.

31.01.2023

Otázka č. 1

Vzhledem k akutní hrozbě narůstající inflace žádá dodavatel zadavatele, aby zavedl do zadávací dokumentace, resp. do Smlouvy mechanismus tzv. inflační doložky ve smyslu vyhrazené změny závazku podle § 100 odst. 1 zákona č. 134/2016 Sb., o zadávání veřejných zakázek (dále jen „ZZVZ“). Na základě výše uvedeného dodavatel navrhuje následující znění inflační doložky:

„Vždy k 1. únoru příslušného roku počínaje 1. únorem 2023 bude docházet k úpravám cen za služby účtovaným dle této rámcové dohody o míru inflace vyjádřenou přírůstkem průměrného ročního indexu spotřebitelských cen za uplynulý/předchozí kalendářní rok, vyhlášenou Českým statistickým úřadem, případně jeho právním nástupcem. Poskytovatel zašle písemné oznámení o úpravě cen objednateli. Pro vyloučení jakýchkoliv pochybností dojde k úpravě cen dle tohoto ujednání bez nutnosti uzavření dodatku k této rámcové dohodě. Pokud by inflace přestala být vyhlašována, dohodnou poskytovatel a objednatel ve lhůtě jednoho kalendářního měsíce na použití jiného srovnatelného indexu.“

Pokud zadavatel na návrh inflační doložky nepřistoupí, budou potenciální dodavatelé nuceni započítat do nabídkové ceny svůj vlastní odhad růstu inflace a zadavatel tak obdrží vzájemně neporovnatelné nabídky. Pokud potenciální dodavatele odhadnou inflaci vyšší, než jaká ve skutečnosti nastane, dojde tak k bezdůvodnému navýšení nabídkové ceny.

Odpověď zadavatele

Jelikož se jedná o otevřené zadávací řízení v konkurenčním prostředí, v němž roční míra inflace příslušných IT služeb zdaleka nedosahuje míru inflace průměrného ročního indexu spotřebitelských cen vyhlašovanou Českým statistickým úřadem. Zadavatel jednající s péčí řádného hospodáře a v souladu se zásadou 3E tak nemůže přistoupit na návrh automatického navyšování ceny, vysoutěžené v konkurenčním prostředí na příslušném relevantním trhu IT služeb, na základě přírůstku průměrného ročního indexu spotřebitelských cen. Na základě tohoto postoje zadavatele nebude výše uvedený „inflační požadavek“ v rámci zadávací dokumentace a jejich příloh zohledňován.

Otázka č. 2

Zadavatel v odst. 18.3 závazného návrhu smlouvy na dodávku systému IS VAK včetně zajištění rozvoje a provozu (dále jen „závazný návrh smlouvy“) uvádí, že akceptuje-li zadavatel jakékoliv plnění bez výhrad, nebude tím dotčeno jeho právo na přiznání práv z případných vad takovéhoto plnění, i pokud je bez zbytečného odkladu nenahlásil. Dodavatel vnímá odst. 18.3 závazného návrhu smlouvy jako dispozitivní úpravu § 2112 odst. 1 zákona č. 89/2012 Sb., občanský zákoník. Odstranění povinnosti notifikace vady má své opodstatnění u jednorázového plnění, kdy výsledkem je hmotná věc. Ovšem v daném případě může nastat situace, kdy zadavatel včas (bez zbytečného odkladu) neoznámí vadu plnění, a neoznámením vady může dojít k vadám dalším, a případně pak i ke vzniku škody, za kterou by byl zcela nespravedlivě dle dikce smlouvy odpovědný dodavatel. Taková situace vrhá dodavatele do značné právní nejistoty. Upraví zadavatel odst. 18.3 závazného návrhu smlouvy tak, aby bylo bez jakýchkoliv pochybností zřejmé, že výše uvedená situace nemůže nastat?

Odpověď zadavatele

Vzhledem ke složitosti systémů je možné v některých případech zjistit vadu až později, tj. i po akceptaci bez výhrad, přičemž je odpovědností Poskytovatele poskytovat zadavateli takové plnění, které je bez vad, přičemž v případě zjištění vad plnění musí nést odpovědnost s tím spojenou. Zadavatel jednající s péčí řádného hospodáře proto ponechává ustanovení odst. 18.3 v původním znění.

Otázka č. 3

Zadavatel v závazném návrhu smlouvy věnuje článek 14 kybernetické bezpečnosti. Dodavatel žádá o vysvětlení následujících nejasností.

Zadavatel uvádí, že IS VAK je ve smyslu § 2 písm. d) . 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů, ve znění pozdějších předpisů (dále jen „ZKB“) významným informačním systémem. Je rovněž informačním systémem veřejné správy podle zákona č. 365/2000 Sb., o

informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů. Poskytovatel je tedy provozovatelem významného informačního systému dle ZKB a zároveň významným dodavatelem ve smyslu § 2 písm. n) a v souladu § 8 Vyhlášky č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (dále jen „VKB“). Poskytovatel je povinen plnit veškeré své povinnosti dle ZKB a VKB ve lhůtách stanovených v těchto právních předpisech

Ohledně ZKB a VKB dodavatel namítá, že se nejedná o právní normy obsahující konkrétní povinnosti, u kterých lze bez dalšího konstatovat, že je dodavatel (resp.) zadavatel dodržuje anebo nedodržuje. Zadavatel je povinen zohlednit požadavky vyplývající ze zavedených bezpečnostních opatření při výběru dodavatele pro jeho informační systém, a tyto požadavky zahrnout do smlouvy, kterou s dodavatelem uzavře. Dodavatel se tedy nemůže zavázat plnit veškeré své povinnosti dle ZKB a VKB. Podle § 4 odst. 4 ZKB platí, že orgány a osoby uvedené v § 3 jsou povinny zohlednit požadavky vyplývající z bezpečnostních opatření při výběru dodavatele pro jejich informační nebo komunikační systém a tyto požadavky zahrnout do smlouvy, kterou s dodavatelem uzavřou. Správce systému (zadavatel), tedy ten, kdo určuje jeho účel a podmínky jeho provozování, je v postavení toho, kdo má mít všechny informace o tom, jaká konkrétní bezpečnostní opatření mají být ve vztahu k systému ze strany provozovatele systému zavedena, neboť pouze správce systému má dostatek informací k tomu, aby mohl bezpečnostní požadavky definovat, a vždy nese odpovědnost za jejich realizaci (cit.

„PROVOZOVATEL INFORMAČNÍHO NEBO KOMUNIKAČNÍHO SYSTÉMU podle § 2písm. g) zákona o

kybernetické bezpečnosti, Verze 3.1, xxx.xxxxx.xx).

Citovaný podpůrný materiál rovněž obsahuje vzor informování dodavatele o tom, že je významným dodavatelem a současně provozovatelem systému. Povinnou součástí oznámení má mj. být dostatečně konkrétní vymezení technických a programových prostředků nebo jiného plnění, které tvoří dodávky tohoto dodavatele, resp. vymezení činností dodavatele v rámci systému, pro které je jeho postavení významné z hlediska bezpečnosti systému. Součástí oznámení, resp. informování, mají být pravidla pro dodavatele, která zohledňují požadavky systému řízení bezpečnosti informací podle § 8 odst. 1 písm.

a) a d) VKB. Tyto chybějící údaje musejí být rovněž promítnuty do závazného návrhu smlouvy.

Dodavatel tedy žádá zadavatele, aby učinil součástí zadávací dokumentace konkrétní bezpečnostní opatření, nebo čl. 14 závazného návrhu smlouvy upravil.

Dále se dle čl. 14 závazného návrhu smlouvy má dodavatel zavázat poskytnout zadavateli veškerou součinnost nezbytnou k tomu, aby zadavatel řádně naplňoval právní povinnosti stanovené ZKB, VKB, vyhláškou 360/2020 Sb., kterou se mění vyhláška č. 317/2014 Sb., o významných informačních systémech a jejich určujících kritériích, ve znění pozdějších předpisů. Tato vyhláška neobsahuje žádné právní povinnosti, které by měl zadavatel (natož dodavatel) naplňovat.

Zejména se dodavatel má zavázat poskytnout zadavateli součinnost směřující k zavedení a provádění bezpečnostních opatření podle uvedených právních předpisů. Pojem „veškerá nezbytná součinnost“ je příliš extenzivní v situaci, kdy konkrétní povinnosti dané ZKB a VKB zřejmě nezná ani sám zadavatel. Povinnosti a opatření podle z právních předpisů nelze vyčíst, jelikož se liší podle toho, v jaké roli podle XXX se dodavatel a zadavatel nacházejí. Opatření se liší podle povahy informačního nebo komunikačního systému a neexistuji tak žádná univerzální opatření a povinnosti platná pro všechny role ZKB a pro všechny informační nebo komunikační systémy.

Pokud zadavatel nestanoví konkrétní bezpečnostní opatření, pak porušuje ustanovení § 36 odst. 3 věta první zákona č. 134/2016 Sb., o zadávání veřejných zakázek, v platném znění (dále jen „ZZVZ“), jelikož nestanovil zadávací podmínky veřejné zakázky v podrobnostech nezbytných pro účast dodavatele v zadávacím řízení. Jednotlivé dodavatelé mohou dojít k odlišným závěrům a definovat požadovanou součinnost v různém rozsahu, a zadavatel tak obdrží vzájemně neporovnatelné nabídky. Jelikož zadavatel jako povinná osoba nestanovil konkrétní opatření, pak porušuje ustanovení § 36 odst. 3 věta druhá, jelikož přenáší odpovědnost za správnost a úplnost zadávacích podmínek na dodavatele.

Pokud zadavatel jako povinná osoba nestanovil konkrétní opatření, a bude v průběhu plnění veřejné zakázky požadovat po dodavatele zdarma další plnění s odkazem na čl. 14, pak zadavatel porušuje ustanovení § 36 odst. 3 věta druhá, jelikož přenáší odpovědnost za správnost a úplnost zadávacích podmínek na dodavatele.

Na základě výše uvedeného žádá dodavatel, aby zadavatel specifikoval systém, kterého se určení významným dodavatelem týká a dále aby specifikoval konkrétní bezpečností opatření a zakalkuloval cenu za jejich naplňování do předpokládané hodnoty veřejné zakázky (kupř. vyhrazenou změnou závazku ve smyslu § 100 ZZVZ), nebo aby podal další vysvětlení zadávací dokumentace, kde by ze závazného návrhu smlouvy odstranil povinnosti uvedené v čl. 14.

Odpověď zadavatele

Zadavatel chápe, že ZKB a VKB obsahuje převážně obecné zásady, zároveň však uvádí, že obsahuje i konkrétní požadavky kybernetické bezpečnosti. Příkladem může být §19 VKB odstavec (5). Dále Zadavatel uvádí, že pojem „dodržovat zásady bezpečnosti informací v souladu se zákonem č. 181/2014 Sb.“ mají za cíl dosáhnout chování Dodavatele dle nejlepší praxe v oblasti kybernetické bezpečnosti, právě však v souladu s povinnými závazky dle ZKB a VKB, které na Zadavatele dopadají. Může se tedy jednat o spolupráci při kybernetických bezpečnostních incidentech, zachování fyzické bezpečnosti, poskytování součinnosti při auditu a v případě požadavků na provoz a rozvoj systému takovým způsobem ze strany Dodavatele, které neodporují, ale naopak naplňují požadavky ZKB a VKB. Cílem Zadavatele tedy není v rámci této VZ nadstandartní požadavek na zajištění kybernetické bezpečnosti

mimo předmět smlouvy a mimo požadavky související s předmětem smlouvy, ale v souladu s jejím plněním.

Odst. 14 smlouvy má pro dodavatele informativní charakter naplňující § 8 vyhlášky č. 82/2018 Sb. a konkrétní požadavky na dodavatele jsou uvedeny v rámci smlouvy a jejích příloh.

Konkrétní požadavky na dodržování bezpečnostních opatření jsou vymezeny ve smlouvě v rámci povinností dodavatele (např. v odst. 7.6 – 7.10 a jinde). Poskytovatel je v průběhu poskytování Služeb povinen postupovat v souladu s interními dokumenty Objednatele, které upravují poskytování Služeb a které tvoří součást Zadávací dokumentace. (viz odst. 8 smlouvy). Součástí této dokumentace jsou právě i bezpečnostní politiky, směrnice a standardy z oblasti kybernetické bezpečnosti, které popisují konkrétní požadavky a opatření. Např. konkrétní požadavky na tvorbu hesla, na bezpečný přístup k systémům MZe, na integraci bezpečnostních logů, na integraci systému skenování zranitelností, na tvorbu aplikací, na úroveň a kvalitu šifrování, spolupráci na řešení bezpečnostních incidentů a další.

Další konkrétní požadavky plynoucí ze zákona č. 181/2014 Sb. o KB, vyhlášky č. 82/2018 Sb., o KB a vyhlášky č. 529/2006 Sb., o požadavcích na strukturu a obsah informační koncepce a provozní dokumentace a o požadavcích na řízení bezpečnosti a kvality ISVS jsou uvedené:

v příloze č. 1 v rámci požadavků na podporovatelnost (např.: REQ- 031 Soulad se ZoKB až REQ 54 Přeposílání auditních událostí).

Požadavky Objednatele na kybernetickou bezpečnost jsou podrobně specifikovány v dokumentu

Standard systémové bezpečnosti (viz příloha č. 1 odst. 6)

a dále v Příloze č. 2 v katalogových listech, týkajících se Specifikace služeb provozu a rozvoje, např.: 02- Paušální správa aktiv a konfigurací, 04 Řízení vad (incidentů), 08 – Realizace Exit plánu, a v odst. 5 Požadavky na bezpečnostní dokumentaci.

IS Vak je v souladu s § 2 odst. 1 písm. b) vyhlášky č. 317/2014 Sb., mimo jiné využíván ke kontrolní nebo inspekční činnosti vč. státního dozoru. S ohledem k této skutečnost se tedy jedná o významný informační systém a z toho plyne, jak pro Objednatele jako správce, tak pro Poskytovatele jako provozovatele IS VaK, povinnost pro tento systém dodržovat požadavky vyhlášky č. 82/2018 Sb.

V případě porušení povinností souvisejícími s bezpečnostními požadavky jsou specifikovány sankce

v odst. 25.12, 25.16 a 25.17.

Zadavatel se rozhodl doplnit čl. 14.4 o níže uvedené znění

„Pokud by z tohoto důvodu vznikla potřeba poskytnutí služeb, které nejsou zahrnuty v této smlouvě, bude postupováno v souladu s § 222 ZZVZ.“

Otázka č. 4

Zadavatel v odst. 25.20 závazného návrhu smlouvy stanovil, že zaplacení jakékoliv sjednané smluvní pokuty nebo slev z ceny nezbavuje povinnou smluvní stranu povinnosti splnit své závazky ani nahradit způsobenou škodu nebo nemajetkovou újmu. Kumulace více práv na slevy z ceny a/nebo smluvní pokuty v případě jednoho porušení Smlouvy je přípustná. Dle názoru dodavatele je takový požadavek nepřiměřený. Nelze po dodavateli spravedlivě požadovat, aby nesl odpovědnost za případnou škodu v plné výši, kterou nelze dopředu odhadnout. Dle názoru dodavatele nemůže být výše škody v daném případě předvídatelná, a může být zcela nepřiměřená míře rizika, kterou je dodavatel ochoten na sebe převzít při plnění veřejné zakázky.

Požadavek na nijak nelimitovanou náhradu škody je zcela zjevně nepřiměřený hodnotě veřejné zakázky. Tím dochází k porušení zásady přiměřenosti uvedené v § 6 ZZVZ. Dodavatel nemůže dopředu výši škody předvídat a toto riziko musí promítat do nabídkové ceny.

Dodavatel tedy navrhuje zadavateli, aby stanovil maximální výši škody, která může vzniknout, a vytvořil limit podle svého vlastního uvážení, nikoliv podle návrhu dodavatele. Dodavatel upozorňuje zadavatele, že pokud nedokáže odhadnout výši škody zadavatel, tím méně jí může odhadnout dodavatel. V takovém případě by zadavatel v rámci soudního řízení náhradu škody beztak nevymohl (což by bylo v rozporu s jednáním s péčí řádného hospodáře). Důvodová zpráva k občanskému zákoníku totiž na str. 569 uvádí, že rozsah náhrady škody podmiňuje její předvídatelnost.

Dodavatel má tedy za to, že ke stanovení neomezené odpovědnosti za škodu neopravňují zadavatele ani charakter, hodnota a význam zajišťovaných povinností, ani vzájemný poměr hodnoty zajišťovaného závazku a výše škody. Dodavatel apriori nepředpokládá, že bude porušovat své povinnosti ze smlouvy, ovšem přesto má dodavatel za to, že je neomezená náhrada škody nepřiměřená. Dodavatel apeluje na zadavatele, aby ještě zvážil funkci náhrady škody při posuzování přiměřenosti výše náhrady škody a přihlédl k celkovým okolnostem úkonu, jeho pohnutkám a účelu, který byl zadavatelem sledován.

Odpověď zadavatele

V návaznosti na požadavek tazatele na limitaci výše náhrady škody zadavatel uvádí, že občanský zákoník, na jehož důvodovou zprávu se tazatel v otázce odvolává, stanoví v § 2913, že poruší-li strana povinnost ze smlouvy, nahradí škodu z toho vzniklou druhé straně nebo i osobě, jejímuž zájmu mělo splnění ujednané povinnosti zjevně sloužit. Zároveň občanský zákoník tamtéž jako omezující podmínku stanoví, že povinnosti k náhradě se škůdce zprostí, prokáže-li, že mu ve splnění povinnosti ze smlouvy

dočasně nebo trvale zabránila mimořádná nepředvídatelná a nepřekonatelná překážka vzniklá nezávisle na jeho vůli. Předvídatelnost je tedy dle tohoto ustanovení pojmem relevantním ve vztahu k překážce bránící splnění povinnosti ze smlouvy, nikoli k předvídatelnosti samotné škody. Je též třeba zdůraznit, že v předmětném ustanovení odst. 19.9 Smlouvy jsou výslovně ošetřeny možné škody způsobené právními vadami plnění, zejména v situaci úspěšného uplatnění autorskoprávních nároků

3. osob., jehož důsledky mohou být pro zadavatele různých stupňů závažnosti, tedy i velmi závažných. Případné dopady na Poskytovatele z jeho eventuální odpovědnosti za újmu, resp. snížení míry jeho rizika při plnění veřejné zakázky, jsou ze značné části ošetřeny institutem povinného pojištění odpovědnosti Poskytovatele za újmu ve smyslu čl. 8. Smlouvy. Zadavatel je toho názoru, že předmětné ustanovení odst. 19.9 Smlouvy je v souladu se zákonem a s požadavky kladenými na zadavatele jako na subjekt, jenž musí jednat s péčí řádného hospodáře, a proto zadavatel ponechává z těchto důvodů dané ustanovení beze změny.

03. 02. 2023

Otázka č. 1

Dodavateli po prostudování zadávací dokumentace nejsou zcela zřejmé některé zásadní otázky týkajících se oblasti bezpečnosti a GDPR, jež mají mj. vliv mj. i na stanovení nabídkové ceny. Dodavatel tedy žádá o odpovědi na následující otázky:

 Budou v rámci aplikace IS VAK zpracovávány osobní informace (pokud ano, jaké)?

o Jakých subjektů?

o V jakém rozsahu?

o Za jakým účelem?

 V případě zpracování osobních informací, jak zadavatel plánuje dostát práv dotčených subjektů? (xxxxx://xxx.xxxx.xx/0-xxxxx-xxxxxxxx-xxxxx/x-00000/x0x0000)

 Vztahuje se na požadovaný systém IS VAK ještě nějaká legislativa či regulace kromě ZKB, příp.

GDPR?

 Můžete indikovat nejcitlivější informace, které budou v rámci aplikace IS VAK zpracovávány a ukládány? (ideálně dle Vaší klasifikační škály)

 Můžete indikovat požadavek na zvýšenou integritu konkrétních typů informací (viz REQ-035), které bude aplikace zpracovávat a ukládat?

 Můžete indikovat jaké stávající bezpečnostní nástroje bude možno/nutno použít či integrovat?

o Privileged Access Management (PAM) – správa privilegovaných účtů

o SIEM (Security Incident and Event Management) – Vyhodnocování bezpečnostníc událostí

o Log Collection – správa a archivace logů

o IAM – centrální správa indentit a uživatelských účtů

o HSM – bezpečné úložiště klíčů a certifikátů

o MZe PKI – nástroj pro vydávání důvěryhodných certifikátů pro zabezpečenou komunikaci systém – systém v rámci MZe LAN

 Bude většina požadavků bezpečnosti řízení předpisovou základnou MZe nebo se očekává hybridní způsob, například analýza rizik IS VaK dle metodiky NÚKIB?

Odpověď zadavatele

o Jakých subjektů?

Subjekty v rámci IS VAK jsou:

- Provozovatelé

- Vlastníci

- příjemci vodného a stočného

- žadatelé o povolení k provozování

- viz příloha č. 1 smlouvy

o V jakém rozsahu?

Osobní informace budou v IS VAK zpracovávána v rozsahu dle § 29b zákona č. 274/2001 Sb., Zákon o vodovodech a kanalizacích.

o Za jakým účelem?

Osobní informace jsou v IS VAK zpracovávány za účelem výkonu agendy A1045-Vodovody a kanalizace pro veřejnou potřebu (pod tímto označením je agenda A1045 registrována v Registru práv a povinností (RPP)).

V případě zpracování osobních informací, jak zadavatel plánuje dostát práv dotčených subjektů? (https://www.uoou.cz/6-prava-subjektu-udaju/d-27276/p1=4744)

 právo na přístup k osobním údajům – uživatel/poskytovatel dat bude moct zkontrolovat vedené osobní údaje ve svém profilu v IS VAK.

 právo na opravu, resp. doplnění – IS VAK bude přebírat data ze základních registrů, jakožto primárního zdroje, oprava nebo doplnění může být provedena pouze prostřednictvím základních registrů.

 právo na výmaz – MZe vede osobní údaje v IS VAK na základě zákona č. 274/2001 Sb., a proto právo na výmaz nelze v tomto případě uplatnit. Osobní údaje v systému jsou evidovány minimálně do doby uplynutí skartační lhůty, jejíž spouštěcí událostí je zrušení vodovodu, nebo kanalizace.

 právo na omezení zpracování - MZe vede osobní údaje v IS VAK na základě zákona č. 274/2001 Sb., právo na omezení zpracování nelze uplatnit.

 právo na přenositelnost údajů – MZe bude přebírat data pro IS VAK ze základních registrů, jakožto primárního zdroje a nebude osobní údaje poskytovat zdrojem musí být základní registry.

 právo vznést námitku, - MZe vede osobní údaje v IS VAK na základě zákona č. 274/2001 Sb., právo vznést námitku nelze v tomto případě uplatnit.

 právo nebýt předmětem automatizovaného individuálního rozhodování s právními či obdobnými účinky, zahrnujíce i profilování. – MZe nebude provádět profilování uživatelů, ani nebude využívat automatizovaného individuálního rozhodování.

Vztahuje se na požadovaný systém IS VAK ještě nějaká legislativa či regulace kromě ZKB, příp. GDPR?

- Kromě věcně příslušného zákona č. 274/2001 Sb., se odkazujeme na informace uvedené na níže uvedeném odkaze.

- https://archi.gov.cz/znalostni_baze:klicove_zakony_eg

Můžete indikovat nejcitlivější informace, které budou v rámci aplikace IS VAK zpracovávány a ukládány? (ideálně dle Vaší klasifikační škály)

- Nejcitlivějším údajem jsou informace umožňující identifikaci uživatele, viz § 29b, Zákona č.

274/2001Sb.

Můžete indikovat požadavek na zvýšenou integritu konkrétních typů informací (viz REQ-035), které bude aplikace zpracovávat a ukládat?

- Požadavkem je myšleno, že žádná data, která prochází skrze rozhraní IS VAK nesmí být ohrožena z hlediska integrity, důvěrnosti a dostupnosti.

Můžete indikovat jaké stávající bezpečnostní nástroje bude možno/nutno použít či integrovat?

- Tyto požadavky jsou definovány v čl. 7 Smlouvy.

Bude většina požadavků bezpečnosti řízení předpisovou základnou MZe nebo se očekává hybridní způsob, například analýza rizik IS VaK dle metodiky NÚKIB?

- Předpisová základna v oblasti bezpečnosti (KB) vychází z metodik a doporučení NÚKIB, proto se předpokládá hybridní způsob.

Otázka č. 2

KL_VAK_01:

Chápe dodavatel tento KL správně tak, že zadavatel spravuje infrastrukturální SW prvky sám a dodavatel bude pouze poskytovat součinnost v rámci integrace IS VAK do těchto prvků?

V případě, že tomu tak není, žádáme o upřesnění konkrétních infrastrukturálních SW prvků, u kterých bude vyžadována jejich správa a provoz dodavatelem a také v jakém rozsahu.

Odpověď zadavatele

Ano, Zadavatel spravuje infrastrukturní softwarové prvky ve vlastní režii, resp. prostřednictvím dodavatele infrastrukturních služeb, kterého řídí MZe.

Otázka č. 3

KL_VAK_02:

Chápe dodavatel tento KL správně tak, že:

- změny v provozovaném a akceptovaném IS VAK budou vykonávány v rámci KL_VAK_06, nikoliv v rámci paušální správy. Je úsudek dodavatele správný?

- Je za součinnost považováno i poskytnutí specifikace API IS VAK?

Odpověď zadavatele

Zadavatel v KL_VAK_02 specifikuje rozsah paušálních služeb. Tyto služby obsahují mimo jiné následující:

- Aktivní vyhledání a identifikace oprav, bezpečnostních záplat, patchů, hotfixů, nebo servicepacků včetně jejich získání/stažení, uložení a instalace;

- Implementace nových verzí jednotlivých komponent funkčního celku IS VAK dodaných a schválených Objednatelem pro všechna prostředí/instance funkčního celku. Nasazení releasu (tj. změnového nebo opravného balíku) může být různě robustní a Poskytovatel musí

robustnost nastaveného přístupu uzpůsobit v závislosti na předmětu nasazení (od parametrické změny, po novou verzi použitého produktu). Provádění implementace na všechna prostředí tak, aby byla zachována identická konfigurace testovacího a provozního prostředí. Nasazení na testovací prostředí bude vždy předcházet nasazení na produkční prostředí a bude podléhat schválení Objednatele;

- Nasazení veškerých nových verzí, patchů, hotfixů, service packů a dalších opravných balíků výrobců (vendorů) použitých SW komponent funkčního celku;

- Implementace Objednatelem schválených požadavků na změnu konfigurace.

Z výše uvedeného vyplývá, že činnosti, na které se uchazeč dotazuje jsou součástí paušálních služeb. Za součinnost je považováno i poskytnutí údajů k API ISVAK.

Otázka č. 4

KL_VAK_02:

Jaký rozsah MDs pro exportování dat a metadat z IS VAK zadavatel předpokládá na měsíční bázi?

Odpověď zadavatele

Zadavatel doplní do příslušného KL předpokládaný maximální rozsah těchto činností.

03. 02. 2023

Otázka č. 1

Žádáme zadavatele o poskytnutí obrázků použitých v zadávací dokumentaci v dostatečném rozlišení. Obrázky v ZD nejsou v tomto provedení dostatečně čitelné.

Odpověď zadavatele

Zadavatel zveřejní na profilu zadavatele požadovaná data v čitelné podobě.

Otázka č. 2

Podporuje integrační platforma AgriBUS ESB i rest komunikaci?

Odpověď zadavatele

Ano, podporuje.

Otázka č. 3

Jsou na integrační AgriBUS ESB vystavena všechna rozhraní, která jsou potřeba pro integrace poptávaného systému?

V případě, že AgriBUS ESB nyní neposkytuje všechna potřebná rozhraní, budou včas zajištěny Zadavatelem tak, aby nebyl narušen harmonogram tohoto projektu a bude také zajištěna potřebná součinnost dodavatele AgriBUS, případně třetích stran v průběhu projektu?

Odpověď zadavatele

Obecný popis rozhraní pro integraci s IS VAK Zadavatel uveřejní na profilu Zadavatele. Veškerá nezbytná integrační rozhraní budou k dispozici vítěznému uchazeči cestou ESB (AgriBus MZe), vyjma rozhraní na LDAP/AD MZe, SMTP server MZe, CODEL DB MZe (S těmito systémy bude IS VAK integrován napřímo). Tato rozhraní Zadavatel již nyní využíváa jejich zpřístupnění Dodavateli pro potřeby projektu je otázkou parametrického nastavení (vydání certifikátu pro ESB, nastavení hesla pro CODEL atd.)

Otázka č. 4

Jaký systém pro autorizaci a autentizaci Zadavatel poskytne (např. Active Directory)?

Odpověď zadavatele

Zadavatel poskytne pro autorizaci a autentizaci LDAP/AD MZe.

Otázka č. 5

Pro testování a migraci dat je klíčové, aby migrace a testování migrace měli validní vzorek dat. Budou data pro testování IS VAK poskytnuta z produkčních prostředí?

Budou data pro testování migrace dat poskytnuta z produkčních prostředí?

Odpověď zadavatele

Data pro testování IS VAK budou poskytnuta z produkčních prostředí.

Migrace historických/současných dat IS VAK bude provedena do systému jednorázově. Dodavatel může pro testování migrace využít tato data.

Otázka č. 6

Je možné v rámci Off-site použít vzdálený přístup pro poskytování služeb, kdy se propojí pomocí Site2Site VPN obě sítě objednatele a poskytovatele? Za jakých podmínek?

Odpověď zadavatele

Ano Site2Site VPN lze použít pro přístup k prostředí MZe avšak dále zprostředkovaně pouze pomocí PIM k aplikaci ISVAK za podmínek:

• vytvoření IPsec tunelu pro Site2Site VPN

• ze Site2Site VPN přístup pouze na PIM MZe až následně přístup k infrastruktuře ISVAK

• nekolizní adresní zdrojový rozsah

Otázka č. 7

Žádáme o interpretaci požadavku u „KPI_VAK_07: 12 x 7 PO-PÁ;“. Podle standartního zápisu by to znamenalo dostupnost 12 hodin po dobu 7 dní od Pondělí do Pátku.

Odpověď zadavatele

Zadavatel upraví tuto administrativní chybu v příslušném KL. Správné znění zní „12 x 5 PO-PÁ“.

Otázka č. 8

V závazném návrhu smlouvy, kapitole 12.3 přílohy 1 se píše, že Dodavatel musí v implementační fázi, po schválení analýzy akceptovat změny v zadání bez navýšení ceny. Dokonce je Dodavatel nabádán začít s implementací dříve tam, kde si je jistý, že ke změně nedojde. Takový postup může zásadně, i negativně, ovlivnit náklady na plnění a pro dodavatele v této formulaci se jeví jednoznačně jednostranně nevýhodný a tím obecně neakceptovatelný. Může zadavatele upravit formulaci tohoto článku ve smyslu akceptace změny pouze po vyhodnocení dopadu a oboustranné dohodě?

Odpověď zadavatele

Zadavatel na základě výše uvedeného požadavku upraví znění kapitoly 12.3 přílohy č. 1 Smlouvy. Nové znění smlouvy bude zveřejněno na profilu Zadavatele.

Otázka č. 9

V „KL_VAK_08 – Realizace Exit plánu“ je uvedený požadavek:

 Poskytovat veškerou součinnost potřebnou k realizaci Exit plánu (tj. mimo jiné i poskytování informací, účast na jednáních Objednatele nebo třetích stran určených Objednatelem apod.).

Takto obecně definovaný požadavek na součinnost nejen Objednateli, ale i třetím stranám, umožňuje ze strany Objednatele vznášet neomezené požadavky na čerpání člověkodní poskytovatele po celou dobu trvání Exit plánu.

Vzhledem ke všeobecně uznávané praxi, a pro možnost odpovědného nacenění nabídky tohoto KL, žádáme Zadavatele o definici maximální hranice celkového požadavku na čerpání člověkodní pro potřebnou součinnost při realizaci Exit plánu.

Odpověď zadavatele

Zadavatel specifikuje rozsah maximální požadované součinnosti v rozsahu 32MD/4 měsíce. Tyto informace budou zároveň doplněny do Smlouvy.

Otázka č. 10

V Návrhu smlouvy, v Příloze č. 1 kapitole 3.2 Data je uvedeno, že data budou poskytnuta ve formě databázových souborů. Obsahují databáze mimo dat rovněž i jakoukoliv byznys logiku ve formě procedur, triggerů, atd.?

Odpověď zadavatele

Databáze neobsahují jakoukoliv byznys logiku ve formě procedur, triggerů.

Otázka č. 11

V Návrhu smlouvy, v Příloze č. 1 kapitole 4.4 Stručný popis systému je uvedeno:

... Podání hlášení bude možné i v případě, kdy uživatel nebude přihlášený do aplikačního rozhraní IS VAK. Pro tento přístup budou formuláře vystaveny i pro nepřihlášenou veřejnost. (a) V případě odeslání bude Uživatel vyzván k ověření identity. (b) Teprve po ověření identity a zvolení příslušného hlášení se Uživateli zpřístupní funkcionalita odeslání formuláře a předvyplňování formuláře známými daty. Pokud systém detekuje, že existují data pro předvyplnění, IS VAK tato data nabídne k vyplnění.

Popis ve větě označené (a) uvádí zahájení identifikace až při odeslání (již uživatelem kompletně vyplněného formuláře?). Věta označená (b) však zpřístupnění funkce pro odeslání uvádí po autentizaci, a navíc s možností předvyplnit formulář známými daty ze systému. Uvedený popis není konzistentní z hlediska požadovaného postupu a obsahu. Z popisu vyplývá, že potřebná funkcionalita pro podání

hlášení je pro uživatele bez ověření identity nedostupná, i když je v popisu zmíněno, že funkcionalita je požadována pro nepřihlášenou veřejnost. Rovněž požadavek na předvyplnění formuláře je pro formulaci (a) a (b) rozdílný.

Může Zadavatel svůj popis požadované funkčnosti pro jednoznačné pochopení zrevidovat?

Odpověď zadavatele

Zadavatel upraví znění kapitoly 4.4 přílohy č. 1 Smlouvy. Neautorizovaný uživatel (uživatel u něhož není známa totožnost) nemůže využít funkcionalitu předvyplňování formulářů, ani odeslání podání. Neautorizovaný uživatel může pouze vyplnit formulář a stáhnout si verzi v XML, případně opětovně nahrát XML, editovat ho a znova exportovat.

Otázka č. 12

V Návrhu smlouvy, v Příloze č. 1 kapitole 4.4 Stručný popis systému je uvedeno:

„... Přípravu dat v současné době často zajišťují třetí osoby, které nejsou definované v zákoně (tzv. Zpracovatelé). Zpracovatelé můžou ve webovém rozhraní formuláře vyplnit data, a XML podobu formuláře předat osobě, která je dle zákona povinna poslat hlášení. Zpracovatel nebude moci využívat předvyplňování dat, může ale využít import rozpracovaných dat z předchozího roku pro předvyplnění.“

a) Může Zadavatel upřesnit svůj požadavek na způsob realizace předání XML podoby formuláře mezi Zpracovatelem a osobou ze zákona?

b) Může Zadavatel upřesnit svou představu na zdroj dat "z předchozího roku" pro jejich import Zpracovatelem?

Odpověď zadavatele

a) Podobu XML formuláře definuje dodavatel v rámci Fáze 1. Předání je mimo systém a je čistě v režii těchto subjektů.

b) Zadavatel předpokládá, že Zpracovatelé (ale možná i Poskytovatelé dat) budou využívat XML verze formulářů pro předvyplnění z předchozího roku. Zdrojem dat se může stát IS VAK (tj. v roce X+1 si Poskytovatelé dat udělají export dat ze systému za rok X) nebo si mohou rovnou ponechat XML verzi z předchozího roku.

Otázka č. 13

V Návrhu smlouvy, v Příloze č. 1 kapitolách 4.4.1 MP VAK, 4.4.2 VS VAK je uvedeno:

„... Poskytovatel dat bude moci data zpětně načíst, doplnit údaje a provést opětovně export nebo odeslání.“

Může Zadavatel upřesnit svůj zámysl/alternativu na účel exportu dat ve vztahu k odeslání dat?

Odpověď zadavatele

Systém IS VAK umožní uživateli importovat a exportovat formulář podání opakovaně, v případě, že uživatel bude chtít data modifikovat.

V případě, že se uživatel rozhodne data odeslat, musí být v danou chvíli známa jeho totožnost. Požadavek na možnost exportu dat je požadován z důvodu přípravy podání třetí osobou (Zpracovatelem), která za Poskytovatele dat připraví žádost/hlášení/kalkulaci, avšak do systému nevstupuje jako přihlášený uživatel.

Otázka č. 14

V Návrhu smlouvy, v Příloze č. 1 kapitole 7 Testování je uvedeno:

„... Integrační testy, systémové, zátěžové, akceptační a testy plánů obnovy budou probíhat v testovacím prostředí Zadavatele.“

a) Odpovídá testovací prostředí Zadavatele identicky produkčnímu prostředí Zadavatele z hlediska architektury, operačního a databázového prostředí, dostupnosti integrovaných systémů?

b) S jakou kvalitou testovacích dat lze počítat v testovacím prostředí (obsah, referenční integrita, objem)? Budek dispozici identická sada dat s produkčním prostředím?

Odpověď zadavatele

a) Ano, testovací prostředí zadavatele odpovídá identicky produkčnímu prostředí z hlediska architektury, operačního a databázového prostředí, dostupnosti integrovaných systémů

b) Dodavatel může pro testování systému IS VAK využít všechna historická data IS VAK, tj. sada dat bude identická s produkčním prostředím.

Otázka č. 15

V Návrhu smlouvy, v Příloze č. 1 kapitole 12.3 Fáze vývoj, implementace a integrace a Fáze pilotního provozu je uvedeno:

„Dodavatel zahájí realizaci funkčního celku zahrnujícího: vývoj, implementaci a integraci nejpozději po akceptaci implementační analýzy. Objednatel nicméně předpokládá, že Dodavatel může zahájit část vývojových prací již před akceptací výstupů implementační analýzy, v případě, že si bude jistý, že v rámci akceptačního řízení výsledku první fáze nebude Objednatel požadovat změnu. V případě, že si Objednatel vyžádá změnu, je Dodavatel povinen ji zapracovat bez dodatečného zvýšení ceny za realizaci.“

Může Zadavatel upřesnit, jakou změnu uvedená formulace představuje (změna požadavků pro řešení nebo změna v navrženém způsobu realizace nebo změna z důvodu změny v legislativě)?

Odpověď zadavatele

Zadavatel na základě výše uvedeného požadavku upraví znění kapitoly 12.3 přílohy č. 1 Smlouvy. Nové znění smlouvy bude zveřejněno na profilu Zadavatele.

Otázka č. 16

V Návrhu smlouvy, v Příloze č. 1 kapitole 13 Požadavky na systém IS VAK je u požadavku REQ-109 uvedeno:

„... Důležitým faktem pro budování systému IS VAK je skutečnost, že elektronicky předané formuláře budou primárně ukládány ve Spisové službě. Systém IS VAK bude z těchto podání extrahovat informace a spravovat jejich databázi.“

a) Znamená tato formulace skutečnost, že předání formulářů ze strany povinných osob může probíhat i mimo systém IS VAK, např. odesláním do datové schránky nebo předáním na podatelně, a to ve kterékoliv fázi životního cyklu zpracování případu?

b) Znamená tato formulace skutečnost, že životní cyklus téhož případu může být ze strany povinné osoby zpracováván kombinovaně, např. část v IS VAK a část písemně?

Odpověď zadavatele

a) Zadavatel předpokládá příjem všech podání cestou formulářového rozhraní IS VAK a následné uložení podání v eSSL úřadu, IS VAK bude udržovat pouze data a odkaz na dokument v eSSL. V případě, že podání dorazí do DS, podatelny MZe je automaticky evidován v eSSL. Data z podání zadá garant IS VAK do systému samostatně.

b) Zákon č. 274/2001Sb., specifikuje požadavky na způsob předání povinných údajů. Tato podání budou zpracovávána v celém životním cyklu elektronicky. Ve výjimečných případech může dojít k situaci, kdy data do systému bude zapisovat garant IS VAK prostřednictvím webového uživatelského rozhraní IS VAK. Následné zpracování (životní cyklus) takového podání bude rovněž plně elektronické.

Otázka č. 17

V Návrhu smlouvy, v Příloze č. 1 kapitole 13 Požadavky na systém IS VAK je u požadavku REQ-110 uvedeno:

„Systém bude doplňovat informace o subjektech (právnických a fyzických osobách) ze ISZR.“

Může zadavatel upřesnit, zda doplnění informací z ISZR je myšleno online při zpracování formuláře konkrétní povinné osoby nebo jako dávková kontrola převzatých a uložených dat?

Odpověď zadavatele

U autentizovaných uživatelů dojde k doplnění informací z ISZR online způsobem.

Otázka č. 18

V Návrhu smlouvy, v Příloze č. 1 kapitole 13 Požadavky na systém IS VAK je u požadavku REQ-119 je uvedeno:

„Protože lze očekávat, že se zvýší rozsah automatických kontrol a blokačních mechanismů v systému. Budou historická data označena speciálním stavem (dále jen IMPORT).“

Lze očekávat, že při importu historických dat budou vznikat i stavy kombinované, kdy historická data tvoří část záznamu.

a) Na takto vzniklé záznamy bude rovněž pohlíženo jako na data historická ve speciálním stavu?

b) Myslí zadavatel svou formulací požadavek realizovat všechny kontroly dat uplatněné v aplikaci při postupném zpracování formuláře při importu historických dat do nových struktur?

Odpověď zadavatele

„Lze očekávat, že při importu historických dat budou vznikat i stavy kombinované, kdy historická data tvoří část záznamu“ - Ne, jeden záznam bude vždy zařazen do skupiny historických (stav IMPORT), nebo do skupiny nových/aktuálních dat.

a) Ne, na data, která projdou všemi kontrolami kvality bude nahlíženo, jako na data nová/aktuální.

b) Smyslem požadavku Zadavatele je provést pouze kontroly kvality. Zadavatel neočekává např. uplatnění kontrol souvisejících s procesem zpracování záznamů.

Otázka č. 18

V Návrhu smlouvy, v Příloze č. 1 kapitole 13 Požadavky na systém IS VAK je u požadavku REQ-124 je uvedeno:

„Systém bude rozesílat notifikace prostřednictvím EPO a eSSL MZe“

Je formulací myšlen požadavek, kdy je řízení pro odeslání patřičně vybavené zprávy předáno do kompetence EPO a eSSL a zpráva odeslána prostředky tohoto systému?

Odpověď zadavatele

Ano, takto je to myšleno.

Otázka č. 19

V Návrhu smlouvy, v Příloze č. 1 kapitole 13 Požadavky na systém IS VAK je u podkapitoly „Systém bude podporovat import souborů“ uvedeno:

„Import dokumentů je důležitou součástí fungování IS VAK. Soubory mohou mít podobu doprovodného dokumentu záznamu nebo mohou být mandatorní. Soubory dále mohou sloužit k předvyplnění (např. import číselníku).“

Znamená tento požadavek automatickou evidenci a uložení všech převzatých souborů v eSSL?

Odpověď zadavatele

Ano, veškerá data budou ukládána v eSSL, vyjma importovaných číselníků.

Otázka č. 20

V Návrhu smlouvy je v čl. 26.5 je uvedeno „Objednatel je oprávněn bez jakýchkoliv sankcí vůči jeho osobě tuto Smlouvu písemně vypovědět bez udání důvodů, a to s výpovědní dobou 3 měsíců.“

Vzhledem k tomu, že ve smlouvě není popsán proces předčasného ukončení smlouvy, může Zadavatel tento proces upřesnit, včetně např. finančního vyrovnání za již realizované činnosti, a doplnit toto do návrhu smlouvy?

Odpověď zadavatele

Z podstaty výpovědi uplatněné dle smlouvy v souladu s občanským zákoníkem vyplývá, že smlouva zaniká s tzv. účinky ex nunc, tzn. od okamžiku ukončení účinnosti Smlouvy, tj. od okamžiku uplynutí výpovědní doby. Nejsou tak dotčena vzájemně poskytnutá plnění do konce výpovědní doby a vzájemné nároky z nich plynoucí. Ukončení Smlouvy na základě výpovědi je jen jedním ze způsobů ukončení Smlouvy, a tak i na tento případ se vztahuje ustanovení odst. 26.7 Smlouvy.

Toto vysvětlení vyplývá z textu Smlouvy a podstaty institutu výpovědi ve smyslu občanského zákoníku, a proto není třeba Smlouvu doplňovat.

06. 02. 2023

Otázka č. 1

Uchazeč se ze svého pohledu profesionála jednajícího se znalostí a pečlivostí v segmentu ICT domnívá, že smluvní pokuty uvedené v čl. 25 Přílohy č. 1 zadávací dokumentace s názvem Závazný text návrhu smlouvy, jsou vůči předpokládané hodnotě veřejné zakázky zjevně nepřiměřené (výběr čl. 25.3, 25.6, 25.10, 25.18). Nejen uvedené smluvní pokuty jsou přísnější, než tomu je u porušení smluvních povinností při realizaci služeb s prvky kritické infrastruktury.

Uchazeč má za to, že se jedná o takový zjevný exces, který má dopad do soutěžního prostředí v tom smyslu, že se o veřejnou zakázku de facto nemohou ucházet všichni dodavatelé, kteří by byli k jejímu plnění objektivně způsobilí.

Uchazeč Zadavatele žádá o přehodnocení výše smluvních pokut a zohlednění přiměřenosti smluvních pokut i vzhledem k předpokládané hodnotě veřejné zakázky, tak aby stanovením sankcí nedocházelo ke skryté diskriminaci potenciálních zájemců, a v tomto důsledku k omezení hospodářské soutěže u předmětné veřejné zakázky.

Odpověď zadavatele

Zadavatel provedl revizi uvedených sankcí, které upraví v čl. 25.3, 25.6. Ostatní ustanovení sankčního ujednání zůstávají s ohledem na svůj význam pro MZe beze změny.

06. 02. 2023

Otázka č. 1

Zadavatel uvádí v příloze č. 5 zadávací dokumentace (Hodnocení a hodnotící kritéria) mj. následující: ”Jedna konkrétní zakázka (tj. posuzovaný projekt, resp. aplikace), může být v hodnocení všech subkritérií B.1, B.2 a B.3, použita pouze jedenkrát.“

Chápe dodavatel tento požadavek správně tak, že u každé z uvedených pozic, které jsou předmětem hodnocení, lze využít určitý projekt pro účely hodnocení jen jedenkrát?

Odpověď zadavatele

Zadavatel upraví hodnotící kritérium v příloze ZD č. 5 Hodnocení a hodnotící kritéria. Jedna konkrétní zakázka (tj. posuzovaný projekt, resp. aplikace), může být v hodnocení použita ve všech subkritériích

B.1, B.2 a B.3, tzn. u jednotlivých osob (členů realizačního týmu) lze prokázat zkušenosti stejnou zakázkou.

06. 02. 2023

Otázka č. 1

Dotaz se týká nejasnosti ve vymezení hodnoticího kritéria A. Nabídková cena ve vztahu k nabídkové ceně a její struktuře. V dokumentu Příloha č. 5 ZD Hodnocení a hodnotící kritéria jsou uvedeny podmínky pro hodnocení takto:

„V rámci dílčího hodnotícího kritéria A. „Nabídková cena“ bude zadavatel hodnotit celkovou výši nabídkové ceny veřejné zakázky v Kč bez DPH. Nabídkovou cenou se pro účely hodnocení rozumí maximální celková cena za Paušální katalogové listy a Ad hoc služby, to znamená součet cen bez DPH za jednotlivé katalogové listy a Ad hoc služby. Za vhodnější bude považována nabídka s nižší nabídkovou cenou.“

V dokumentu ISVAK_příloha č. 1 ZD_Závazný text návrhu smlouvy jsou uvedeny jednotlivé katalogové listy, jak paušální, tak ad-hoc. Dále, v dokumentu ISVAK_příloha č. 1 ZD_Závazný text návrhu smlouvy, článek 3.2, je uveden předmět plnění, který se sestává ze závazku realizovat v 3.2.1 Etapy dodávky a nasazení IS VAK a dále v 3.2.2 Etapy Zajištění služeb (jak paušálních, tak ad-hoc). Obsah etapy Dodávky a nasazení IS VAK ale podle našeho názoru není součástí žádných katalogových listů, jak též plyne ze struktury Přílohy č. 3 Souhrnná cenová tabulka, kde je cena za dodávku a nasazení IS VAK uvedena samostatně.

Z uvedených dokumentů logicky vyplývá, že cena za dodávku a nasazení IS VAK není vůbec zařazena do hodnotících kritérií, což se jeví jako chybné.

Žádáme tímto Zadavatele o jednoznačné vymezení obsahu hodnotících kritérií ve vztahu k cenové struktuře.

Odpověď zadavatele

Zadavatel opraví znění přílohy č. 5 Zadávací dokumentace, tak, aby bylo zjevné, že předmětem hodnocení nabídkové ceny je kompletní dodávka IS VAK, dle finančního členění uvedeného v příloze č. 3 Smlouvy.

Otázka č. 2

Dotaz míří na nejasnost ve stanovení součtu celkové nabídkové ceny. V dokumentu ISVAK_příloha č. 1 ZD_Závazný text návrhu smlouvy, Příloha č. 3 v Tabulce č. 5: “Celková nabídková cena pro účely hodnocení” je uvedena instrukce, že do této tabulky se doplní součet celkových cen tabulek č. 1 - 4.

Vzhledem k tomu, že v případě paušálních cen se jedná o cenu služeb za jeden měsíc, považujeme instrukci za nepřesnou. Podle logiky věci, by se do této souhrnné tabulky měl uvést celkový součet paušálních plateb za celou dobu trvání smlouvy (paušální služby budou poskytovány po akceptaci etapy Dodávka a nasazení IS VAK, nicméně pro účely hodnocení by měl být počet měsíců stanoven jednoznačně).

Z našeho pohledu tedy buď chybí souhrnný řádek v Tabulce č. 2 “Maximální cena za 1 měsíc zajištění Paušálních služeb” s jednoznačným stanovením počtu měsíců pro započtení souhrnné ceny nebo je instrukce v Tabulce č. 5 nepřesná.

Z důvodu nejasnosti žádáme Zadavatele o revizi Přílohy č. 3.

Odpověď zadavatele

Zadavatel opraví zjevnou administrativní chybu v označení tabulky č. 2, kdy je požadováno nacenění jak za 1 měsíc poskytování paušálních služeb, tak celkové nacenění za 48 měsíců. Tuto změnu Zadavatel promítne do přílohy č. 3 smlouvy a uveřejní na profilu Zadavatele.

08. 02. 2023

Otázka č. 1

Zadavatel v Příloze č. 1 ZD, kapitola 13 Požadavky na systém IS VAK v REQ-033 uvádí:

„Součástí bezpečnostní dokumentace musí být:

• Mapování požadavků VKB na opatření přílohy A normy ČSN ISO/IEC 27001:2014“

V roce 2022 byla vydána nová verze normy ISO/IEC 27001:2022. Může Dodavatel mapovat požadavky VKB na opatření přílohy A nové verze normy, tedy 2022?

Odpověď zadavatele

Ano, dodavatel může mapovat požadavky VKB na opatření přílohy A nové verze normy, tedy 2022.

Otázka č. 2

Dokumentace, vymezená v rámci Přílohy č. 3 a v souladu s § 36 odst. 8 ZZVZ poskytnutá oproti podpisu Dohody o ochraně důvěrných informací, v části Bezpečnost, obsahuje odkazy na již zrušené předpisy

 316/2014 Sb., Vyhláška o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních a o stanovení náležitostí podání v oblasti kybernetické bezpečnosti (vyhláška o kybernetické bezpečnosti)

 101/2000 Sb., Zákon o ochraně osobních údajů a o změně některých zákonů

 137/2006 Sb., Zákon o veřejných zakázkách

Je správný předpoklad Dodavatele, že bude pracovat s platnými právními předpisy a že pokud je v interním předpisu Ministerstva zemědělství použit odkaz na zrušený právní předpis, bude Dodavatel pracovat s ekvivalentním požadavkem v aktuálně platném právním předpisu?

Odpověď zadavatele

Ano, předpoklad dodavatele je správný.

10. 02. 2023

Otázka č. 1

Zadavatel v příloze č. 1 ZD Závazný text návrhu smlouvy_final uvádí odkazy k stažení dokumentace k aplikacím MPVaK (verze určená pro zpracovatele evidence), MPVaK (verze určená pro vodoprávní úřady), VSVaK (zpracovatel).

Může Zadavatel uvést důvod proč obdobně, jako v případě výše uvedených podkladů, nedává k dispozici přístup k uživatelské dokumentaci modulů PPVaK a PRVaK? Uchazeč ve výše uvedených dokumentacích nalezl stěžejní informace, které předpokládá, že budou k dispozici také v nepublikovaných dokumentacích a obecně přispějí účastníkům tohoto výběrového řízení k lepšímu návrhu cílového řešení pro Zadavatele. Vzhledem k uvedenému Uchazeč upozorňuje Zadavatele na možný rozpor se zásadou rovného zacházení, která spočívá zejména v povinnosti Zadavatele zacházet stejným způsobem se všemi dodavateli (účastníky) v rámci celého průběhu zadávacího řízení realizovaného dle ZZVZ.

Odpověď zadavatele

Jelikož jsou data PPVaK a PRVAK neveřejná, budou k dispozici uchazečům na základě podpisu NDA.

Otázka č. 2

Zadavatel v příloze č. 1 ZD Závazný text návrhu smlouvy final uvádí, že zdrojový kód bude veden v GIT dle požadavků Objednatele.

Může Zadavatel upřesnit, zda zdrojové kódy stávajícího systému jsou vedeny v GIT a budou dostupné vybranému Dodavateli?

Odpověď zadavatele

Zadavatel disponuje zdrojovými kódy ke stávajícímu řešení GIT úložišti. Tato data budou k dispozici vítěznému uchazeči.

V Praze dne: shodné s datem a časem el. podpisu

Ing. Vladimír Velas

Digitálně podepsal Ing. Vladimír Velas

Datum: 2023.02.13

17:04:09 +01'00'

Česká republika – Ministerstvo zemědělství

Ing. Jan Waraus

ředitel Odboru informačních a komunikačních technologií v z. Ing. Vladimír Velas