Procurement observatory.

<!-- PAGE 1 -->## List1

| Název obchodní společnosti: Dodavatel č. 1 |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- |
|  |  | Komentář Dodavatele č. 1 | Vysvětlení/Reakce | Dopad do ZD (ANO/NE) | Způsob zapracování |
|  | Otázky k předmětu plnění |  |  |  |  |
|  | Kapitola 1: Stávající stav ICT zajištění agendy VaK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 2: Požadavky na nový systém |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 3: Základní požadavky na funkční celek |  |  |  |  |
|  |  | 1. identifikace části zadání: Notifikace, tiskové výstupy 2. popis nepřesnosti: Zadávací dokumentace předpokládá generování tiskových výstupů a e-mailových notifikací, není však zřejmé, zda zadavatel požaduje použití konkrétní technologie pro tvorbu šablon, případně zda volba technologie zůstává na dodavateli. 3. dopad zjištěné nepřesnosti: Nejednoznačnost může vést k odlišnému technickému řešení a má přímý dopad na odhad pracnosti. 4. návrh upřesnění: Doporučujeme zvážit upřesnění, zda požaduje použití konkrétní technologie nebo nástroje pro tvorbu a správu tiskových a e-mailových šablon, nebo zda je volba technologie plně na dodavateli. | Zadavatel nepožaduje použití konkrétní technologie ani nástroje pro tvorbu a správu tiskových výstupů a e-mailových notifikací. Volba konkrétního technického řešení je na dodavateli, za předpokladu splnění všech funkčních, provozních a bezpečnostních požadavků zadávací dokumentace. | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 4: Požadavky na agendovou komponentu – modul MP VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 5: Požadavky na agendovou komponentu – modul VS VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 6: Požadavky na agendovou komponentu – modul PP VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 7: Požadavky na agendovou komponentu – modul PR VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 8: Požadavky na agendovou komponentu Evidence technicko bezpečnostního dohledu (ETBD) |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 9: Požadavky na agendovou komponentu Samostatná evidence dokumentů (SED) |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 10: Požadavky na komponentu Jmenného rejstříku |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
| 4.&#9;Otázky k předpokládanému harmonogramu |  |  |  |  |  |
|  | Harmonogram realizace  | NE |  |  |  |
|  |  | Navrhované časy pro jednotlivé fáze nejsou dle našich zkušeností dostatečné. Riziková je především časová dotace na business analýzu, pro kterou navrhovaných 157MD je nedostatečných. Doporučujeme navýšení alespoň o 30MD | Zadavatel na základě připomínek získaných v rámci PTK prodlouží dobu na analýzu o 30 dní. | ANO | Úprava podmínek uvedených v Zadávací dokumentaci. |
|  | Možnost zkrácení | NE |  |  |  |
|  |  | Kritickým bodem implementace bude zajištění kapacit a součinnosti na straně Zadavatele. Doporučujeme, pokud je to možné, ponechat maximální možné časování, které Zadavatel může akceptovat. V opačném případě roste riziko nedodržení smluvních závazků nebo zanešení chyby.  | Zadavatel ponechá možnost nabídnout zkrácení doby realizace a související hodnoticí kritérium. Cílem Zadavatele je umožnit dodavatelům uplatnit jejich zkušenosti, kapacity, know-how a případné vlastní metodické či technologické postupy, které mohou vést k efektivnějšímu průběhu vývoje a rychlejšímu dodání řešení. Rozsah garantované součinnosti poskytované Zadavatelem je popsán v zadávací dokumentaci a Uchazeči by při stanovení nabízených termínů měli vycházet z těchto podmínek. Termín realizace nabídnutý Uchazečem v rámci tohoto hodnoticího kritéria bude pro vybraného dodavatele závazný. Zadavatel si je současně vědom skutečnosti, že v průběhu realizace mohou nastat okolnosti, které dodavatel nemůže objektivně ovlivnit, včetně případných prodlení způsobených na straně Zadavatele. Z tohoto důvodu smlouva obsahuje ustanovení, na jehož základě může dodavatel v odůvodněných případech požádat o prodloužení termínu plnění. Takový požadavek bude posouzen a případně schválen Zadavatelem v souladu se smluvními podmínkami. | NE |  |
|  | Zajištění dodržení harmonogramu | NE |  |  |  |
|  |  | V případě, že by Dodavatel sám navrhnul zkrácení harmonogramu, bude třeba zajistit kapacitně a kvalitativně silného zástupce pro pokrytí QA a koordinace mezi Dodavatelem a Zadavatelem. Případně doporučujeme zvážit řízení/koordinace některou z agilních metodik.  | Zadavatel ponechá možnost nabídnout zkrácení doby realizace a související hodnoticí kritérium. Cílem Zadavatele je umožnit dodavatelům uplatnit jejich zkušenosti, kapacity, know-how a případné vlastní metodické či technologické postupy, které mohou vést k efektivnějšímu průběhu vývoje a rychlejšímu dodání řešení. Rozsah garantované součinnosti poskytované Zadavatelem je popsán v zadávací dokumentaci a Uchazeči by při stanovení nabízených termínů měli vycházet z těchto podmínek. Termín realizace nabídnutý Uchazečem v rámci tohoto hodnoticího kritéria bude pro vybraného dodavatele závazný. Zadavatel si je současně vědom skutečnosti, že v průběhu realizace mohou nastat okolnosti, které dodavatel nemůže objektivně ovlivnit, včetně případných prodlení způsobených na straně Zadavatele. Z tohoto důvodu smlouva obsahuje ustanovení, na jehož základě může dodavatel v odůvodněných případech požádat o prodloužení termínu plnění. Takový požadavek bude posouzen a případně schválen Zadavatelem v souladu se smluvními podmínkami. | NE |  |
| 5.&#9;Otázky k požadované technické kvalifikaci |  |  |  |  |  |
|  | Seznam významných služeb |  |  |  |  |
|  | Obecné požadavky na seznam služeb  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Předmět plnění referenční služby | NE |  |  |  |
|  |  | Doporučujeme více specifikovat požadavky na finální podobu dodaného řešení. Např. HA, horizontální škálování, případně provozní prostředí cloud/on-premise.  | Zadavatel tyto striktní kritéria neuplatní, aby byla nedošlo k neúměrnému omezení hospodářské soutěže a potenciálně diskriminačnímu nastavení kvalifikačních podmínek. | NE |  |
|  |  |  |  |  |  |
|  | Požadavek na ISVS | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Služba na dodávku aplikace / IS | NE |  |  |  |
|  |  | Doporučujeme zvýšení částky na min. 10mil. Kč v posledních 5ti letech.  | Zadavatel se rozhodl neuplatnit striktnější kritéria, aby nedošlo k neúměrnému omezení hospodářské soutěže a potenciálně diskriminačnímu nastavení kvalifikačních podmínek. | NE |  |
|  |  |  |  |  |  |
|  | Služba na provoz aplikace / IS | NE |  |  |  |
|  |  | Doporučujeme zvýšení částky na min. 10mil. Kč v posledních 5ti letech. | Zadavatel se rozhodl neuplatnit striktnější kritéria, aby nedošlo k neúměrnému omezení hospodářské soutěže a potenciálně diskriminačnímu nastavení kvalifikačních podmínek. | NE |  |
|  |  |  |  |  |  |
|  | Seznam členů realizačního týmu a jejich kvalifikace |  |  |  |  |
|  | (1) Obecné požadavky na realizační tým | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (2) Minimálně jedna (1) osoba v kategorii role Solution Architekt splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (3)Minimálně jedna (1) osoba v kategorii role Aplikační architekt splňující následující požadavky:  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (4) Minimálně jedna (1) osoba v kategorii role Projektový manažer splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (5) Minimálně dvě (2) osoby v kategorii role Analytik IT senior splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (6) Minimálně pět (5) osob v kategorii role Vývojář splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (7) Minimálně jedna (1) osoba v kategorii role Tester splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (8) Minimálně jedna (1) osoba v kategorii role Bezpečnostní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (9) Minimálně jedna (1) osoba v kategorii role Manažer provozu splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (10) Minimálně dvě (2) osoby v kategorii role Provozní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (11) Minimálně jedna (1) osoba v kategorii role Specialista uživatelské podpory splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (12) Minimálně jedna (1) osoba v kategorii role SCRUM master splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
| 6.&#9;Otázky ke kritériím hodnocení |  |  |  |  |  |
|  | Celková nabídková cena: 30 % | NE |  |  |  |
|  |  | Sumarizace nákladů na pokrytí požadovaných služeb včetně rozvoje a podpory řešení neodpovídá maximální nabídkové ceně. Především 2760MD pro výkonové plnění je problematické a zásadně zdražuje celý projekt. Následná cena za 1MD blended se tímto dostává do nerealizovatelných úrovní ve srovná se současným trhem.  | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. | ANO | Úprava podmínek uvedených v Zadávací dokumentaci. |
|  | Návrh vybraných částí řešení: 30 % | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Prokázání odborných znalostí: 30 % | NE |  |  |  |
|  |  | Ověřování znalostí principů eGovernmentu pro účely hodnocení nabídek je z našeho pohledu zbytečné, příliš selektivní pro zachování regulérnosti veřejné soutěže a nepřináší projektu téměř žádnou přidanou hodnotu.  | Zadavatel s připomínkou nesouhlasí. Znalost principů eGovernmentu považuje za zásadní předpoklad úspěšné realizace informačního systému veřejné správy. Navrhované řešení musí být v souladu s principy eGovernmentu, požadavky Národního architektonického rámce a musí umožňovat využívání sdílených služeb veřejné správy, včetně základních registrů a dalších sdílených komponent eGovernmentu. Ověření znalostí této problematiky proto zadavatel nepovažuje za nadbytečné. | NE |  |
|  | Urychlení vývoje a dodání vybraných modulů: 10 % | NIC |  |  |  |
|  |  |  |  |  |  |
| 7.&#9;Další otázky zadavatele |  |  |  |  |  |
|  | Předpokládaná hodnota zakázky | NE |  |  |  |
|  |  | Po prostudování technických, funkčních i nefunkčních požadavků, doplňkových služeb služeb provozu a rozvoje vnímáme navrhovanou maximální cenu jako nedostatečnou a navrhujeme její navýšení. Po sečtení požadavků na vývoj, podporu a rozvoj s přihlédnutím k obvyklým cenám ICT prací dle zveřejněného benchmarku MVČR není uvažovaný scope v navrhované ceně realizovatelný.  | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. | ANO | Úprava podmínek uvedených v Zadávací dokumentaci. |
|  | Limity pro nabídkovou cenu | NE |  |  |  |
|  |  | Maximální cena 49 844 000Kč není dostatečná pro pokrytí nákladů na vývoj, rozvoj a podporu provozu. Jako dodavatel dále nechápeme požadavek na 2760MD rozvoje ve 4 letech, jelikož se tento rozsah blíží nákladům na realizaci celého nového díla.  | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. Limit pro výši nabídkové ceny byl na základě PTK zrušen, nabídková cena tedy může přesáhnout předpokládanou hodnotu VZ. | ANO | Úprava podmínek uvedených v Zadávací dokumentaci. |
|  | Platební podmínky | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Bankovní záruka | NE |  |  |  |
|  |  | Doporučujeme upřesnit, zda bankovní záruka bude uvolněna po ukončení výroby/implementace. V opačném případě bude zdražovat realizaci přenesením nákladů na Zadavatele.  | Záměrem zadavatele je požadovat bankovní záruku po celou dobu účinnosti smlouvy, proto zadavatel ponechá příslušná ustanovení zadávací dokumentace a smlouvy v původním znění. | NE |  |
|  | Lhůta pro podání nabídek | NE |  |  |  |
|  |  | Doporučujeme navýšit na 60dní.  | Zadavatel s ohledem na běžně používané lhůty již přistoupil k prodloužení lhůty pro podání nabídek z 30 na 45 dnů. Současně zadavatel realizoval předběžnou tržní konzultaci, v jejímž rámci měli potenciální dodavatelé možnost se v předstihu seznámit s očekávaným předmětem plnění. Úpravy zadávací dokumentace provedené na základě výsledků předběžné tržní konzultace mají převážně upřesňující a doplňující charakter a nepředstavují podstatnou změnu rozsahu ani charakteru předmětu plnění. S ohledem na výše uvedené skutečnosti zadavatel považuje stanovenou lhůtu pro podání nabídek za dostatečnou a ponechává ji v délce 45 dnů. | NE |  |
|  |  |  |  |  |  |
| Další připomínky mimo formulář |  | Nejsou |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
| Název obchodní společnosti: Dodavatel č. 2 |  |  |  |  |  |
|  |  | Komentář Dodavatele č. 2 | Vysvětlení/Reakce | Dopad do ZD (ANO/NE) | Způsob zapracování |
|  | Otázky k předmětu plnění |  |  |  |  |
|  | Kapitola 1: Stávající stav ICT zajištění agendy VaK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 2: Požadavky na nový systém |  |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Kapitola 2.3. Požadavky na použité technologie a architekturu technologické vrstvy 2. popis nepřesnosti: Text opakovaně odkazuje na „kapitolu 11“ resp. „kapitolu 11.9“ (např. „podklad pro vlastní analýzu... podrobnosti viz 11.9“, „ 3. dopad zjištěné nepřesnosti: nelze jednoznačně dohledat, na kterou konkrétní část specifikace text odkazuje, což zvyšuje riziko nejednotného výkladu rozsahu požadované dokumentace. 4. návrh upřesnění: Doporučujeme opravit/doplnit číslování kapitol  | Text specifikace předmětu veřejné zakázky bude upřesněn a bude provedena kontrola odkazů na jednotlivé kapitoly. | ANO | Vysvětlující text k výstupům Detailní implementační analýzy je nyní uveden jako podkapitola 2.11.2. |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Kapitola 2.7 Požadavky na kapacitu a výkonnost funkčního celku 2. popis nepřesnosti: Text na dvou místech odkazuje na počty uživatelů uvedené v „tabulkách 5-7“ resp. „tabulce 5“, avšak příslušné tabulky jsou v dokumentu ve skutečnosti očíslovány jako „Tabulka 1“ (VAK a ETBD), „Tabulka 6“ (SED) a „Tabulka 7“ (Jmenný rejstřík) – číslo „5“ pro tabulku VAK/ETBD v dokumentu není použito. 3. dopad zjištěné nepřesnosti: Nesoulad číslování tabulek může vést k záměně, ke které tabulce se požadavek na kapacitu/zátěžové testování skutečně vztahuje. 4. návrh upřesnění: Doporučujeme opravit číslo tabulky 1 na tabulku 5 | Text specifikace předmětu veřejné zakázky bude upřesněn a číslování odkazů na tabulky opraveno. | ANO | Prevedena oprava označení tabulky v kapitole 2.7. |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Kapitola 2.5 Uživatelé a jejich role 2. popis nepřesnosti: V textu specifikace jsou použity Zkratky „CAAIS“ a „PKCE“, ale v úvodním seznamu „Použité termíny a zkratky“ chybí. 3. dopad zjištěné nepřesnosti: Chybějící definice zkratek v úvodním přehledu ztěžuje orientaci čtenáři, který se s pojmy CAAIS/PKCE nesetkal, a snižuje formální úplnost dokumentu. 4. návrh upřesnění: Doporučujeme doplnit zkratky CAAIS a PKCE (včetně stručného vysvětlení) do úvodního seznamu použitých termínů a zkratek. | Text specifikace předmětu veřejné zakázky bude upřesněn a tabulka pojmů doplněna o tyto zkratky. | ANO | Termín CAAIS byl doplněn do přehledu termínů a zkratek. Termín PKCE je vysvětlen v textu v místě výskytu. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitola 2.14 Předání funkčního celku 2. stávající formulace: Ukončení jakéhokoliv Milníku či Fáze 4 je podmíněno úspěšným akceptováním výstupů příslušného Milníku či Fáze, které konstatuje, že předávané výstupy neobsahují vady kategorie A a B 3. návrh nového znění: Ukončení jakéhokoliv Milníku či Fáze 4 je podmíněno úspěšným akceptováním výstupů příslušného Milníku či Fáze, které konstatuje, že předávané výstupy neobsahují vady kategorie A a je identifikováno nanejvýš 5 chyb kategorie B. 4. potvrzení vazby na cíl a účel: Je vhodné mít v akceptačních kritériích nenulový počet vad kategorie B z důvodu, aby chyby, které sice omezují běžný provoz, ale nepřevyšují svým dopadem dopad odložení nasazení systému do produkce, mohly být vyřešeny až v rámci provozu po akceptaci s výhradou. Cíl a účel zadání se tím nemění. 5. popis zjednodušení: Úprava umožňuje zadavateli předat do provozu systém flexibilněji a na základě dohody s dodavatelem řešit prioritu vad. 6. dopad navrhované úpravy: Zjednodušení nasazení systému do produkce a zvýšení pravděpodobnosti dodržení harmonogramu. | Zadavatel nepovažuje za účelné přebírat do provozu dílo, které má chyby kategorie A nebo B, proto ponechá ustanovení týkající se finální akceptace beze změny. | NE |  |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitola 2.4 Integrace systému (AgriBus, integrační rámec). 2. stávající formulace: Integrace probíhají přes AgriBus, jsou vyjmenovány napojené systémy (SEPO, ZR, SED, Jmenný rejstřík, AgriGIS) a je umožněn návrh alternativ v implementační analýze. 3. návrh nového znění: Doplnit pododdíl „Jednotná datová páteř ISVaK–DTM–PRVK/GIS“, který závazně stanoví: • referenční identifikátory pro průřezovou evidenci: IČME (majetek), IČPE (provozní celky), IDVD (vodní díla), ID karty PRVAK (obec/část/soustava) jako povinné pole všech API a exportů; • procesy a periodicitu synchronizace (min. roční + ad hoc při změně), verzování a audit dat napříč komponentami přes AgriBus; • povinné uchování vazeb na zdroj (ID prvku DTM, datum/verze datové sady) u prostorově vázaných objektů. 4. potvrzení vazby na cíl a účel: Úprava nemění cíl centralizovat administraci a odstranit souborové přenosy; zpřesňuje integrace tak, aby ISVaK plnil roli referenční evidence pro PRVAK a DTM/GIS. 5. popis zjednodušení: Jednoznačné ID a verzování sníží integrační ambiguitu, zlepší dohledatelnost a omezí manuální slaďování. 6. dopad navrhované úpravy: Nepožaduje změnu architektury, jde o upřesnění rozhraní a SLA; malé navýšení prací v analýze a integrační vrstvě. | Integrace mezi Digitální technickou mapou (DTM) a systémy MZe bude realizována prostřednictvím systému AgriGIS. Není proto účelné ani potřebné podrobně specifikovat tuto část integrace v rámci veřejné zakázky na IS VaK. Zadavatel současně považuje používání jednoznačných identifikátorů v integračních rozhraních za standardní součást návrhu řešení. Konkrétní rozsah a způsob využití identifikátorů bude vycházet z datových struktur a identifikátorů vedených v příslušných zdrojových systémech, zejména v DTM (např. IČME). Zadavatel nepovažuje za nutné závazně stanovovat navrhované procesy synchronizace, verzování a auditních vazeb mezi DTM a ostatními systémy, neboť tyto oblasti budou řešeny v rámci navrhované integrační architektury jednotlivých systémů a nejsou předmětem plnění IS VaK. Integrace na DTM zajišťuje systém AgriGIS. | NE |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. Identifikace části zadání: Kapitola 2.16 „Integrace se systémem AgriGIS" — požadavek na mechanismus předání kontextu a autorizace dat mezi Funkčním celkem a mapovou aplikací. 2. Popis nepřesnosti: Zadávací dokumentace stanovuje, že „v opačném směru musí být umožněno, aby mapová aplikace ověřila oprávnění uživatele a získala seznam agendových prvků, ke kterým má daný uživatel přístup" prostřednictvím „služby vystavené systémem, která na základě identity uživatele vrátí odpovídající množinu dat". Zadání však nespecifikuje, jakým způsobem bude tato služba autentizovat identitu uživatele přicházejícího z mapové aplikace. Rovněž není jasné, zda musí být tato služba vystavena přes ESB AgriBus, nebo přímo. 3. Dopad zjištěné nepřesnosti: Architektonické rozhodnutí o způsobu autentizace identity v tomto integračním bodě ovlivňuje návrh bezpečnostní architektury, rozsah analytické fáze (Fáze 2) i celkový odhad pracnosti. Různí dodavatelé mohou navrhnout nekompatibilní řešení, která splňují literu zadání, ale nikoliv záměr zadavatele. To ohrožuje porovnatelnost nabídek. 4. Návrh upřesnění: Zadavatel doplní do zadávací dokumentace popis stávajícího integračního vzoru, který je používán u jiných agendových systémů MZE pro předávání identity do AgriGIS. Pokud takový vzor dosud neexistuje, doporučujeme tuto skutečnost v zadání explicitně uvést a nechat na dodavateli návrh schválený Objednatelem v rámci implementační analýzy. | Zadavatel v tomto bodě upřesní, že předmětná integrace nebude realizována prostřednictvím ESB AgriBus. Komunikace mezi Funkčním celkem a systémem AgriGIS bude řešena prostřednictvím aplikačního rozhraní (API). Konkrétní způsob předávání identity uživatele a autorizace přístupu k datům není v této fázi stanoven. Jeho návrh bude součástí implementační analýzy dodavatele a musí respektovat bezpečnostní a architektonické požadavky objednatele. Navržené řešení bude podléhat schválení objednatele. | NE |  |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kap. 2.16 Integrace se systémem AgriGIS. 2. stávající formulace: AgriGIS je popsán jako vizualizační integrace s předáním kontextu z EVI do mapové aplikace a opačným ověřením oprávnění pro zobrazení. 3. návrh nového znění: Rozšířit na obousměrnou integraci s DTM/GIS: • povinný zápis a údržba vazeb EVI ↔ DTM (ID geo-prvku, verze vrstvy) u všech prostorových objektů; • služba pro „spatial reconcile“: při změně geometrie v DTM/AgriGIS založí (nebo označí) změnu v EVI a PRVAK kartě; • exportní API musí vždy uvádět identifikátory (IČME/IČPE/IDVD/ID karty) + metadata verze GIS/DTM. 4. potvrzení vazby na cíl a účel: Cíl zůstává, integrace s AgriGIS je již vyžadována; doplnění z ní dělá datovou (nejen mapovou) vazbu. 5. popis zjednodušení: Minimalizuje rozpad dat mezi ISVaK, PRVAK a DTM a zrychlí aktualizace. 6. dopad navrhované úpravy: Bez zásahu do základní architektury; rozšíření API, mapové služby a metadat. | Zadavatel v rámci požadované integrace se systémem AgriGIS nepředpokládá realizaci editací ani správu dat v Digitální technické mapě (DTM). Systém AgriGIS je v tomto případě konzumentem prostorových dat a ani jeho prostřednictvím nebude prováděna editace dat vedených v DTM. Požadovaná integrace je zamýšlena především pro účely zobrazení a využití prostorového kontextu dat evidovaných ve Funkčním celku. Zadavatel proto nepožaduje implementaci mechanismů pro synchronizaci změn do DTM, správu verzí prostorových objektů ani obousměrnou datovou integraci v navrhovaném rozsahu. Předávání identifikátorů objektů prostřednictvím integračních rozhraní zadavatel považuje za standardní součást návrhu integračního řešení. Detailní návrh struktury rozhraní a předávaných dat bude předmětem implementační analýzy a následné součinnosti mezi dodavatelem IS VaK a dodavatelem systému AgriGIS. | NE |  |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. Identifikace části zadání: Kapitola 2.16 „Integrace se systémem AgriGIS". 2. Stávající formulace: „Předání kontextu bude realizováno prostřednictvím parametrizovaného volání mapové aplikace (např. URL parametrů nebo lehkého API), přičemž systém poskytne identifikátory nebo filtrační kritéria pro zobrazení dat." 3. Návrh nového znění: Doporučujeme doplnit: „Zadavatel poskytne vítěznému dodavateli po podpisu smlouvy popis technického rozhraní AgriGIS relevantního pro tento integrační bod, včetně dokumentace způsobu autentizace identity uživatele a struktury filtračních parametrů. Dodavatel na základě těchto podkladů navrhne konkrétní implementaci v rámci implementační analýzy; návrh podléhá schválení Objednatele." 4. Potvrzení vazby na cíl a účel: Navrhovaná úprava nemění cíl — konzistentní řízení přístupu mezi Funkčním celkem a mapovou aplikací. Pouze explicitně přesouvá zodpovědnost za definici integračního vzoru na stranu, která má přístup ke stávající architektuře AgriGIS. 5. Popis zjednodušení: Dodavatel nebude muset spekulovat o interním fungování AgriGIS a navrhovat řešení „do prázdna". Snižuje se riziko odmítnutí architektonického návrhu v implementační analýze. 6. Dopad navrhované úpravy: Žádný dopad na harmonogram ani cenu, pokud jsou podklady předány v rámci NDA materiálů po podpisu smlouvy (jak je v zadání již předvídáno). Pozitivní dopad na kvalitu architektonického návrhu a na porovnatelnost nabídek. | Zadavatel upřesní specifikaci integračního rozhraní se systémem AgriGIS, zejména ve vztahu k odpovědnosti za návrh a implementaci integračního řešení. Zadavatel poskytne dodavateli v průběhu realizační fáze dostupné podklady nezbytné pro návrh integrace. Současně však upozorňuje, že technické možnosti integračního řešení jsou do značné míry dány technologickou platformou ESRI ArcGIS Enterprise a funkcionalitami poskytovanými systémem AgriGIS. Konkrétní návrh způsobu předávání kontextu, identity uživatele a využití dostupných integračních mechanismů bude součástí implementační analýzy dodavatele a bude podléhat schválení objednatele. | ANO | Do kapitoly 2.16 byl doplněn odkaz na dokumentaci produktu. |
|  |  |  |  |  |  |
|  | Kapitola 3: Základní požadavky na funkční celek |  |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Kapitola 3.5 Chyby v datech a práce s nimi“ – pravidla pro chybu kategorie 4 (Odchylka). 2. popis nepřesnosti: Specifikace uvádí, že chybu kategorie 4 (Odchylka) nebude možné zneaktivnit, ale nevysvětluje důvod tohoto omezení. 3. dopad zjištěné nepřesnosti: Chybějící odůvodnění může vést k uživatelským dotazům a nejasnostem při akceptačním testování. 4. návrh upřesnění: Doporučujeme doplnit do specifikace stručné odůvodnění, proč nelze chybu kategorie 4 (Odchylka) zneaktivnit/skrýt, případně zvážit umožnění uživatelského skrytí neblokující odchylky bez vlivu na hodnocení bezchybnosti záznamu. | Ze Zadávací dokumentace vyplývá, že Chyba kategorie 4 je jen odchylka a nemá vliv na blokaci nebo označení záznamu "s chybou". Z tohoto důvodu není potřeba ji zneaktivňovat. | NE |  |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitola 3.11 Správa číselníků (hierarchie, kaskády). 2. stávající formulace: Evidence hierarchických číselníků KÚ–ORP, vazby a kaskádové doplňování údajů; možnost aktualizací z jiných systémů, verzování a audit číselníků. 3. návrh nového znění: Doplnit závazný „Model hierarchie soustav“ (obecní/skupinové/regionální soustavy) a jeho uplatnění napříč moduly (MP, VS, PP, PR VAK) včetně kaskádových agregací; uložit povinnost kaskádových kontrol (blokace u porušení hierarchie) a synchronizovaných číselníků sdílených s PRVAK a DTM (např. karty soustav, aglomerace). 4. potvrzení vazby na cíl a účel: Zpřesnění číselníků podporuje stávající kontrolní logiku a sjednocené UI; cíl se nemění. 5. popis zjednodušení: Vynutí konzistenci napříč moduly a eliminuje duplicitní lokální „pravdy“. 6. dopad navrhované úpravy: Úprava definic číselníků a validací; bez změny architektury. | Požadavky na shlukování a hierarchii vychází z fungování stávající aplikace IS VAK. Zadavatel v zadávací dokumentaci požaduje zachování funkcionality stávajícího modulu PR VAK. S ohledem na tato fakta nepovažujeme za nutné stanovovat "závazný model hierarchie". Dodavatel může v rámci implementační analýzy doplnit požadovanou funkcionalitu o vylepšení a rozšíření, tato podléhají schválení Zadavatele. | NE |  |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitola 3.4 Spouštění datových kontrol (kvalita dat a reporting). 2. stávající formulace: Definovány formální/validační/kombinované kontroly, ukládání do „Protokolu chyb“ a jejich spouštění i přes API. 3. návrh nového znění: Doplnit kategorie „mezi-systémových kontrol“ konzistence (ISVaK–PRVAK–DTM) a povinný kvartální reporting KPI kvality dat (úplnost ID, vazby na DTM, chybovost) do rolí MZE/KÚ; zavést centrální číselník přeshraničních kontrol a SLA na jejich běh. 4. potvrzení vazby na cíl a účel: Kontrolní rámec už je součástí zadání; rozšíření posiluje datovou kvalitu bez změny účelu. 5. popis zjednodušení: Pravidelný přehled kvality dat umožní řídit nápravu a zkrátí řešení incidentů. 6. dopad navrhované úpravy: Rozšíření kontrol a dashboardů; bez dopadu na architekturu | Zadavatel neidentifikuje tento požadavek na funkcionalitu Funkčního celku. | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 4: Požadavky na agendovou komponentu – modul MP VAK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Kapitola 4.6 „Požadavky na proces“ popis stavů hlášení a pravidel pro editaci záznamu. 2. popis nepřesnosti: Specifikace životního cyklu hlášení MP VAK vyjmenovává stavy Přijaté → Ve zpracování → Zpracované (a Zrušené / Zneplatněné / Vráceno k doplnění); stav „Převzaté“ mezi nimi není. Text ale dále uvádí, že editaci může uživatel spustit „ve stavu Převzaté“ — tento stav v životním cyklu MP VAK neexistuje (na rozdíl od VS VAK, kde existuje). 3. dopad zjištěné nepřesnosti: Odkaz na neexistující stav je nejednoznačný a ztěžuje jednoznačnou implementaci pravidel pro editaci. 4. návrh upřesnění: Doporučujeme opravit/upřesnit, ve kterém z reálně existujících stavů životního cyklu MP VAK (pravděpodobně „Ve zpracování“) je editace záznamu skutečně povolena. | Zadavatel upraví zadavací dokumentaci v navrženém smyslu. V rámci zpracování dokumentace došlo k přejmenování a stav "Převzaté" je nyní označován "Ve zpracování". Z funkčního hlediska jsou oba stavy identické. | ANO | Došlo ke sjednocení označení stavů, v kapitole zaměřené na modul VS VAK a MP VAK. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitoly 4.3 (MP VAK integrace); 6.2 (PP VAK integrace); 7.3 (PR VAK integrace). 2. stávající formulace: Napojení na SEPO/SED/Jmenný rejstřík; v MP VAK generování IČME ID pro FO; v PR VAK obecné vazby na SED. 3. návrh nového znění: Stanovit povinnost uvádět a validovat IČME/IČPE/IDVD/ID karty PRVAK ve všech integračních výměnách (SEPO/SED/AgriBus) a exportech; chybějící nebo nevalidní identifikátor = blokační chyba při příjmu dat; doplnit povinné mapování na DTM (ID geo prvku + verze) pro prostorové agendy. Doplnit datový model o geoprostorové informace a topologii 4. potvrzení vazby na cíl a účel: Nemění účel modulů, posiluje jednoznačnost a dohledatelnost napříč systémy. 5. popis zjednodušení: Méně kolizí při párování záznamů a rychlejší automatizované kontroly. 6. dopad navrhované úpravy: Úpravy schémat API a validátorů; bez změny architektury. | Zadavatel doplní zadávací dokumentaci v navrženém smyslu a specifikuje požadavek na kontrolu identifikačních atributů prvků ve vzájemné komunikaci. | ANO | Text zaměřený na požadavek kontroly a validace identifikátorů byl vložen do kapitoly 2.4. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitola 4 (modul MP VAK) — požadavky na shodu s funkcionalitou stávající aplikace (ř. 1200, 1231, 1240, 1538, 1548, 1552); v návaznosti Kap. 7 (modul PR VAK, ř. 2389), kde je požadavek na kopírování stávajícího rozhraní explicitně rozšířen i na MP VAK a VS VAK. 2. stávající formulace: Zadání na několika místech modulu MP VAK stanovuje, že rozhraní, funkčnost a v jednom případě i výpočetní logika a pojmenování mají vycházet ze stávající aplikace IS VaK (např.: "Objednatel požaduje realizovat funkcionalitu v rozsahu a v souladu (tj. pojmenování, způsob výpočtu, umístění atd.) s funkcionalitou stávající aplikace"; "Rozhraní a funkčnost této stránky bude vycházet z rozložení grafického rozhraní stávající aplikace MP VAK"). V modulu PR VAK zadání dále přímo požaduje, aby zobrazení "kopírovalo" stávající kompaktní rozhraní, a to obdobně i pro MP VAK a VS VAK. 3. návrh nového znění: Doporučujeme Objednateli zvážit přeformulování těchto požadavků z vázání na konkrétní vzhled/pojmenování/umístění stávající aplikace na vázání na zachování funkčního obsahu a rozsahu (tj. jaké informace, výpočty a operace musí být uživateli k dispozici), bez závazného požadavku na kopírování konkrétního grafického rozhraní nebo přesného pojmenování legacy aplikace. Konkrétně navrhujeme u těchto bodů doplnit formulaci umožňující dodavateli navrhnout modernizované/zjednodušené rozhraní 4. potvrzení vazby na cíl a účel: Cíl zadání — zajistit uživatelům MP VAK a PR VAK plnohodnotnou náhradu stávající funkcionality bez ztráty informací nebo pracovních postupů — se nemění. Návrh pouze odděluje požadavek na funkční/obsahovou kontinuitu od požadavku na vizuální/pojmenovací kopii konkrétní legacy aplikace. 5. popis zjednodušení: Umožní dodavateli navrhnout jednotné, moderní a konzistentní uživatelské rozhraní napříč agendovými moduly Funkčního celku (MP VAK, PR VAK, VS VAK, PP VAK), místo replikace čtyř historicky oddělených a vzájemně odlišných rozhraní stávajících aplikací. Snižuje riziko přenesení zastaralých UX vzorů do nového řešení a zjednodušuje školení uživatelů, kteří budou pracovat s jedním konzistentním rozhraním. 6. dopad navrhované úpravy: Bez dopadu na rozsah požadované funkčnosti. Může mít pozitivní dopad na cenu a harmonogram implementace (menší vázanost na analýzu a replikaci specifik čtyř legacy rozhraní) a na budoucí udržitelnost řešení | Dodavatel je oprávněn v rámci předložení grafického návrhu navrhnout vlastní úpravy či vylepšení řešení. Takové návrhy však vždy podléhají předchozímu schválení Objednatele. Pokud Dodavatel předloží návrh, který se odchyluje od požadavků stanovených Zadávací dokumentací, a Objednatel takový návrh neschválí, nelze předložení takového návrhu považovat za splnění povinnosti Dodavatele na předložení návrhu řešení v souladu se zadáním. Za splnění této povinnosti lze považovat pouze návrh odpovídající požadavkům Zadávací dokumentace, případně návrh odchylující se od zadání, který byl Objednatelem výslovně schválen. | ANO | Text explicitně upravující možnost Dodavatele navrhovat vlastní řešení uživatelského rozhraní byl doplněn do kapitoly 2.11.3, která se zabývá výstupy analytické fáze projektu. |
|  |  |  |  |  |  |
|  | Kapitola 5: Požadavky na agendovou komponentu – modul VS VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 6: Požadavky na agendovou komponentu – modul PP VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 7: Požadavky na agendovou komponentu – modul PR VAK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. Identifikace části zadání: Kapitola 7.2 „Požadavky na zpracování dat" — výpočet průniku majetku s hranicemi obcí ve spolupráci se systémem AgriGIS. 2. Popis nepřesnosti: Zadávací dokumentace uvádí, že systém „provede nápočet průniku majetku s danými částmi obce" a že tuto funkcionalitu zajistí „ve spolupráci se systémem AgriGIS", přičemž výsledkem je „součet hodnot reprodukční pořizovací ceny majetků evidovaných průnikem fyzického výskytu infrastrukturních prvků s vymezenými hranicemi obcí a částí obcí". Fyzický výskyt infrastrukturního prvku na území obce (tj. přítomnost jakéhokoli bodu geometrie prvku v hranici obce) je jako princip srozumitelný. Zadání však nespecifikuje, která ze dvou komponent — Funkční celek, nebo AgriGIS — má prostorový průnik fakticky vyhodnotit, ani jakým způsobem budou výsledky průniku předány do Funkčního celku pro následný výpočet reprodukční pořizovací ceny. 3. Dopad zjištěné nepřesnosti: Prostorový průnik polygonů (hranice obcí/částí obcí) s geometriemi infrastrukturních prvků je ze své podstaty GIS operace, pro jejíž spolehlivé a výkonné vyhodnocení je přirozeným nástrojem geografický informační systém. MZe přitom již provozuje platformu AgriGIS (ArcGIS Enterprise), která disponuje nativní podporou prostorových analýz tohoto typu. Pokud by tuto operaci měl provádět Funkční celek vlastními prostředky (tj. mimo GIS), znamenalo by to nutnost implementovat prostorový výpočetní engine, spravovat aktuální vrstvu hranic obcí/částí obcí a zajistit jejich synchronizaci se RÚIAN — a to vše duplicitně vedle existující GIS infrastruktury MZe. Nejasnost v rozdělení zodpovědností tak přímo ovlivňuje architektonický návrh, odhad pracnosti i provozní model. 4. Návrh upřesnění: Zadavatel doplní, zda vyhodnocení prostorového průniku infrastrukturních prvků s hranicemi obcí a částí obcí bude v gesci systému AgriGIS (který k tomu má nativní prostorové analytické nástroje a přístup k referenčním geodatům), nebo Funkčního celku. Pokud bude tato operace svěřena AgriGIS, zadavatel upřesní: (a) způsob a frekvenci předání výsledků průniku do Funkčního celku (synchronní API / asynchronní batch), (b) strukturu a formát předávaných dat, (c) referenční vrstvu hranic obcí a částí obcí, která bude pro průnik použita (RÚIAN, případně jiný zdroj spravovaný v AgriGIS). Využití stávající GIS infrastruktury MZe pro tento účel se jeví jako přirozené a provozně efektivní řešení, které zamezí duplicitní implementaci prostorových výpočtů mimo GIS platformu. | Zadavatel upřesní dokumentaci v tom smyslu, aby bylo zřejmé, že systém AgriGIS pouze vyhodnotí prostorový průnik a zapíše výsledek do databáze. Hodnocení a výpočet reprodukční požizovací ceny nebo jiných statistických údajů je na agendovém informačním systému. | ANO | Text byl doplněn do podkapitoly 7.2. |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. Identifikace části zadání: Kapitola 7.2 „Požadavky na zpracování dat" — integrace s DTM krajů prostřednictvím atributu IČME 2. Popis nepřesnosti: Zadání předpokládá napojení IS VaK na DTM krajů, aniž by zohledňovalo skutečnou dvouvrstvou architekturu systému. IS DMVS provozovaný ČÚZK funguje jako centrální agregační brána nad všemi 14 krajskými IS DTM a poskytuje jednotné rozhraní (R19–R29), prostřednictvím kterého lze pokrýt území všech krajů jediným napojením. 3. Popis dopadu: Nejednoznačnost formulace může vést k podhodnocení nebo nadhodnocení rozsahu díla, nejasné architektuře řešení a neurčené odpovědnosti za správu přístupových oprávnění. 4. Návrh upřesnění: zadavatel by měl zvážit, zda napojení na centrální prvek systému IS DMVS nepostačuje a zda tedy přímá integrace na 14 krajských API je nebo není technicky nutná. | Zadavatel z části nesouhlasí s uvedeným tvrzením. Není požadováno napojení komponenty VAK na DTM/DMVS. Na DTM bude napojen systém AgriGIS. Zadavatel ovšem provede úpravu textu v tom smyslu, aby bylo zřejmé, že data budou konzumována z DMVS nikoliv z jednotlivých DTM krajů. | ANO | V textu byla provedena změna z označení DTM na DMVS v podkapitole 7.2. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. Identifikace části zadání: Kapitola 7.10 Statistické sestavy a přehledy. 2. Stávající formulace: „Rozsah a ergonomie poskytování statistických sestav a přehledů bude vycházet ze stávajících verzí modulu PR VAK. Kromě toho nově bude modul poskytovat statistické údaje o investičních nákladech v jednotlivých územních nebo jiných celcích." 3. Návrh nového znění: Doporučujeme doplnit: „Statistické výstupy na úrovni územních celků (ORP, kraj, povodí, ČR) budou exportovatelné ve strukturovaném formátu (minimálně XLSX, CSV) obsahujícím jednoznačné identifikátory územních celků (kód ORP, kód kraje dle RÚIAN) umožňující jednoznačné geografické přiřazení při zpracování v navazujících analytických nebo mapových nástrojích." Zároveň doporučujeme vyjasnit, zda výstupy PR VAK budou předávány do externích analytických nástrojů (benchmarking SOVAK, roční zprávy MZe) a v jakém formátu tyto nástroje data přijímají. 4. Potvrzení vazby na cíl a účel: Navrhovaná úprava nijak nemění věcný záměr zadavatele — poskytovat statistiku investičních nákladů po územních celcích. Pouze explicitně definuje výstupní formát tak, aby exportovaná data byla bez dalšího zpracování použitelná v navazujících analýzách. 5. Popis zjednodušení: Zabrání se situaci, kdy exportovaná data obsahují pouze textové názvy obcí/ORP (které jsou náchylné na překlepy a změny) místo standardizovaných číselných kódů z RÚIAN. Snižuje se pracnost zpracování na straně analytických nástrojů. 6. Dopad navrhované úpravy: Minimální dopad na implementaci (přidání atributů kódů RÚIAN do exportního modulu). Pozitivní dopad na datovou kvalitu a interoperabilitu výstupů. | Zadavatel provede upřesnění v tom smyslu, že zvýrazní požadavek na možnost exportu součtových údajů. | ANO | Text byl doplněn do podkapitoly 7.10. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitola 7.2 Požadavky na zpracování dat; 7.1/7.11 Karty a agregace. 2. stávající formulace: Součty přes hierarchii správního členění, průniky s AgriGIS a požadavek na propojení s DTM přes IČME (stávající i návrhové stavy). 3. návrh nového znění: Uložit povinnost evidovat u každé Karty PRVAK odkaz na příslušné DTM prvky a jejich verzi; definovat „propagační pravidla“: změna prvku v PRVAK/DTM vyvolá přenesení změny do ISVaK (nebo založení úlohy pro verifikaci); doplnit „ID karty soustavy“ a model nadobecních soustav (vazby a agregace) jako závazný číselník. Doplnit datový model geoprostorové informace, plánovaní s využitím topologie a prostorových dotazů/analýz. 4. potvrzení vazby na cíl a účel: PR VAK už počítá s agregacemi a vazbou na DTM/AgriGIS; doplnění je zpřesňuje. 5. popis zjednodušení: Automatizované sčítání a aktualizace bez ručního přepisu, vyšší konzistence. 6. dopad navrhované úpravy: Rozšíření datového modelu karet a integrací; bez změny architektury. | Údržba proměnlivých údajů uvedených v DMVS v rámci IS VAK se nezdá jako vhodný architektonický vzor. IS VAK bude skrze AgriGIS využívat aktuální data DMVS. Prvky v DMVS budou mít v sobě uvedený identifikátor IČME, přes který bude možné data párovat s údaji IS VAK. Jednotlivé části obce budou mít, na základě prostorového průniku realizovánu vazbu s infrastrukturním majetkem, tento nápočet zajistí systém AgriGIS a není součástí realizace veřejné zakázky, která byla předmětem PTK. Zadavatel provede doplní zadávací dokumentace v tom smyslu, že u jednotlivých evidovaných jednotek v rámci modulu PR VAK (tj. část obce, městská část, obec) budou uvedeny identifikátory IČME, které se tam vyskytují. | ANO | Text byl doplněn do podkapitoly 7.10. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitola 7 (modul PR VAK) a Kap. 8 (ETBD), v návaznosti na Kap. 2, sekce „Integrace se systémem AgriGIS". 2. stávající formulace: Zadání u PR VAK stanovuje funkční spolupráci s AgriGIS (nápočet průniku majetku, propojení s DTM) a u ETBD integraci s AgriGIS (ArcGIS Enterprise) pro automatické předvyplnění geografických atributů a mapové okno. Zadání ale u žádného z modulů nestanovuje, že by měly být přímo implementovány nad platformou ArcGIS Enterprise, na které AgriGIS již dnes běží. 3. návrh nového znění: Doporučujeme výslovně stanovit, že moduly PR VAK a ETBD budou implementovány nad platformou ArcGIS Enterprise (ESRI), tedy nad stejnou platformou, na které běží AgriGIS. Důvodem je jejich funkční závislost na prostorových datech (u PR VAK nápočet průniku majetku a vazba na DTM, u ETBD automatické doplnění geoatributů a mapové okno) a skutečnost, že nad platformou ArcGIS je provozován také Národní prováděcí plán, využívající obdobné datové modely, mapové služby a integrační mechanismy — využití stejné platformy tak snižuje rizika spojená s jeho provozem, rozvojem a správou a umožňuje zachovat kontinuitu bez nutnosti migrace nebo paralelního vývoje funkcionalit. Doporučujeme Objednateli zvážit obdobný přístup i u dalších modulů s prostorovým rozměrem, včetně MP VAK. 4. potvrzení vazby na cíl a účel: Cíl modulů PR VAK a ETBD nemění; návrh se týká pouze upřesnění technologické platformy, na které jsou realizovány již popsané GIS závislosti. 5. popis zjednodušení: Jednotná platforma pro PR VAK, ETBD, AgriGIS a Národní prováděcí plán odstraňuje potřebu synchronizace dat mezi odlišnými GIS technologiemi a zjednodušuje sdílení datových modelů a mapových služeb. MZe už má licenci k ESRI pro účely NPP, tedy využití ESRI pro IS VaK by nevyžadovalo žádné nové pořízení ze strany MZe. 6. dopad navrhované úpravy: Upřesnění zadání a stanovení technologie ESRI by umožnilo •&#9;Zvýšení kvality řešení – zvýšení komfortu uživatelů při práci s daty •&#9;Zvýšení využitelnosti dat pro reporting a pro sdílení mezi systémy •&#9;Zefektivnění reportingu v rámci UWWTD (směrnice (EU) 2024/3019), která přináší celou řadu nových povinností, které musí ČR postupně splnit •&#9;Pokud by nebyla využitá stejná platforma znamenalo by to implementaci dalších systémů pro integraci, transformaci a správu dat a toho plynoucí navýšení nákladů na naplnění povinností vycházející ze směrnic EU •&#9;Umožnění údržby Národního prováděcího plánu, který je zpracován jako GIS aplikace na platformě ESRI •&#9;Zjednodušení integrace s PRVKÚK – tyto systémy jsou také implementovány často na platformě ESRI •&#9;Možnost integrace NPP jako živého systému, který při správně prováděné aktualizaci dat může poskytovat MZE i celému vodohospodářskému oboru zcela unikátní informace způsobem, který by měl být v 21. století standardem •&#9;Pokud nebude tento systém implementován na stejné platformě jako systémy řešící příbuznou agendu, hrozí v budoucnu jeho rychlé zastarání, nárůst neefektivity a opakování scénáře, že systém je vnímán odbornou veřejností jako nevyhovující a neodpovídající potřebám a stále se zvyšujícím standardům oboru | Zadavatel nesouhlasí s navrženým doporučením. Agendové moduly fungují cca 20 let bez napojení na GIS, a proto nelze říci, že je výkon agendy funkčně závislý na GIS. Zadavatel souhlasí, že propojení s GIS může významně zlepšit uživatelský komfort, a proto se rozhodl pro jeho využití pro vizualizaci dat. | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 8: Požadavky na agendovou komponentu Evidence technicko bezpečnostního dohledu (ETBD) |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Příloha č. 4 – Technická specifikace; modul ETBD, definice role pro veřejné uživatele. 2. popis nepřesnosti: Role přiřazovaná všem veřejným uživatelům se nazývá „Farmář“ — v kontextu agendy technickobezpečnostního dohledu nad vodními díly působí tento název jako nesouvisející s předmětem agendy. 3. dopad zjištěné nepřesnosti: Nevhodně zvolený název role může působit zavádějícím dojmem na uživatele i na Dodavatele při implementaci. 4. návrh upřesnění: Doporučujeme přejmenovat roli veřejného uživatele v modulu ETBD na název odpovídající předmětu agendy (např. „Veřejný uživatel“), při zachování stejné funkce a rozsahu oprávnění. | Bohužel označení vychází z nativního označení základního uživatelského účtu v LDAP/AD a není možné ho zmněnit pro potřeby tohoto projektu. Označené role námá praktický dopad na realizaci a její pracnost. | NE |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. Identifikace části zadání: Kapitola 8.7 „Role a jejich oprávnění" — role Stavební úřad KU a Stavební úřad ORP; podkapitola „Data v agendě ETBD" — zápis výsledků prostorového průniku systémem AgriGIS. 2. Popis nepřesnosti: Zadávací dokumentace uvádí, že přiřazení stavebního úřadu k liniovým vodním dílům bude provedeno na základě „prostorového průniku liniového prvku s geografickou vrstvou působnosti jednotlivých stavebních úřadů" a že „údaje o prostorovém průniku zapíše k datům do databáze systém AgriGIS, tudíž je mimo rámec této realizace. V rámci realizace dojde k dohodě mezi Provozovatelem AgriGIS a Poskytovatelem o nejvhodnější formě a struktuře pro zápis těchto dat." Zadávací dokumentace nezodpovídá tyto otázky: (a) Kdo a kdy iniciuje spuštění prostorového průniku v AgriGIS — Funkční celek (jako API volání), nebo provozovatel AgriGIS (manuálně)? (b) S jakou frekvencí bude prostorový průnik přepočítáván — jednorázově při zaevidování vodního díla, nebo periodicky (např. při změnách správních obvodů)? (c) Jak bude Funkční celek notifikován o výsledcích průniku a jejich aktualizacích? 3. Dopad zjištěné nepřesnosti: Bez zodpovězení těchto otázek nelze navrhnout spolehlivou architekturu rozhraní mezi Funkčním celkem a AgriGIS pro tuto funkcionalitu. Pokud je průnik spouštěn asynchronně (např. jednou denně), musí Funkční celek počítat s tím, že nově zaevidovaná vodní díla dočasně nemají přiřazen stavební úřad — a musí tuto situaci ošetřit v uživatelském rozhraní a v logice přístupu k datům. Nevyjasněnost přímo ovlivňuje implementaci logiky přístupu k datům a odhad pracnosti. 4. Návrh upřesnění: Zadavatel doplní: (a) iniciátor a způsob spuštění prostorového průniku (synchronní API / asynchronní batch / manuální), (b) očekávanou latenci (jak rychle po zaevidování VD bude přiřazení stavebního úřadu dostupné), (c) způsob notifikace Funkčního celku o výsledcích (webhook, polling, sdílená DB tabulka), (d) chování systému v přechodovém stavu bez přiřazení. | Zadavatel na základě přeložených otázek upřesňuje, že: a) spuštění nápočtu nápočet iniciuje komponenta Funkčního celku EVI, která požádá o dopočtení údajů k ukládanému prvku, b) na vyžádání, c) výsledek nápočtu bude součástí doplňovaných atributů a bude možné si jej zkontrolovat, bude evidován processing_status; processing_time a processing_error Upřesnění budou také doplněna do zadávací dokumentace. | ANO | Text byl doplněn do podkapitoly 8.3. |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání (2) 1. Identifikace části zadání: Kapitola 8.5 „Požadavky na uživatelské rozhraní" — automatické doplňování polohopisných údajů na základě souřadnic vodního díla. 2. Popis nepřesnosti: Zadávací dokumentace uvádí: „Vybrané polohopisné údaje budou do systému doplňovány automaticky na základě souřadnic vodního díla — ORP, kraj, územní působnost s.p. Povodí apod. Součástí detailu bude i mapové okno obsahující mapové podklady agendy, po kliknutí do mapy budou odečteny informace o poloze." Zadání nespecifikuje: (a) zda je poloha vodního díla ukládána jako souřadnice bodu, nebo jako geometrie (linie, polygon), (b) kdo odpovídá za správnost a aktualizaci referenčních geodat ORP/kraj/Povodí — zda jsou tato data součástí AgriGIS, nebo je musí Funkční celek udržovat samostatně. 3. Dopad zjištěné nepřesnosti: Tabulka atributů ETBD (příloha zadání) přitom prokazuje, že různé druhy vodních děl vyžadují různé typy geometrie: pro bodová díla (čerpací stanice, jezy, ČOV) jsou evidovány souřadnice jednoho bodu X/Y v S-JTSK; pro liniové stavby (ochranné hráze, přivaděče — druh „H" a „SP") jsou povinné souřadnice počátečního i koncového bodu (atributy vdxpjtsk/vdypjtsk a vdxkjtsk/vdykjtsk); a pro plošná díla (vodní nádrže, suché nádrže — druh „VN", „SN") tabulka atributů sice uvádí jen bod, ale poznámka přímo v tabulce konstatuje, že „bude prezentováno jako bod v mapě podle souřadnic, ale zároveň souřadnice nebude možné vygenerovat v žádném z výstupních formátů (politika ochrany umístění vodárenských nádrží)". Pro nádrže jsou ovšem technicky relevantní parametry jako plocha, objem a kóta, které bodová reprezentace nepodporuje dostatečně. Bez jednoznačné definice geometrického modelu pro každý druh VD nelze správně implementovat algoritmus prostorového průniku pro automatické doplnění ORP/kraj/Povodí. 4. Návrh upřesnění: Zadavatel v analytické fázi specifikuje geometrický model vodních děl dle jejich druhu: bodová díla (CS, J, ČOV) jsou lokalizována jedním bodem X/Y v S-JTSK, liniové stavby (H, SP) párem souřadnic počátečního a koncového bodu, pro plošná díla (VN, SN, O) zadavatel upřesní, zda postačuje bodový centroid/referenční bod, nebo je požadována polygonová geometrie. Zadavatel vezme na vědomí, že u liniových a plošných vodních děl bodová nebo dvou-bodová reprezentace nezaručuje úplné přiřazení administrativních jednotek (ORP, kraj, územní působnost s.p. Povodí): hráz nebo nádrž se může fyzicky rozkládat přes více ORP nebo krajů, zatímco systém přiřadí jednotku pouze podle průniku s lokalizačním bodem. Zadavatel proto upřesní, zda pro tato vodní díla postačuje přiřazení administrativní jednotky podle lokalizačního bodu (zjednodušené řešení), nebo zda je požadováno přiřazení na základě plné prostorové geometrie linie či polygonu. | Zadavatel na základě přeložených otázek upřesňuje, že: a) polohy vodních děl mají charakter bodu, u liniových staveb jsou evidovány dvě souřadnice (počátek a konec) na mapě se vykresluje prvek na základě počáteční souřadnice, b) vrstvy prostorových dat sloužící pro nápočet průniku budou součástí AgriGIS. Zadavatel doplní zadávací dokumentaci o výše uvedené vysvětlení. | ANO | Text byl doplněn do podkapitoly 8.8. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle (1) 1. Identifikace části zadání: Kapitola 8.5 „Požadavky na uživatelské rozhraní" — vizuální odlišení vodních děl podle naléhavosti prohlídky v seznamu; podkapitola „Integrace se systémem AgriGIS" — přenos vyfiltrovaných záznamů do mapové aplikace. 2. Stávající formulace: „Ze seznamu bude možné se prokliknout do mapové aplikace. Mapová aplikace bude zohledňovat vyfiltrovaná vodní díla. U seznamu vodních děl bude možné vizuálně odlišit vodní díla podle naléhavosti provedení prohlídky — například barvou záznamu, barevnou značkou atd. Přesný způsob rozlišení bude předmětem grafického návrhu Poskytovatele a podléhá schválení Objednatele." 3. Návrh nového znění: Doporučujeme doplnit: „V případě přechodu uživatele do mapové aplikace (proklik ze seznamu nebo z detailu záznamu) budou spolu s identifikátory vodních děl předány i hodnoty atributu naléhavosti prohlídky, aby bylo možné toto vizuální odlišení zachovat i v mapovém zobrazení. Technický způsob předání tohoto atributu do mapové aplikace (URL parametr / API) navrhne dodavatel v rámci implementační analýzy; návrh podléhá schválení Objednatele." 4. Potvrzení vazby na cíl a účel: Navrhovaná doplňková formulace zachovává cíl zadavatele — vizuálně odlišit naléhavost prohlídky. Rozšiřuje jej konzistentně i na mapové zobrazení, které je součástí téhož uživatelského workflow. 5. Popis zjednodušení: Uživatel (správce povodí, stavební úřad) bude moci vyhodnotit naléhavost prohlídek přímo v mapě bez přepínání kontextu. Eliminuje nutnost paralelní práce v tabulkovém seznamu a v mapě. 6. Dopad navrhované úpravy: Minimální dopad na implementaci (přidání jednoho atributu do předávaného kontextu). Pozitivní dopad na použitelnost mapové aplikace pro prioritizaci terénních prohlídek. | Zadavatel upřesňuje, že v případě přechodu do mapové aplikace budou předávány pouze identifikátory vodních děl, hodnoty naléhavosti by měl systém AgriGIS, stejně jako všechny další údaje čerpat z databáze. Návrh konkrétní podoby rozhraní bude součástí dohody s dodavatelem AgriGIS a podléhá schválení Zadavatelem. | ANO | Text doplněn do podkapitoly 8.3. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle (2) 1. Identifikace části zadání: Kapitola 8.8 „Data v agendě ETBD" — specifikace databázového schématu pro prostorová data. 2. Stávající formulace: „Předpokládáme, že Dodavatel doplní finální databázové schéma o další atributy nutné pro fungování agendové komponenty ETBD nebo pro správné fungování spolupracující mapové aplikace pro ETBD." 3. Návrh nového znění: Doporučujeme doplnit: „Dodavatel v rámci implementační analýzy navrhne způsob uložení prostorových dat vodních děl v databázi IS VaK, včetně volby souřadnicového systému, typu geometrie pro jednotlivé druhy vodních děl a způsobu synchronizace nebo propojení těchto dat s prostředím ArcGIS Enterprise (AgriGIS). Návrh musí být konzistentní s datovým modelem AgriGIS a podléhá schválení Objednatele ve spolupráci s Provozovatelem AgriGIS." 4. Potvrzení vazby na cíl a účel: Navrhovaná úprava zachovává cíl — správně fungující mapová aplikace pro ETBD. Explicitně zavazuje dodavatele k navržení konzistentního prostorového datového modelu v rámci analytické fáze, namísto ponechání tohoto architektonicky klíčového rozhodnutí zcela otevřeného. 5. Popis zjednodušení: Zabrání se situaci, kdy dodavatel navrhne prostorový datový model nekompatibilní s ArcGIS Enterprise, což by vyžadovalo přepracování v pozdní fázi projektu (vada kategorie A implementační analýzy). 6. Dopad navrhované úpravy: Bez dopadu na harmonogram. Vyžaduje, aby Objednatel zajistil součinnost Provozovatele AgriGIS při schvalování prostorového datového modelu v rámci implementační analýzy (Fáze 2). | Zadavatel se domnívá, že dotaz zřejmě vychází z představy komplikované datové strukty a různorodé palety geografických reprezentací prvků vodních děl podléhajících TBD. Vodní díla TBD jsou však evidována pouze bodově, jejich atributy budou součástí zadávací dokumentace a předpokládané kardinality jsou také naznačeny v zadávací dokumentaci. S ohledem na zde uvedená fakta Zadavatel nebude na podkladě této připomínky realizovat další doplnění nebo úpravu zadávací dokumentace. | NE |  |
|  | Kapitola 9: Požadavky na agendovou komponentu Samostatná evidence dokumentů (SED) |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Příloha č. 4 – Technická specifikace; komponenta SED, tabulky metadat dokumentů pro agendu ETBD. 2. popis nepřesnosti: Dvě různé tabulky metadat pro ETBD uvádí odlišný organizační kód útvaru – jedna „15112“, druhá „15122“ (kódy pro PPVAK/PRVAK a MPVAK/VSVaK jsou shodné v obou tabulkách). 3. dopad zjištěné nepřesnosti: Rozdílný kód pro tutéž agendu může vést k nesprávnému směrování dokumentů v SED. 4. návrh upřesnění: Doporučujeme sjednotit a jednoznačně potvrdit správný organizační kód útvaru pro agendu ETBD (15112, nebo 15122) v obou tabulkách metadat. | Zadavatel opraví chybu v textu Zadávací dokumentace. | ANO | Oprava textu dokumentu byla provedena v podkapitole 9.8. |
|  |  |  |  |  |  |
|  | Kapitola 10: Požadavky na komponentu Jmenného rejstříku |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Příloha č. 4 – Technická specifikace; komponenta Jmenný rejstřík, datový model atributu IČO. 2. popis nepřesnosti: Datový model definuje IČO nekonzistentně – u FO jako „text, max 50 znaků“, u PO jako „INTEGER, max 50 znaků“ (vnitřně rozporné, celočíselný typ se počtem znaků neomezuje). 3. dopad zjištěné nepřesnosti: Uložení IČO jako INTEGER by mohlo vést ke ztrátě úvodních nul, což by způsobilo chybnou identifikaci subjektu. 4. návrh upřesnění: Doporučujeme sjednotit datový typ atributu IČO pro fyzické i právnické osoby na textový typ, aby nedocházelo ke ztrátě úvodních nul. | Dodavatel provede sjednocení požadavků na datové typy. | ANO | Oprava textu dokumentu byla provedena v podkapitole 10.6 |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Harmonogram realizace  | NE |  |  |  |
|  |  | Zadání používá, názvy Fáze 2, Fáze 3, Fáze 4, aniž by tyto fáze byly uvedeny v harmonogramu projektu. Doporučujeme doplnit definice jednotlivých fází a jejich doplnění do harmonogramu. | Vysvětlení jednotlivých fází je součástí návrhu smlouvy v Zadávací dokumentaci k realizaci Funkčního celku. Tento text nebyl součástí PTK. | NE |  |
|  | Možnost zkrácení | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Zajištění dodržení harmonogramu | NE |  |  |  |
|  |  | Nedoporučujeme jako výběrové kritérium používat zkrácení harmonogramu. Navrhujeme tyto mechanismy: Navržení pravidelných akceptačních a platebních milníků, které dodavatele finančně průběžně motivují dodávat včas průběžné výstupy. Pravidelný, formalizovaný status reporting s explicitním trackováním odchylky od harmonogramu (nikoli jen ad hoc informování) Řízení rizik s pravidelnou aktualizací rizikového registru a jasnou eskalační cestou při identifikaci hrozícího zpoždění. Průběžné/inkrementální akceptace dílčích výstupů (nikoli jen finální akceptace celku), aby se rizika zpoždění a nekvality odhalila co nejdříve. Řídicí výbor se zástupci Objednatele i Dodavatele, s pravidelnou frekvencí (např. měsíční) a jasně definovanou eskalační pravomocí. Úprava počtu vad kategorie B, které podmiňují úspěšné ukončení Milníku či Fáze na nenulový.  | Zadavatel děkuje za přípomínku, v tomto případě však ponechá text zadávací dokumentace v původním smyslu. | NE |  |
|  |  |  |  |  |  |
|  | Seznam významných služeb |  |  |  |  |
|  | Obecné požadavky na seznam služeb  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Předmět plnění referenční služby | NE |  |  |  |
|  |  | Vzhledem k zaměření VZ považujeme předmět referenční služby za příliš obecně definovaný. Pokud chce zadavatel garantovat zkušenost dodavatele s dodávkami obdobného typu IS (sw řešení), doporučujeme doplnit definici referenční služby o IS v oblasti vodohospodářství. Zároveň doporučujeme zvážit přidání požadavku na referenci v oblasti systémů implementující procesní řízení.  | Vzhledem k úzkému a vysoce specializovanému charakteru tohoto odvětví by stanovení takového požadavku mohlo vést k neúměrnému omezení hospodářské soutěže a potenciálně diskriminačnímu nastavení kvalifikačních podmínek. Zadavatel proto požaduje reference na informační systémy obdobného rozsahu a složitosti bez omezení na konkrétní odvětví. | NE |  |
|  |  |  |  |  |  |
|  | Požadavek na ISVS | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Služba na dodávku aplikace / IS | NE |  |  |  |
|  |  | Vzhledem k předpokládané hodnotě VZ považujeme minimální hodnotu referenční zakázky za nepřiměřeně nízkou a navrhujeme zvýšit na 10 mil. Kč | Zadavatel se rozhodl neuplatnit striktnější kritéria, aby nedošlo k neúměrnému omezení hospodářské soutěže a potenciálně diskriminačnímu nastavení kvalifikačních podmínek. | NE |  |
|  |  |  |  |  |  |
|  | Služba na provoz aplikace / IS | NE |  |  |  |
|  |  | Garantovaná provozní doba je uvedena z našich zkušeností a námi dodávaných servisních služeb v nestandardní hodnotě. Většinou se jedná o 5x8 (resp. ve výjimečných případech 5x9), nebo o 7x24. Doporučujeme vyžadovat referenci na službu, která odpovídá obvyklým parametrům, aby nedošlo ke znevýhodnění uchazečů a napadnutelnosti výběrového řízení (tedy 5x8 nebo 7x24) | Požadovaná garantovaná provozní doba v rámci referenční zakázky je stanovena jako minimálně 5x10. Tento požadavek vychází z provozních potřeb a parametrů budoucího funkčního celku. Zadavatel se nedomnívá, že by požadavek byl diskriminační nebo bezdůvodně omezoval hospodářskou soutěž, neboť uchazeči mohou prokázat splnění kvalifikace i referenční zakázkou s přísnějšími parametry poskytovaných služeb (např. 7x24). | NE |  |
|  |  |  |  |  |  |
|  | Seznam členů realizačního týmu a jejich kvalifikace |  |  |  |  |
|  | (1) Obecné požadavky na realizační tým | NE |  |  |  |
|  |  | Odborné znalosti a složení týmu reflektuje pouze IT část dodávky a zcela pomíjí, že pro zajištění kvality řešení je potřeba aby dodavatel disponoval i odborným know-how. Z našeho pohledu je potřeba doplnit tým o odborníky minimálně v těchto rolích: 1. osoba, která za vlastníka nebo provozovatele VHI zpracovává vedení majetkové a provozní evidence vodovodů a kanalizací v rozsahu dle § 5 zák. č. 274/2001 Sb. Tato osoba by měla být ideálně ze společnosti, která vlastní nebo provozuje velký rozsah vodohospodářského majetku, který garantuje širokou škálu řešených druhů a typů VHI, které by navrhované technické řešení mělo pokrýt. 2. osoba která za vlastníka a provozovatele VHI zpracovává plán financování obnovy vodovodů a kanalizací dle části 5., § 13 vyhl. 428/2001 Sb., kterou se provádí zákon č. 274/2001 Sb. o vodovodech a kanalizacích. Jako v bodě 1) platí, že daná osoba by měla být ideálně ze společnosti, která vlastní nebo provozuje velký rozsah vodohospodářského majetku, který garantuje širokou škálu řešených druhů a typů VHI, které by navrhované technické řešení mělo pokrýt. 3. právník s dokonalou znalostí vodního práva, který zná všechny povinnosti vlastníka a provozovatele VHI v souvislostech. Garantuje, že se při návrhu technického řešení nic neopomene. 4. specialista konzultant ESRI s pětiletou zkušeností na projektech vývoje Geografických informačních systému s certifikací ESRI na úrovni Associate. Garantuje, že návrh řešení využije efektivně existující řešení MZE na platformě ESRI zejména integraci a AgriGIS a NPP. | Zadavatel neomezuje počet osob v jednotlivých rolích. Uchazeči tak mohou do role analytiků nominovat odborníky disponující znalostmi z oboru VaK a vodního zákona. Tyto oblasti budou také testovány v rámci testu pro roli analytika. | NE |  |
|  | (2) Minimálně jedna (1) osoba v kategorii role Solution Architekt splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (3)Minimálně jedna (1) osoba v kategorii role Aplikační architekt splňující následující požadavky:  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (4) Minimálně jedna (1) osoba v kategorii role Projektový manažer splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (5) Minimálně dvě (2) osoby v kategorii role Analytik IT senior splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (6) Minimálně pět (5) osob v kategorii role Vývojář splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (7) Minimálně jedna (1) osoba v kategorii role Tester splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (8) Minimálně jedna (1) osoba v kategorii role Bezpečnostní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (9) Minimálně jedna (1) osoba v kategorii role Manažer provozu splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (10) Minimálně dvě (2) osoby v kategorii role Provozní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (11) Minimálně jedna (1) osoba v kategorii role Specialista uživatelské podpory splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (12) Minimálně jedna (1) osoba v kategorii role SCRUM master splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Celková nabídková cena: 30 % | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Návrh vybraných částí řešení: 30 % | ANO, s doporučením |  |  |  |
|  |  | Doporučujeme jako některou z úloh, které mají být zpracovány, realizovat také úlohy a) demonstrující konzistenci datového modelu, topologie a zobrazení nad mapou b) demonstrující využítí ArcGIS Online | Zadavatel děkuje za námět nicméně v tomto případě ponechá parametry bez změny. Požadované demonstrace konzistence datového modelu, topologie a mapového zobrazení, stejně jako demonstrace využití ArcGIS Online, nespadají do předmětu plnění funkčního celku EVI. GIS kompetence, správa prostorových dat, datového modelu, topologických pravidel a konfigurace mapových aplikací jsou v cílové architektuře řešení svěřeny systému AgriGIS a jeho provozovateli. | NE |  |
|  | Prokázání odborných znalostí: 30 % | NE |  |  |  |
|  |  | Doporučujeme rozšířit. Odborné znalosti a složení týmu reflektuje pouze IT část dodávky a zcela pomíjí, že pro zajištění kvality řešení je potřeba aby dodavatel disponoval i odborným know-how. Z našeho pohledu je potřeba doplnit tým o odborníky minimálně v těchto rolích: 1. osoba, která za vlastníka nebo provozovatele VHI zpracovává vedení majetkové a provozní evidence vodovodů a kanalizací v rozsahu dle § 5 zák. č. 274/2001 Sb. Tato osoba by měla být ideálně ze společnosti, která vlastní nebo provozuje velký rozsah vodohospodářského majetku, který garantuje širokou škálu řešených druhů a typů VHI, které by navrhované technické řešení mělo pokrýt. 2. osoba která za vlastníka a provozovatele VHI zpracovává plán financování obnovy vodovodů a kanalizací dle části 5., § 13 vyhl. 428/2001 Sb., kterou se provádí zákon č. 274/2001 Sb. o vodovodech a kanalizacích. Jako v bodě 1) platí, že daná osoba by měla být ideálně ze společnosti, která vlastní nebo provozuje velký rozsah vodohospodářského majetku, který garantuje širokou škálu řešených druhů a typů VHI, které by navrhované technické řešení mělo pokrýt. 3. právník s dokonalou znalostí vodního práva, který zná všechny povinnosti vlastníka a provozovatele VHI v souvislostech. Garantuje, že se při návrhu technického řešení nic neopomene. | Zadavatel neomezuje počet osob v jednotlivých rolích. Uchazeči tak mohou do role analytiků nominovat odborníky disponující znalostmi z oboru VaK a vodního zákona. | NE |  |
|  | Urychlení vývoje a dodání vybraných modulů: 10 % | NE |  |  |  |
|  |  | Kritérium považujeme za nevhodné. Ze zkušenosti z podobných tendrů dochází ke splnění takového požadavku u všech uchazečů. Není pak naplněn cíl takového kritéria, tj. vybrat takového dodavatele, který má dostatek zdrojů realizaci dodávky. Doporučujeme spíše navýšit váhu kritéria 3 – prokázání odborných znalostí, které lépe prokazuje schopnost uchazeče dodat zakázku v plánovaném harmonogramu. | Zadavatel ponechá možnost nabídnout zkrácení doby realizace a související hodnoticí kritérium. Cílem Zadavatele je umožnit dodavatelům uplatnit jejich zkušenosti, kapacity, know-how a případné vlastní metodické či technologické postupy, které mohou vést k efektivnějšímu průběhu vývoje a rychlejšímu dodání řešení. Rozsah garantované součinnosti poskytované Zadavatelem je popsán v zadávací dokumentaci a Uchazeči by při stanovení nabízených termínů měli vycházet z těchto podmínek. Termín realizace nabídnutý Uchazečem v rámci tohoto hodnoticího kritéria bude pro vybraného dodavatele závazný. Zadavatel si je současně vědom skutečnosti, že v průběhu realizace mohou nastat okolnosti, které dodavatel nemůže objektivně ovlivnit, včetně případných prodlení způsobených na straně Zadavatele. Z tohoto důvodu smlouva obsahuje ustanovení, na jehož základě může dodavatel v odůvodněných případech požádat o prodloužení termínu plnění. Takový požadavek bude posouzen a případně schválen Zadavatelem v souladu se smluvními podmínkami. | NE |  |
|  |  |  |  |  |  |
|  | Předpokládaná hodnota zakázky | NE |  |  |  |
|  |  | Vzhledem k rozsahu díla považujeme předpokládanou cenu za podhodnocenou. Rozsah poptávaného díla byl oproti minulé zakázce rozšířen o moduly SED, Jmenný rejstřík a ETBD a toto rozšíření scopu není v předpokládané ceně nijak reflektováno. Celkovou hodnotu zakázky předpokládáme ve výši 75–110 mil Kč bez DPH  | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. Limit pro výši nabídkové ceny byl na základě PTK zrušen, nabídková cena tedy může přesáhnout předpokládanou hodnotu VZ. | ANO | Úprava podmínek uvedených v zadávací dokumentaci. |
|  | Limity pro nabídkovou cenu | NE |  |  |  |
|  |  | Předpokládaná cena za Služby s fixním plněním a Služby s výkonovým plněním v rozsahu 2760 MD uvedená zadavatelem je 16 225 000 Kč, což je z našeho pohledu jednoznačně podhodnocené. Je třeba vzít v úvahu že pouze dodávka 2760 MDs představuje cenu okolo 30 mil Kč, pokud budeme vycházet z průměrné MD sazby na českém IT trhu | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. Limit pro výši nabídkové ceny byl na základě PTK zrušen, nabídková cena tedy může přesáhnout předpokládanou hodnotu VZ. | ANO | Úprava podmínek uvedených v zadávací dokumentaci. |
|  | Platební podmínky | NE |  |  |  |
|  |  | Vzhledem k rozsahu díla a době trvání dodávky (analytická a implementační část) považujeme za vhodné rozdělit platbu za vývoj a dodání funkčního celku 1) na dílčí platební milníky vázané na dodávku jednotlivých částí díla (modulů) 2) doplnit platební milník po zahájení projektu (podpisu smlouvy) Za Konkrétně tedy celkem 6 platebních milníků: 1.&#9;po podepsání smlouvy 2.&#9;po akceptaci implementační analýzy 3.&#9;po akceptaci Milník 1 4.&#9;po akceptaci Milník 2 5.&#9;po akceptaci Milník 3 6.&#9;po akceptaci funkčního celku Důvodem pro takovou změnu je to, že dílčími platebními milníky se snižuje celková cena, protože dodavatel není nucen nést veškeré náklady na financování výroby po celou dobu realizace. | Připomínka není akceptována. Zadavatel na základě interního posouzení rozhodl ponechat způsob úhrady plnění v původním znění. | NE |  |
|  | Bankovní záruka | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Lhůta pro podání nabídek | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  |  | Nejsou |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
| Název obchodní společnosti: Dodavatel č. 3 |  |  |  |  |  |
|  |  | Komentář Dodavatele č. 3 | Vysvětlení/Reakce | Zapracováno |  |
|  | Otázky k předmětu plnění |  |  |  |  |
|  | Kapitola 1: Stávající stav ICT zajištění agendy VaK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: 1.1. Stávající datové zdroje (k 1.2.): „Struktura jednotlivých databází vychází z příloh vyhlášky č. 428/2001 Sb., kterou se provádí zákon č. 274/2001 Sb., o vodovodech a kanalizacích pro veřejnou potřebu a o změně některých zákonů.“ 2. popis nepřesnosti: 2.1. „Struktury jednotlivých databází“ jsou v platné legislativě popsané s různou mírou podrobnosti a vzájemné konzistence (jak po věcné, tak formální stránce) 3. dopad zjištěné nepřesnosti: 3.1. Pokud zadávací dokumentace vychází při návrhu datových struktur z platné legislativy, pak její vzájemná nekonzistence komplikuje návrh jednotného datového modelu, zvyšuje složitost implementace a vytváří prostor pro rozdílnou interpretaci požadavků jednotlivými uchazeči. 4. návrh upřesnění: 4.1. Doporučujeme, aby zadávací dokumentace v případech, kdy legislativa připouští více možných výkladů nebo obsahuje vzájemně nekonzistentní datové definice, jednoznačně stanovila referenční datový model a jeho interpretaci pro účely návrhu informačního systému. (Poznámka: Z dlouhodobé praktické zkušenosti považujeme za systémově nejvhodnější řešení sjednocení datových definic v legislativě (věcně i formálně). Uvědomujeme si však, že taková změna přesahuje rámec této veřejné zakázky i kompetence adresáta PTK.) | Součástí plnění dodavatele je návrh a implementace takového datového modelu, který bude vycházet z požadavků platné legislativy a současně bude odpovídat požadovaným funkcionalitám systému. Zadavatel nepovažuje za účelné stanovovat úplný referenční datový model, neboť jeho finální podoba může být definována až na základě implementační analýzy provedené Dodavatelem. | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 2: Požadavky na nový systém |  |  |  |  |
|  |  | 1.1 Základní architektura systému (kap 2.2) 2.1 Pro Testovací a Pre-produkční instanci je jasně specifikováno, že je zajišťuje Objednatel. Z textu zadávací dokumentace není zcela jednoznačné, zda způsob zajištění Produkčního prostředí odpovídá stejnému modelu jako u prostředí Testovacího a Pre-produkčního, nebo zda se předpokládá odlišné rozdělení odpovědností. Odstavec, který se týká vývojového prostředí je možné vnímat, jako součást bloku uvedeného „Pro všechna prostředí platí“. 3.1 Povede minimálně k doplňujícím dotazům a může vést k rozdílnému vymezení rozsahu plnění jednotlivými uchazeči, a tím i k obtížně porovnatelným nabídkám. 4.1 Sourodým způsobem popsat všechna prostředí vč. Vývojového. | Objednatel v rámci Specifikace předmětu veřejné zakázky explicitně doplnít, že zajištění Produkčního prostředí je shodný s Testovacím a preprodukčním. Současně Objednatel upozorňuje, že vývojové prostředí není součástí požadovaného plnění a Specifikace předmětu veřejné zakázky. Zajištění vývojového prostředí je plně v odpovědnosti dodavatele. | ANO | V podkapitole 2.2 došlo k doplnění informace o zajištění provozu infrastruktury provozního prostředí v souladu s prostředím testovacím a preprodukčním. |
|  |  | 1.2 Integrace systému (kap. 2.4.) 2.2 Není jednoznačně vymezen rozsah integračních služeb poskytovaných platformou AgriBus a služeb, které jsou součástí dodávky uchazeče. Ze zadání není zřejmé zejména to, zda je součástí plnění také návrh a implementace nových integračních služeb, jejich publikace, transformace zpráv, orchestrace nebo konfigurace integrační platformy. 3.2 Může vést k nepřesnému nacenění nabídky a následným jednáním o vícepráce. 4.2 Přesněji specifikovat kdo řeší služby AgriBus vč. Nových, které mohou být potřeba pro dodávané řešení. | Vzhledem k obecné povaze dotazu není možné jednoznačně vymezit odpovědnost za všechny potenciální integrační scénáře. Zadavatel obecně předpokládá, že tam, kde již integrační rozhraní existují a jejich existence není zpětně ovlivněna systémem IS VaK, budou primárně využita tato existující rozhraní. V případech, kdy bude nezbytné vytvořit nové integrační služby nebo služby budou vznikem IS VaK, bude jejich návrh a specifikace řešena v součinnosti s dodavatelem integrovaného systému a dalšími dotčenými stranami (to se týká zejména systémů SEPO a AgriGIS a všech služeb v rámci propojení komponent funkčního celku). Implementace a provoz integrační platformy AgriBus nejsou součástí plnění dodavatele IS VaK a je v gesci Zadavatele. Dodavatel IS VaK je odpovědný za poskytnutí specifikace požadovaných služeb a rozhraní, přičemž konfiguraci a nastavení integrační platformy AgriBus zajistí Zadavatel. Dodavatel poskytuje nezbytnou součinnost ke které je vyzván a poskytuje nezbytnou součinnost při realizaci takového rozhraní. | NE |  |
|  |  | 1.3 Implementační analýza (kap. 2.11) 2.3 Implementační analýza může podstatným způsobem doplnit zadání, nejsou jasně specifikovaná kritéria jejího hodnocení, řešení, které dodavatel nabídne a následně podpoří v implementační analýze může Poskytovatel odmítnout a trvat na jiném, finančně náročnějším. 3.3 Zadávací dokumentace nevymezuje postup pro případ, kdy objednatel v rámci implementační analýzy neakceptuje navržené řešení a požaduje jeho přepracování nebo nahrazení jiným řešením. Není zřejmé, jak bude v takovém případě posuzováno, zda se stále jedná o upřesnění zadání, nebo již o změnu rozsahu plnění. 4.3 Jednoznačně vymezit rozsah implementační analýzy a stanovit kritéria, podle kterých bude posuzováno, zda navržené úpravy představují pouze zpřesnění zadání, nebo již změnu rozsahu plnění. Současně doporučujeme popsat proces schvalování výstupů implementační analýzy, vč. lhůt pro jejich posouzení a postupu při neshodě mezi objednatelem a dodavatelem. | Zadavatel s připomínkou nesouhlasí. Implementační analýza slouží k upřesnění způsobu realizace požadavků zadavatele a návrhu technického řešení v mezích zadávací dokumentace. Nejedná se o nástroj pro změnu rozsahu plnění veřejné zakázky. | NE |  |
|  |  | Doporučení: Přesné vymezení hranic odpovědnosti mezi agendovou komponentou a sdílenými službami Technická specifikace popisuje integrační vazby mezi agendovou komponentou a sdílenými službami (AgriBus, SED, Jmenný rejstřík, AgriGIS). Není však ve všech případech jednoznačně vymezen rozsah funkcionality, která je součástí dodávky agendové komponenty, a funkcionality zajišťované sdílenými platformami nebo jejich provozovateli. Zejména není vždy zřejmé: • kdo odpovídá za návrh a implementaci nových integračních služeb, • kdo zajišťuje transformace dat a orchestrace integračních toků, • kdo publikuje a spravuje integrační rozhraní, • kdo odpovídá za konfiguraci integrační platformy, • které části řešení jsou součástí plnění této veřejné zakázky a které budou dodány nebo provozovány jiným subjektem. Doporučujeme jednoznačně vymezit hranice odpovědnosti jednotlivých systémů, sdílených platforem a dodavatelů, aby všichni uchazeči oceňovali stejný rozsah plnění. | Připomínka obsahuje několik samostatných otázek: Kdo odpovídá za návrh a implementaci nových integračních služeb? V tomto bodě záleží na tom, zda je služba již v provozu a IS VaK je pouze konzumentem (např. základní registry) nebo zda je služba vývíjena a upravována v kontextu IS VAK (například vešklerá komunikace se SEPO, komunikace mezi komponentami Funkčního celku). Ve druhém případě Dodavatel IS VaK ve splupráci s dodavatelem druhého systému připraví návrh rozhraní. V případě potřeby nových integračních služeb budou jejich specifikace připraveny v součinnosti se správci a dodavateli integrovaných systémů. Pro zajištění porovnatelnosti Zadavatel do ZD uvede infomraci o nacenění v takovém smyslu, že Uchazeč v rámci zadávacího řízení by měl v nabídce počítat s takovou pracností, jako by integrační rozhraní v takovém případě navhroval sám. Kdo zajišťuje transformace dat a orchestraci integračních toků? Pokud je v rámci komunikace potřeba orchestrace, zajišťuje ji platforma AgriBus. Transformace dat je možné zajistit na urovni AgriBus nebo v systému. V současném zadání nepředpokládáme transformaci dat na AgriBus. Specifické požadavky na transformaci příchozích zpráv v SED jsou uvedeny v popisu dané komponenty. Kdo publikuje a spravuje integrační rozhraní? Pokud je potřeba vystavit novou službu, je jejich specifikace předána provozovateli AgriBus. Kdo odpovídá za konfiguraci integrační platformy? Konfigurace a provoz integrační platformy AgriBus nejsou součástí plnění dodavatele IS VaK a jsou zajišťovány provozovatelem platformy AgriBus. Které části řešení jsou součástí plnění této veřejné zakázky a které budou dodány nebo provozovány jiným subjektem? Součástí plnění této veřejné zakázky je návrh a implementace funkčních celků IS VaK včetně jejich rozhraní vůči okolním systémům. Součástí plnění nejsou sdílené resortní platformy a systémy (zejména AgriBus, AgriGIS, SED a Jmenný rejstřík), které jsou dodávány a provozovány samostatně. Konkrétní podoba integračních vazeb bude upřesněna v rámci implementační analýzy. Zadavatel na podkladě této připomínky doplní text zadávací dokumentace o informace uvedené v odpovědích na předložené otázky. | ANO | Text byl doplněn na konec kapitoly 2.4. |
|  |  |  |  |  |  |
|  | Kapitola 3: Základní požadavky na funkční celek |  |  |  |  |
|  |  | 1.1 Chyby v datech a práce s nimi (kap. 3.5) 2.1.1. Není jednoznačně specifikován význam pojmů: • konfigurační přehled chyb • aktivní • deaktivovaná chyba 2.1.2. Není zřejmý vztah mezi evidovanými chybami a validačními pravidly ani jejich životní cyklus. Ze zadání není jednoznačné zejména: jak chyba vzniká, kdo a za jakých podmínek ji může deaktivovat nebo znovu aktivovat, zda se deaktivuje konkrétní výskyt chyby nebo typ chyby, jaký je vztah mezi odstraněním chyby a opětovným vyhodnocením validačních pravidel. 3.1. Nejednoznačná specifikace práce s chybami může vést k rozdílnému návrhu mechanismu validací, evidence chyb a jejich životního cyklu jednotlivými uchazeči. Výsledkem mohou být funkčně odlišná řešení i rozdílné ocenění nabídek. 4.1. Doporučujeme jednoznačně definovat význam pojmů "aktivní chyba", "deaktivovaná chyba" a "konfigurační přehled chyb", jejich vztah k validačním pravidlům a popsat celý životní cyklus chyby vč. podmínek jejího vzniku, deaktivace a opětovné aktivace. | Zadavatel nesouhlasí s tím, že by nebylo zřejmé, co je aktivní a neaktivní chyba, nicméně Zadávací dokumentace bude doplněna tak, aby lépe vysvětlila životní cyklus chyby. Chyba vzniká po provedení validace, může tedy být již součástí příchozích dat. Část formuláře obsahujícího chyby se označuje Protokol chyb. Dále může vzniknout, resp. být odhalena a zaznamenána, po kliknutí na tlačítko "Kontrola" v komponentě Funkčního celku. V takovém případě je zařazena do protokolu chyb. Pokud dojde ke změně vstupních polí pro výpočet chyby a chyba se již nevyskytuje, pak chyba z protokolu chyb mizí. Konfigurační přehled chyb v rozhraní systémového administrátora bude mít formu seznamu chyb vyhodnocovaných v dané agendové komponentě. Parametry chyb, které může administrátor měnit jsou v zadávací dokumentaci uvedeny v části: "Konfigurace chyb". | ANO | Do textu podkapitoly 3.5 byl doplněn nový bod "Životní cyklus chyby". K popisu činností a funkcí dostupných systémovému administrátorovi (podkapitola 3.10) byl doplněn text, týkající se konfigurace chyb. |
|  |  | 1.2. Export dat (kap 3.6) 2.2. Nejsou jednoznačně definovány požadavky: „Asynchronní generování rozsáhlého exportu“. Není jasné, co znamená časový údaj „v jednom čase“ v popisu „Každý uživatel může v jednom čase zadat právě jednu asynchronní operaci tohoto typu.“ 3.2. Nejednoznačné vymezení omezení asynchronních exportů může vést k rozdílné implementaci mechanismu plánování, souběžného zpracování a řízení dlouhotrvajících exportních operací. 4.2. Doporučujeme jednoznačně vymezit význam pojmu "v jednom čase", rozsah tohoto omezení a chování systému při dlouhotrvajících nebo neúspěšně dokončených asynchronních exportech. Zejména není jasné, co je míněno pojmem "v jednom čase". Zda se omezení vztahuje na celý systém, jednotlivé komponenty nebo pouze konkrétní typ exportu, kdy je asynchronní operace považována za ukončenou, jak se systém zachová v případě dlouhotrvajících nebo neúspěšně dokončených exportů. | Pojmem „v jednom čase“ zadavatel rozumí, že jeden uživatel může mít současně spuštěnu pouze jednu asynchronní exportní operaci daného typu. Do doby dokončení, zrušení nebo ukončení této operace chybovým stavem není umožněno založení další exportní operace stejného typu týmž uživatelem. Zadavatel v tomto smyslu upraví znění zadání. | ANO | Text doplněn do podkapitoly 3.6, konkrétně k požadavku na "Asynchronní generování rozsáhlého exportu".  |
|  |  | 1.3. Osobní a interní poznámky (kap. 3.8.) 2.3. Požadavek na možnost vložit do systému nestrukturované informace, bez kterých není možná interpretace, popř. další zpracování dat, není v zadání specifikován jednoznačně s ohledem na to: • zda jsou poznámky součástí auditní stopy, • zda podléhají verzování • zda jsou součástí exportů a importů • zda jsou přenášeny prostřednictvím integračních rozhraní • zda a jak ovlivňují další automatizované zpracování dat 3.3. Nedostatečná specifikace práce s interními a osobními poznámkami může vést k rozdílnému způsobu jejich implementace zejména ve vztahu k auditní stopě, verzování, exportům, integracím a automatizovanému zpracování dat. 4.3. Doporučujeme jednoznačně specifikovat životní cyklus interních a osobních poznámek, jejich vztah k auditní stopě, verzování, exportům, integračním rozhraním a jejich vliv na další automatizované zpracování dat. | Zadavetel upřesňuje: • zda jsou poznámky součástí auditní stopy Ano poznámky jsou součástí auditní stopy. • zda podléhají verzování Není přesně uvedeno o jaké verzování se má jednat. Osobní poznámka se dle požadavku přepisuje a je pouze součástí auditního logu, který je uživateli přístupný. • zda jsou součástí exportů a importů Mohou být součástí exportů. • zda jsou přenášeny prostřednictvím integračních rozhraní Poznámky nejsou součástí integračních rozhraní. • zda a jak ovlivňují další automatizované zpracování dat Poznámky neovlivňují zpracování dat. Zadavatel požadované upřesnění doplní do zadávací dokumentace. | ANO | Text doplněn do podkapitoly 3.8.  |
|  |  |  |  |  |  |
|  | Kapitola 4: Požadavky na agendovou komponentu – modul MP VAK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1.1. Nadpis kapitoly 4. POŽADAVKY NA AGENDOVOU KOMPONENTU – MODUL MP VAK (a identicky v případě dalších modulů komponenty VAK) 2.1. Jde o komponentu VAK, z nadpisu to vypadlo 3.1. Může vést k nesystematickému chápání termínů Komponenta / Modul 4.1. Změnit nadpis na „…4. POŽADAVKY NA AGENDOVOU KOMPONENTU VAK – MODUL MP VAK | Zadavatel upraví zadavací dokumentaci v navrženém smyslu. | ANO | Nadpisy byly opraveny, aby lépe rozlišily agendovou komponentu VAK. |
|  |  | 1.2. Editace přijatých dat – geografická příslušnost (str. 47) 2.2. Není jasné, co znamená „geografická příslušnost“. 3.2. Upřesnění umožní ošetřit dotčené komponenty tak, aby mohly s „geografickou příslušností“ pracovat. 4.2. Vysvětlit, co „geografická příslušnost“ znamená a k jakým entitám se vztahuje. | Geografická příslušnost se týká potenciálně všech úřadů veřejné správy a s.p. Povodí a její rozsah vychází z platných právních předpisů. V rámci systému je specifikována v atributech prvku. | ANO | Pojem byl doplněn do přehledu "Použité termíny a zkratky". |
|  |  | 1.3. Výsledky kontroly (str. 48) 2.3. Zde se píše o „Deaktivaci kontrol“, ale odkazováno je do tabulky „Chyby v datech a práce s nimi“, kde se hovoří o „deaktivaci chyb“ 3.3. Uvedený rozpor zvyšuje nejistotu v tom, zda se nastavují parametry kontrol nebo chyb a zda se deaktivují některé kontroly (pak některé údaje nebudou vyhodnoceny jako chyby), popř. lze chybným údajům „nastavit pardon“ a označit ho za validní („deaktivací chyby“) 4.3. Striktně definovat, zda se mají nastavovat parametry kontrol nebo deaktivovat detekované chyby v záznamech. | Zadavatel provede korekci zadavací dokumentaci tak, aby došlo k odstranění rozporu. | ANO | Text na straně 57 byl upraven, aby nezmiňoval deaktivaci kontrol. |
|  |  | 1.4. Kapitola 4.2. Požadavky na zpracování dat a práci se záznamy 2.4. Není jednoznačně definován pojem „sada navázaných vlastníků“ ani způsob, jakým systém vyhodnocuje existenci více záznamů o majetku s rozdílnou sadou navázaných vlastníků. 3.4. Není zřejmé, podle jakých pravidel má být existence „sady navázaných vlastníků“ vyhodnocována ani jaká je její vazba na evidované záznamy o majetku. To může vést k rozdílné implementaci této funkcionality jednotlivými uchazeči. 4.4. Definovat pojem „skupina navázaných vlastníků“ a způsob vazby této entity na záznamy o majetku | Skupina navázaných vlastníků je soubor vlastníků uvedených na daném hlášení. Tento soubor se může v jednotlivých letech lišit vlivem změn vlastnické struktury. Zadavatel nesouhlasí s tvrzením, že není zřejmé, jak bude vyhodnocována situace, kdy existuje více záznamů s rozdílnou sadou vlastníků. V zadávací dokumentaci je uvedeno, že se pracuje s nejnovější sadou. V případě pohledu do detailu majetku by měl mít uživatel možnost zobrazit všechny evidované vlastníky. Zadávací dokumentace uvádí: „Součástí tohoto rozhraní bude možnost podívat se na historické verze údajů evidovaných k majetku.“ Toto ustanovení se vztahuje i na údaje o vlastnících. | NE |  |
|  |  | 1.5. IČME ID (str. 52) 2.5. Zadávací dokumentace sama identifikuje potřebu zavést nový identifikátor (IČME ID) pro případy, kdy vlastníkem infrastruktury je fyzická osoba. Domníváme se, že stejná analýza by měla být provedena i pro konstrukci identifikátoru IČME jako celku, protože některé jeho části (zejména identifikace vlastníka a vazba na katastrální území) mohou obdobným způsobem komplikovat dlouhodobou stabilitu datového modelu. 3.5. Jedním z principů konstrukce IČME je zakódování identity vlastníka infrastruktury. To znamená, že při změně vlastníka dochází ke změně identifikátoru infrastruktury, přestože samotná infrastruktura zůstává beze změny. IČME se objevuje jako vazebný klíč mezi daty IS VAK a DTM. Pokud zadávací dokumentace navrhuje změnu konstrukce identifikátoru pro případy, kdy vlastníkem infrastruktury je fyzická osoba, považujeme za vhodné posoudit konstrukci identifikátoru IČME jako celku, vč. případů právnických osob. Další část identifikátoru IČME vychází z katastrálního území, zatímco jiné části zadání (např. PR VAK) pracují primárně s částmi obcí. Tyto územní jednotky nejsou vzájemně ekvivalentní ani hierarchicky skladebné, což může komplikovat jejich společné využití při agregacích, vyhodnocování a integračních vazbách. 4.5. Doporučujeme v rámci implementační analýzy prověřit, zda stávající konstrukce identifikátoru IČME dlouhodobě vyhovuje požadavkům nového systému, zejména z hlediska stability identifikace infrastruktury, integračních vazeb mezi IS VAK, DTM a dalšími systémy a požadovaných územních agregací. Z dlouhodobé zkušenosti upozorňujeme, že tato konstrukce může představovat riziko pro dlouhodobou stabilitu datového modelu. Domníváme se, že případná revize konstrukce identifikátoru IČME by měla být provedena na samém počátku implementační analýzy, protože následně ovlivňuje datový model, integrační vazby i migraci dat napříč celým řešením. V případě, že analýza prokáže omezení stávající konstrukce, doporučujeme zvážit návrh nového interního identifikátoru infrastruktury při zachování zpětné kompatibility s IČME. | Zadavatel nepředpokládá změny ve způsobu generování IČME. IČME ID slouží čístě k tomu, aby došlo k odstranění informací o fyzické osobě z IČME. | NE |  |
|  | Kapitola 5: Požadavky na agendovou komponentu – modul VS VAK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1. identifikace části zadání: 1.1. str. 68 odst. 2 odrážka „lokalita“ 2. popis nepřesnosti: 2.1. Zadávací dokumentace používá pojem „lokalita“, aniž by jej jednoznačně definovala. Není zřejmé, zda se jedná o samostatnou evidovanou entitu, geograficky vymezené území, lokalitu definovanou prostřednictvím GIS nebo pouze o textový údaj. Současně nejsou popsány případné vazby této entity na prostorová data ani způsob její identifikace. 3. dopad zjištěné nepřesnosti: 3.1. Nejednoznačné vymezení pojmu „lokalita“ může vést k rozdílné interpretaci této entity jednotlivými uchazeči, zejména ve vztahu k datovému modelu a případným vazbám na GIS. 4. návrh upřesnění: 4.1. Doporučujeme jednoznačně definovat pojem „lokalita“, jeho význam v datovém modelu systému, způsob jeho identifikace a případné vazby na geografická data nebo jiné evidované entity. | Pojem lokalita vychází z metodických pokynů Ministerstva financí k dané agendě, viz https://mf.gov.cz/cs/kontrola-a-regulace/cenova-regulace-a-kontrola/cenova-regulace-v-oboru-vak | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 6: Požadavky na agendovou komponentu – modul PP VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 7: Požadavky na agendovou komponentu – modul PR VAK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1.1. Kapitola 7. – úvodní odstavec. 2.1. Odkaz na legislativu, která nekonzistentně definuje datový model a vazby různých systémů (IS VAK / DTM), více viz. Obecná připomínka č. 1. 3.1. Nejednoznačné vymezení referenčních územních jednotek může vést k rozdílnému návrhu datového modelu jednotlivými uchazeči. 4.1. Jednoznačně určit referenční územní jednotku pro modul PR VAK a její vztah k ostatním komponentám systému. (Podle našich zkušeností by mohlo být vhodnější sledovat údaje majetkové a provozní evidence na části obcí ne na katastr, protože další údaje z ČSÚ jsou dostupné pouze na části obcí). | Zadavatel upřesňuje, že nejmenší referenční jednotkou je část obce nebo městská část. | NE |  |
|  |  | 1.2. Kapitola 7.2. Nápočty dat pomocí AgriGIS 2.2. Není jednoznačně popsán způsob provádění prostorových „nápočtů“ prostřednictvím AgriGIS ani rozsah funkcionality poskytované touto službou. Současně není zřejmé, jak budou řešeny přepočty údajů evidovaných na různých územních jednotkách (katastrální území × části obcí). 3.2. Rozdílné interpretace způsobu prostorových nápočtů mohou vést k odlišným implementacím integračních vazeb na AgriGIS. strana 11 z 31 4.2. Doplnit chybějící specifikace a upravit KÚ/KÚ nebo Část obce/Část obce | Provádění nápočtů bude řešeno s dodavatelem systému AgriGIS, bude se jednat o realizaci prostorového průniku prvků a zápis údajů do databáze prvků EVI. | NE |  |
|  |  | 1.3. Celá kapitola 7. 2.3. V dokumentaci se střídají pojmy „karta obce“ a „karta části obce“, aniž je jednoznačně určeno, která z těchto entit představuje základní evidenční jednotku modulu PR VAK. 3.3. Nejednoznačné vymezení evidenční jednotky (obec × část obce) může ovlivnit rozsah implementace i ocenění nabídky. 4.3. Jasně specifikovat, zda je požadováno sledovat údaje na obec / část obce, popř. katastrální území v souvislosti s tím, jak se zadavatel postaví k řešení rozporu katastr/část obce. | Pojem karta obce je zaužívaným pojmem v agendě PR VAK, nicméně Zadavatel upřesňuje, že nejmenší referenční jednotkou je část obce nebo městská část, pokud jsou v dané obci vymezeny. Pokud vymezeny nejsou je nejnižší jednotkou evidence obec. | NE |  |
|  |  | 1.4. Historická data (kap. 7.7.) 2.4. Není jasné, zda je požadovaný import historických geodat, která jsou součástí karet částí obcí v řadě stávajících PRVK. 3.4. Zcela jistě vyvolá diskusi o tom, jak se postavit k rozpornému požadavku vyplývajícímu z legislativy, kdy geodata infrastruktury VaK jsou v DTM, ale současně jsou ve fakticky mnohem lepším a konsolidovanějším a pro potřebu agendy PRVK na krajské úrovni mnohem vhodnějším stavu v krajských databázích PRVK. 4.4. Jasně specifikovat, jaká data a v jakém rozsahu se mají importovat a rozhodnout, zda stávající geodata PRVK ignorovat a nahradit je daty DTM, popř. je na základě dat DTM aktualizovat, jakkoli, ale jasně definovat. | Import historických geodat není součástí importu, proto se o něm zadávací dokumentace nezmiňuje. | NE |  |
|  |  | 1.5. Evidované atributy (kap. 7.11.) 2.5. Dále budou evidovány součtové údaje za ORP, kraje, ČR, povodí, aglomerace atd. – Použití formulace „atd.“ neumožňuje jednoznačně určit rozsah požadovaných agregací. 3.5. Nejednoznačný rozsah agregovaných údajů může způsobit rozdílné ocenění implementace této funkcionality. 4.5. Buď jasně vymezit množinu, nebo zadat jako parametrizovatelnou úlohu jejímž vstupem mohou být libovolné objekty s polygonovou geometrií.  | Zadavatel provede úpravu textu, aby byla odstraněna nejistota ohledně rozsahu požadované funkcionality. | ANO | Text v podkapitole 7.11 byl upraven tak, aby představoval taxativní výčet. |
|  |  |  |  |  |  |
|  | Kapitola 8: Požadavky na agendovou komponentu Evidence technicko bezpečnostního dohledu (ETBD) |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1a) V požadavcích na integraci je uveden požadavek na napojení Agrigis. 2a) b) MZe disponuje systémem LPIS, který je implementován jak nyní na SEPO, tak i přes ESB na jiné systémy resortu (např. SZIF nebo ÚKZÚZ). Vytvářením dalšího způsobu integrace ze SEPO a úpravami v Agrigis SW se výrazně navyšují náklady na integrace, které jsou již v základním režimu funkční. Ve stejném odstavci je uvedeno, že Dodavatel zajistí, že mapová aplikace bude čerpat prostorová data … Ze zadání není jasné, zda Dodavatel pod smlouvou na rozvoj ISVAK má zajistit úpravy mapové aplikace (Agrigis/LPIS) nebo se jedná o mapovou aplikaci, která je uvnitř ISVAK. Bylo by vhodné tuto část v bodě 8.3 přesněji specifikovat. | Využití platformy AgriGIS vychází z požadavků zadavatele na GIS řešení a z cílové architektury systému. Od GIS komponenty zadavatel požaduje zejména vysokou míru flexibility při zobrazování prostorových dat a možnost škálovatelného začlenění mapových funkcí do jednotlivých modulů a uživatelských rozhraní systému. Zadavatel uvádí, že systém AgriGIS je postaven na platformě ArcGIS Enterprise (https://enterprise.arcgis.com/en/). Úpravy mapových aplikací budou realizovány provozovatelem systému AgriGIS. Dodavatel funkčního celku EVI zajistí integraci mapových aplikací do uživatelského rozhraní EVI. Možnosti integrace jsou popsány v dokumentaci platformy ArcGIS Enterprise. Jako vhodná varianta se nabízí zejména využití ArcGIS Maps SDK for JavaScript (dříve ArcGIS API for JavaScript). | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 9: Požadavky na agendovou komponentu Samostatná evidence dokumentů (SED) |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 10: Požadavky na komponentu Jmenného rejstříku |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Harmonogram realizace  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Možnost zkrácení | NE |  |  |  |
|  |  | Harmonogram, jak je navržen, nedává prostor pro významné zkrácení. | Zadavatel ponechá možnost nabídnout zkrácení doby realizace a související hodnoticí kritérium. Cílem Zadavatele je umožnit dodavatelům uplatnit jejich zkušenosti, kapacity, know-how a případné vlastní metodické či technologické postupy, které mohou vést k efektivnějšímu průběhu vývoje a rychlejšímu dodání řešení. Rozsah garantované součinnosti poskytované Zadavatelem je popsán v zadávací dokumentaci a Uchazeči by při stanovení nabízených termínů měli vycházet z těchto podmínek. Termín realizace nabídnutý Uchazečem v rámci tohoto hodnoticího kritéria bude pro vybraného dodavatele závazný. Zadavatel si je současně vědom skutečnosti, že v průběhu realizace mohou nastat okolnosti, které dodavatel nemůže objektivně ovlivnit, včetně případných prodlení způsobených na straně Zadavatele. Z tohoto důvodu smlouva obsahuje ustanovení, na jehož základě může dodavatel v odůvodněných případech požádat o prodloužení termínu plnění. Takový požadavek bude posouzen a případně schválen Zadavatelem v souladu se smluvními podmínkami. | NE |  |
|  | Zajištění dodržení harmonogramu | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Seznam významných služeb |  |  |  |  |
|  | Obecné požadavky na seznam služeb  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Předmět plnění referenční služby | Srozumitelné – ANO Přiměřené – NE Splnitelné - ANO |  |  |  |
|  |  | Chybí vazba IS na výrazně specifickou oblast VaK. Zkušenosti s obecnými IT systémy mohou být v kontextu takto specifických agend nedostatečné. | Vzhledem k úzkému a vysoce specializovanému charakteru tohoto odvětví by stanovení takového požadavku mohlo vést k neúměrnému omezení hospodářské soutěže a potenciálně diskriminačnímu nastavení kvalifikačních podmínek. Zadavatel proto požaduje reference na informační systémy obdobného rozsahu a složitosti bez omezení na konkrétní odvětví. | NE |  |
|  |  |  |  |  |  |
|  | Požadavek na ISVS | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Služba na dodávku aplikace / IS | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Služba na provoz aplikace / IS | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Seznam členů realizačního týmu a jejich kvalifikace |  |  |  |  |
|  | (1) Obecné požadavky na realizační tým | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (2) Minimálně jedna (1) osoba v kategorii role Solution Architekt splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (3)Minimálně jedna (1) osoba v kategorii role Aplikační architekt splňující následující požadavky:  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (4) Minimálně jedna (1) osoba v kategorii role Projektový manažer splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (5) Minimálně dvě (2) osoby v kategorii role Analytik IT senior splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (6) Minimálně pět (5) osob v kategorii role Vývojář splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (7) Minimálně jedna (1) osoba v kategorii role Tester splňující následující požadavky: | ANO/NE |  |  |  |
|  |  |  |  |  |  |
|  | (8) Minimálně jedna (1) osoba v kategorii role Bezpečnostní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (9) Minimálně jedna (1) osoba v kategorii role Manažer provozu splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (10) Minimálně dvě (2) osoby v kategorii role Provozní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (11) Minimálně jedna (1) osoba v kategorii role Specialista uživatelské podpory splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (12) Minimálně jedna (1) osoba v kategorii role SCRUM master splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Celková nabídková cena: 30 % | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Návrh vybraných částí řešení: 30 % | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Prokázání odborných znalostí: 30 % | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Urychlení vývoje a dodání vybraných modulů: 10 % | NE |  |  |  |
|  |  | Kolize s otázkami k harmonogramu. | Zadavatel ponechá možnost nabídnout zkrácení doby realizace a související hodnoticí kritérium. Cílem Zadavatele je umožnit dodavatelům uplatnit jejich zkušenosti, kapacity, know-how a případné vlastní metodické či technologické postupy, které mohou vést k efektivnějšímu průběhu vývoje a rychlejšímu dodání řešení. Rozsah garantované součinnosti poskytované Zadavatelem je popsán v zadávací dokumentaci a Uchazeči by při stanovení nabízených termínů měli vycházet z těchto podmínek. Termín realizace nabídnutý Uchazečem v rámci tohoto hodnoticího kritéria bude pro vybraného dodavatele závazný. Zadavatel si je současně vědom skutečnosti, že v průběhu realizace mohou nastat okolnosti, které dodavatel nemůže objektivně ovlivnit, včetně případných prodlení způsobených na straně Zadavatele. Z tohoto důvodu smlouva obsahuje ustanovení, na jehož základě může dodavatel v odůvodněných případech požádat o prodloužení termínu plnění. Takový požadavek bude posouzen a případně schválen Zadavatelem v souladu se smluvními podmínkami. | NE |  |
|  |  |  |  |  |  |
|  | Předpokládaná hodnota zakázky | NE |  |  |  |
|  |  | Nepřiměřené k ceně za kterou MZE poptávalo dodávku menšího početu Komponent za srovnatelnou cenu v r. 2023. Nepřiměřené aktuálním požadavkům na integrace, importy, složení týmu, …. | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. Limit pro výši nabídkové ceny byl na základě PTK zrušen, nabídková cena tedy může přesáhnout předpokládanou hodnotu VZ. | ANO | Úprava podmínek uvedených v zadávací dokumentaci. |
|  | Limity pro nabídkovou cenu | NE |  |  |  |
|  |  | Viz výše | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. Limit pro výši nabídkové ceny byl na základě PTK zrušen, nabídková cena tedy může přesáhnout předpokládanou hodnotu VZ. | ANO | Úprava podmínek uvedených v zadávací dokumentaci. |
|  | Platební podmínky | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Bankovní záruka | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Lhůta pro podání nabídek | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  |  | NE |  |  |  |
|  |  | Integrace na AgriGis: Rozhraní mapové aplikace není specifikováno (API, autentizace, filtrace, formát dat)  | API rozhraní pro komunikaci s AgriGIS, který je postaven na platformě ArcGIS Enterprise, bude navrženo v rámci realizace projektu. Technologické možnosti a omezení integračního rozhraní proto vycházejí z funkcionalit a standardních integračních mechanismů této platformy. https://enterprise.arcgis.com/en/ Zadavatel uvádí, že za určení rozsahu objektů určených k zobrazení odpovídá příslušná komponenta funkčního celku. Zadavatel nepovažuje za vhodné přenášet business logiku a rozhodování o rozsahu předávaných dat do obecné sdílené GIS platformy poskytující primárně vizualizační služby. Formát předávaných dat bude stanoven v součinnosti s dodavatelem systému AgriGIS. Zadavatel však předpokládá, že prostřednictvím rozhraní budou předávány identifikátory objektů určených k zobrazení, případně jiné údaje nezbytné pro jejich jednoznačnou identifikaci. AgriGIS následně zajistí dohledání odpovídajících geoprostorových prvků a jejich zobrazení na základě údajů evidovaných ve svém datovém úložišti. Ověřování oprávnění uživatele a rozhodování o rozsahu zobrazovaných dat tak zůstává na straně funkčního celku. Zadavatel doplní zadávací dokumentaci tak, aby reflektovala výše uvedené vysvětlení. | ANO | Text doplněn do podkapitoly 2.16. |
|  |  | Historická data a jejich import: Není dostatečně specifikováno, v jakém rozsahu je požadovaná migrace dat ze stávajících systémů.  | Zadavatel doplní zadávací dokumentaci o informace týkající se rozsahu historických dat v agendách ETBD a PP VAK. Zadavatel dále uvádí, že součástí zadávací dokumentace budou také popisy datových struktur a tabulek historických dat. Je přesvědčen, že tyto informace poskytnou dodavatelům dostatečný podklad pro odhad rozsahu migračních prací. Konkrétní způsob migrace a transformace dat bude následně navržen dodavatelem v rámci jím předloženého řešení. | ANO | Text byl doplněn o kapitolu 6.6 zaměřenou na definici rozsahu historických dat v modulu PP VAK, a dále o podkapitolu 8.9 zaměřenou na definici rozsahu historických dat v agendě ETBD. |
|  |  | Kontroly: Zadávací dokumentace předpokládá rozsáhlý systém validačních kontrol. Není však jednoznačně určeno, které kontroly jsou blokující, které mají pouze informativní charakter a jaký je jejich vliv na další zpracování dat. | Konfiguraci závažnosti chyby je možné realizovat v nastavení administrátora. Stanovovat u jednolitých validací jejich závažnost není účelné, protože ho bude možné měnit v tomto rozhaní. Další vysvětlení vlivu chyb na zpracování dat je předmětem požadavků zadávací dokumentace. | NE |  |
|  |  | Atributy / datový model: Zadávací dokumentace na více místech předpokládá doplnění nebo rozšíření evidovaných atributů v rámci implementační analýzy. Není však jednoznačně stanoveno, jaký rozsah změn je ještě považován za zpřesnění zadání a od jakého okamžiku se již jedná o změnu rozsahu plnění.  | Z pohledu zadavatele lze evidovaná data rozdělit na agendová data, jejichž rozsah je definován příslušnými právními předpisy, a systémová data, která slouží k zajištění fungování funkčního celku a poskytování požadovaných funkcí a služeb. V případě agendových dat je jejich rozsah dán příslušnou legislativou. Součástí zadávací dokumentace bude struktura stávající datové základny systému IS VAK i datové základny ETBD. Zadavatel do zadávací dokumentace explicitně uvede, že předpokládaný rozsah agendových dat, se kterým má dodavatel při návrhu řešení počítat, bude odpovídat 150 % současného objemu evidovaných dat. V případě systémových dat je na odbornosti a zkušenostech dodavatele, aby na základě požadovaných funkcionalit a služeb, jakož i své předchozí praxe, kterou mimo jiné prokazuje referenčními zakázkami, navrhl takový datový model, který zajistí řádné fungování požadovaných funkcí a služeb. | NE |  |
|  |  | Exporty: Zadávací dokumentace definuje XML jako výměnný formát pro import některých dat, není však zřejmé, zda je požadována i podpora exportů ve stejném nebo jiném standardizovaném výměnném formátu. Doporučujeme zvážit požadavek na podporu exportů ve formátu XML, případně jednoznačně definovat podporované výměnné formáty jednotlivých komponent. Není jednoznačně specifikován obsah jednotlivých exportů ani rozsah exportovaných atributů. | Zadavatel upřesní dokumentaci s ohledem na formáty exportovaných dat. Zadavatel dále uvádí, že rozsah exportů je volitelný a proměnlivý a souvisí s nastavením rozhraní uživatele. Nebo je naopak dán strukturou záznamu a vychází ze stávající aplikace. | ANO | Text byl doplněno nový požadavek v podkapitole 3.6, který definuje, že detail záznamů bude možné exportovat ve formátech XLSX, XML a PDF. Dále došlo ke sjednocení požadavku na formáty v podkapitole 3.6 v části "Formáty exportu". V jednotlivých modulech a komponentách byly informace ponechány, jen pokud představují nějakou odchylku od těchto požadavků nebo se jedná o specifický příklad exportu. Pokud informace v textu uvedena není, počítá se s možností exportu XLSX a PDF. Zadavatel připomíná, v návaznosti na připomínku, že je nutné definovat obsah jednotlivých exportů, že exporty (v případě seznamů) mají proměnlivý obsah na základě výsledku filtrování. Pokud není filtrování možné exportují se všechny dosupné atributy. Dále v detailu záznamu je možné vyexpotovat všechny atributy. Pokud je někde specificky zvedeno, že funkcionalita vychází ze stávající aplikace, pak rozsah exportu odpovídá stávající aplikaci jejíž instalační soubory budou součástí Zadávací dokumentace. |
|  |  |  |  |  |  |
| Název obchodní společnosti: Dodavatel č. 4 |  |  |  |  |  |
|  |  | Komentář Dodavatele č. 4 | Vysvětlení/Reakce | Zapracováno |  |
|  | Otázky k předmětu plnění |  |  |  |  |
|  | Kapitola 1: Stávající stav ICT zajištění agendy VaK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 2: Požadavky na nový systém |  |  |  |  |
|  |  | 1. identifikace části zadání: a) Záměr vybudování komponent SeD a Jmenný rejstřík se částečně obsahově překrývá s již existujícími systémy v resortu MZe – Společný zemědělský registr SZR a DMS MZe (Spisová služba MZe). 2a) Oba stávající systémy v resortu MZe fungují ve stabilní provozu a pokrývají funkčnosti, které lze v budoucnu z velké části očekávat i po komponentách uvedený v zadávací dokumentaci. 3a) Funkčnosti sice nejsou v této nulové fázi uvedeny, ale je velká pravděpodobnost, že při provozu tyto funkčnosti budou požadovány a MZe bude muset do budoucna řešit rozvoj, a i provoz fakticky totožných systémů. 4a) Zvážit požadavky na architekturu budoucího systému a s využitím existujících systémů snížit nároky na implementaci jak finanční, tak i časovou. | Navržená architektura vychází z požadavků Zadavatele na zajištění požadovaných funkcionalit systému, a to zejména ve vazbě na požadavky Digitální a informační agentury a Národního architektonického rámce. Zadavatel se otázkou využití stávajících resortních systémů zabýval, nicméně po posouzení účelu a požadovaných funkcí jednotlivých komponent a po zpracování SWOT analýzy jednotlivých variant nepředpokládá změnu navržené architektury ani požadovaného rozdělení systému na jednotlivé komponenty. | NE |  |
|  |  | b) Požadavek na migraci dat. 4b) Z podkladů předaných v rámci PTK není dostatečně zřejmý rozsah ani původ dat, které mají být migrovány. Vzhledem k faktu, že analýza cílového řešení teprve má vznikat není jasné jakou formou a jak hodně bude nutné původní data přizpůsobovat novému systému. Pokud by proběhl nejdříve projekt na analýzu cílového systému a až následně projekt na vývoj a migraci (dle analýzy), bude už větší prostor pro přesnější možnost přípravy zadávací dokumentace. | Zadavatel doplní zadávací dokumentaci o informace o počtu evidovaných prvků v jednotlivých agendách. Současně budou součástí podkladů pro realizaci řešení popisy datových struktur a tabulek zdrojových systémů. Zadavatel je přesvědčen, že tyto informace poskytnou dodavatelům dostatečný podklad pro odhad rozsahu migračních prací. Konkrétní způsob migrace a transformace dat bude následně navržen v rámci řešení dodavatele. | ANO | Text byl doplněn o podkapitolu 6.6 zaměřenou na definici rozsahu historických dat v modulu PP VAK, a dále o podkapitolu 8.9 zaměřenou na definici rozsahu historických dat v agendě ETBD. |
|  |  | c) Požadavky na vlastní databázi pro každou komponentu. 2c) V podkladech PTK je uveden požadavek na vlastní databáze pro každou komponentu a není úplně zřejmě, zda tento požadavek znamená samostatné oddělení instance Oracle (s dopady na licenční politiku Oracle a HW požadavky) nebo je možné toto řešit pouze formou DB schémat. | Zadavatel na základě detailního analýzy zhodnotil možnosti provozu databází jednotlivých komponent a optimalizoval svoje požadavky na rozsah, a to při současném zachování požadavků na jejich technologickou oddělitelnost, nezávislý rozvoj a možnost samostatného škálování. Konkrétní požadavky v této oblasti budou v zadávací dokumentaci případně dále upřesněny. | ANO | Text byl doplněn o podkapitolu 2.2.3, která vysvětluje požadavky na členění databází. |
|  |  | 1d) V požadavcích je uvedeno, že nejsou povoleny vazby na databáze jiných komponent. 2d) V resortu MZe je velké množství sdílených datových zdrojů (RUIAN, RPP, číselník útvarů, číselník subjektů, aj. (např. číselníky CUZK – číselník států)) u kterých lze předpokládat, že je bude nový systém využívat. Vyloučením přístupu do těchto sdílených datových zdrojů znamená, že si každá ze 4 nových komponent má udržovat svou vlastní kopii tohoto datového zdroje a zajišťovat aktualizaci tohoto datového zdroje.  | Specifikace požadavku na omezení přímých vazeb mezi databázemi je vedena obecnějším požadavkem na technologickou oddělitelnost jednotlivých komponent, tedy požadavkem na omezení přímých závislostí mezi jejich aplikačními databázemi a zajištění jejich nezávislého rozvoje a provozu. | NE |  |
|  |  | e) Nesoulad počtu běhového prostředí ISVAK a ESB. Nutná součinnost ESB a stanovení cílového řešení za ESB. 2e) V PTK je uvedeno, že prostředí ISVAK bude provozováno na třech prostředích. Dále je uváděna přímá vazba na Agribus. ESB v současné podobě má pouze dvě prostředí a routování komunikací přes 3 prostředí bude vyžadovat úpravy na ESB. 4e) PTK i budoucí zadávací dokumentace, by měla striktně uvádět místa, kdy je vyžadována součinnost po jiném systému, ale zamýšlená funkčnost tohoto systému není v době zadání výběrového řízení funkční. Lze tedy očekávat, že předložená analýza na ISVAK může být revidována, protože MZe nezajistí součinnost u třetí strany. Vhodnější by bylo zadávací dokumentaci uvádět s již před dohodnutým technickým řešením u třetích straně (SEPO, ESB, OracleDB, infrastruktura). Vhodnější je řešit analýzu vlastním projektem, kdy výstupem je již dohodnuté řešení, které je pro všechny strany akceptovatelné a poté vyvíjet SW již do tohoto prostředí – usnadní se jak forma nacenění, tak MZe i aktivně předejte případným implementačním problémům mezi systémy. | Připomínka v bodu e) obsahuje dvě témata: 1) Zadavatel konstatuje, že pro účely integrací bude preprodukční prostředí IS VaK využívat testovací prostředí AgriBus. Tento přístup odpovídá i charakteru navazujících integračních vazeb, kdy jsou na preprodukční prostředí IS VaK napojovány testovací nebo neprodukční instance integrovaných systémů. Zadavatel proto v této oblasti nepředpokládá potřebu dalších úprav ani rozšíření prostředí platformy AgriBus. 2) Zadavatel konstatuje, že součinnost je požadována u všech systémů, které jsou integrovány. V případě prodlení, která nebudou způsobena na straně Dodavatele obsahuje Smlouva mechanismus pro prodloužení termínů dodání v odůvodněných případech. | NE |  |
|  |  | f) Omezený rozsah standardních technologií. 2f) V soupisu standardních technologií MZe neuvádí možnosti použití jazyka python. Jedná se o nejpopulárnější vývojový jazyk v současnosti, a tedy by bylo vhodné upřesnit, zda jej MZe ignoruje z nějakého jasného důvodu. | Standardní technologie uvedené v zadávací dokumentaci vymezují technologie, jejichž licence, instalaci, provoz a maintenance zajišťuje zadavatel. Tento seznam nepředstavuje výčet povolených programovacích jazyků ani technologické omezení pro návrh řešení. Zadavatel použití programovacího jazyka Python nijak nevylučuje ani neomezuje. Volba konkrétních programovacích jazyků a technologií je na dodavateli, pokud jsou splněny požadavky zadávací dokumentace a navržené řešení je v souladu s architektonickými a provozními požadavky zadavatele. | NE |  |
|  |  | g) PTK předpokládá pro autentizaci vlastní nástroj. 2g) V PTK je uvedeno (kapitola 2.5), že se pro autentizaci nevyužije používané SSO, ale Authorization Code Flow. Tento nástroj MZe nyní nemá a MZe nemá funkční ani napojení na CAAIS. 4g) V rámci budoucího zadání na dodávku IS VAK by bylo vhodné uvádět pouze technologie a datové zdroje, které MZe má k dispozici, aby nebyl případný dodavatel překvapen, že popisované řešení v zadávací dokumentaci nelze realizovat z důvodů nedostatků na straně Zadavatele. Napojení mimo stávající SSO přinese komplikace v překlikávání mezi systémy – ISVAK to SEPO, ISVAK to LPIS, SEPO to ISVAK. | Zadavatel hodlá využívat autentizační technologii uvedenou v zadávací dokumentaci, v době realizace projektu budou tyto prvky dostupné. Případné problémy související s její dostupností budou v průběhu realizace projektu řešeny standardními postupy projektového řízení a v souladu se smluvním rámcem, kterým se bude řídit realizace předmětu veřejné zakázky. | NE |  |
|  |  | h) Penetrační testování ze strany Dodavatele. 2h) Pokud Zadavatel provádí své penetrační testování je požadavek bodu 2.13 nadbytečný a zbytečně by celé dílo prodražilo. | Po zvážení připomínek, interních kapacit a rizik souvisejícíh s úpravou, bude provedena úprava požadavku v navrženém smyslu. | ANO | Text byl upraven v podkapitole 2.13, kde došlo ke změně textu zabývajícího se penetračním testováním. |
|  |  | i) Integrace na GIS (kapitola 2.16) 4i) Napojení na systém stávající GIS nástroj LPIS se jeví jako výhodnější než používat AgriGIS. V LPIS je plná podpora pro přihlášení přes SSO a identifikace subjektů ve vazbě na loginy. Možnost práce s různými vrstvami (KN, voda, CRVE), příjem dat z LPIS přes ESB, předávání údaje přes postmessaging (již dnes funguje mezi SEPO a LPIS), možnost práce se SHP a i možnosti kreslení a přenos SHP do ISVAK. Propojení s LPIS umožní i přenos identity uživatele jak je uvedeno ve větě: Toto bude zajištěno prostřednictvím služby vystavené systémem, která na základě identity uživatele vrátí odpovídající množinu dat (např. seznam dostupných prvků nebo jejich identifikátorů).  | Využití platformy AgriGIS vychází z požadavků zadavatele na GIS řešení a z cílové architektury systému. Zadavatel od GIS komponenty požaduje zejména vysokou míru flexibility při zobrazování prostorových dat a možnost škálovatelného začlenění mapových funkcí do jednotlivých modulů a uživatelských rozhraní systému. Zadavatel současně nepředpokládá využití GIS komponenty pro editaci prostorových dat. | NE |  |
|  | Kapitola 3: Základní požadavky na funkční celek |  |  |  |  |
|  |  | 1a) použití zabezpečeného protokolu. 2a) V části logování je uveden požadavek na použití zabezpečeného komunikačního protokolu. Z PTK není jasné, zda zajištění této komunikace je věcí infrastrukturního prostředí MZe nebo si celou organizaci přístupu uživatelů k aplikačním systémům musí řešit Dodavatel sám. | Zajištění infrastrukturních prostředků pro zabezpečenou komunikaci je odpovědností zadavatele. Dodavatel je odpovědný za kompatibilitu dodávaného řešení s těmito prostředky a za podporu využití standardních bezpečných komunikačních protokolů. | NE |  |
|  |  | 1b) využití sdílených číselníků 2b) v části 3.11 je odkaz na číselníky, které již resort v rámci svých systémů sdílí (RPP a číselník ORP). Není smysluplné realizovat v rámci ISVAK (a vlastně samostatně v každé komponentě) replikaci těchto číselníků, a i trvalou aktualizaci. | Specifikace požadavku na omezení přímých vazeb mezi databázemi je vedena obecnějším požadavkem na technologickou oddělitelnost jednotlivých komponent, tedy požadavkem na omezení přímých závislostí mezi jejich aplikačními databázemi a zajištění jejich nezávislého rozvoje a provozu. | NE |  |
|  |  | 1c) funkčnosti SEPO | Popis funkčnosti SEPO bude součástí NDA dokumentace. | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 4: Požadavky na agendovou komponentu – modul MP VAK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1a) Očekávání funkcí, které systémy MZe nemají. 2a) v bodě 4.4 jsou na systém SEPO kladeny funkční požadavky, které systém nyní neposkytuje. PTK by mělo v rámci svého popisu vycházet z funkčností, které Zadavatel již má implementované. V bodě je i uvedeno přesměrování do rozhraní SEPO, které ale vyžaduje jasné sdílení přihlášeného účtu přes SSO a tím předejetí situace odlišného přihlášení v jednotlivých systémech. 3a)Nepřesnosti v PTK a v budoucnu i v zadávací dokumentaci mohou být k tíži dodavatele, který může nabýt dojmu, že funkčnost specifikovaná ze strany Zadavatele je k dispozici a nebude předpokládat, že celou realizaci ISVAK jak analýzu, tak i samotnou dodávku může komplikovat součinnost třetí strany. Zadavatel by měl z důvodů očekávané cenové nabídky na dodání díla přesněji specifikovat, zda v rámci etapy analýzy očekává součinnost se třetí stranou, jak tato bude financována a jak bude řešeno případné prodlení ze strany třetí strany.  | Zadavatel předpokládá, že funkcionality a integrační rozhraní systému SEPO, které jsou v zadávací dokumentaci zohledněny, budou v době realizace projektu dostupné. Zadavatel současně počítá s nezbytnou součinností správců a dodavatelů integrovaných systémů při realizaci integračních vazeb. Skutečnost, že některé související systémy procházejí vlastním rozvojem, není v prostředí rozsáhlých informačních systémů neobvyklá. Zadavatel proto nepovažuje za nutné omezovat návrh cílového řešení výhradně na funkčnosti dostupné ke dni přípravy zadávací dokumentace. Případná koordinace rozvoje navazujících systémů bude zajištěna zadavatelem v rámci realizace projektu.  | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 5: Požadavky na agendovou komponentu – modul VS VAK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1a) a) Využití SEPO i pro potřeby hlášení přímo do SED. 3a) a) Vytváření vstupních formulářů (a návazné logiky) na dvou místech (SEPO a SED) může být v budoucnu komplikované pro zajištění konzistence a také dvojnásobení nákladů na provoz této části systému. Jako výhodnější se jeví ruční vstup dat také přes SEPO, ale v odlišném režimu, nicméně s využitím stejné struktury formuláře i přenosu dat do ISVAK. | Zadavatel nesouhalsí s Doporučením a ponechá Zadávací dokumentaci v části komponenty SED, resp. její existence a uvažované funkcionality, nezměněnou. | NE |  |
|  |  | 3b) V rámci kapitoly je uvedeno propojení přes ESB VAK a SEPO. Jako hlavní identifikátor subjektů by mělo sloužit SZRID. To sice uvedené v části Jmenného rejstříku je, ale není uveden žádný požadavek na napojení SZR a jeho služby a logiku. Bylo by tedy vhodné do zadávací dokumentace uvést, že napojení na SZR je bezpodmínečně nutné pro funkčnost jak ISVAK, tak i integračních vazeb. | SZRID je součástí komunikace autentizačního a autorizačního systému MZe. Zadavatel doplní integraci na systém SZR, která umožňuí na základě SZRID získat údaje o subjektu a naopak. | ANO | Do pokapitoly 2.4 Integrace systému byl doplněn text o napojení na SZR. |
|  |  |  |  |  |  |
|  | Kapitola 6: Požadavky na agendovou komponentu – modul PP VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 7: Požadavky na agendovou komponentu – modul PR VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 8: Požadavky na agendovou komponentu Evidence technicko bezpečnostního dohledu (ETBD) |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 9: Požadavky na agendovou komponentu Samostatná evidence dokumentů (SED) |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1a) Vývoj systému nahrazující elektronickou spisovou službu 2a) a) V prostředí MZe již existuje elektronická spisová služba. Vytváření dalšího systému, který tento systém nahrazuje komplikuje celý proces implementace. Lze očekávat, že v první fázi bude SED pokrývat třeba 20% funkčnosti stávajícího systému DMS, ale lze očekávat, že se časem ukáže nutnost rozvoje SED, které ve výsledku budou podobné nebo totožné s DMS, a to bude znamenat provozovat dva velmi shodné systémy a zajišťovat soulad s legislativou. Už jenom tvorba SIP balíčků nebo práce se spisy je operace, kterou lze přes národní standard pro spisové služby vyžadovat po DMS a neřešit toto odděleným systémem. DMS MZe je přes národní standard publikované do ESB a využití služeb národního standardu umožní nahlížet na SED jako na plně transparentní systém, který je přes národní standard dostupný a snadno vyměnitelný. | Navržená architektura vychází z požadavků Zadavatele na zajištění požadovaných funkcionalit systému, a to zejména ve vazbě na požadavky Digitální a informační agentury a Národního architektonického rámce. Zadavatel se otázkou využití stávajících resortních systémů zabýval, nicméně po posouzení účelu a požadovaných funkcí jednotlivých komponent a po zpracování SWOT analýzy jednotlivých variant nepředpokládá změnu navržené architektury s ohledem na komponentu SED. | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 10: Požadavky na komponentu Jmenného rejstříku |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1a) Jmenný rejstřík jako komponenta 2a) Z podstaty se jedná o obdobné funkčnosti, které již dnes nabízí systém SZR, který veškeré očekávané funkčnosti má implementované a pokryté provozní podporou, a hlavně vyjasněné funkčnosti s ohledem na integraci na ISZR a několik agendových systémů. SZRID jakožto jednotný identifikátor může sloužit jak pro práci v SEPO u podání, tak i zpětný identifikátor pro vizualizaci dat v mapě. Lze jej také používat pro vazby na DMS. Se SZRID se níže počítá, a tedy se počítá s propojením na SZR. Je tedy možné využít jak funkčnosti SZR směrem k externím systémů, tak i řešení EXTID s cílem evidence rolí subjektu v dílčích komponentách ISVAK (garant MP VAK nebo referent MP VAK). Pokud by zůstal Jmenný rejstřík je stejně nutné IS VAK napojit na SZR, a tím umožnit držení kontextu subjektu mezi systémy MZe – ISVAK a LPIS nebo SEPO a ISVAK. 4a) Funkčnost Jmenného rejstříku může zastoupit SZR, které poskytuje veškeré funkcionality týkající se subjektů a to jak omezení duplicit, tak i propojení na externí registry a propojení na NIA a DS. | Navržená architektura vychází z požadavků Zadavatele na zajištění požadovaných funkcionalit systému, a to zejména ve vazbě na požadavky Digitální a informační agentury a Národního architektonického rámce. Zadavatel se otázkou využití stávajících resortních systémů zabýval, nicméně po posouzení účelu a požadovaných funkcí jednotlivých komponent a po zpracování SWOT analýzy jednotlivých variant nepředpokládá změnu navržené architektury s ohledem na komponentu SED. | NE |  |
|  |  |  |  |  |  |
| 4.&#9;Otázky k předpokládanému harmonogramu |  |  |  |  |  |
|  | Harmonogram realizace  | NE |  |  |  |
|  |  | Reálné riziko vnímáme ve sloučení analýzy i dodávky do jedné zakázky s fixní cenou. Analýza tak rozsáhlého systému, včetně návrhu integrací, odsouhlasení těchto integrací a zajištění spolupráce třetích stran na úpravy existujících systémů na MZe může celý harmonogram dodávky posunout úplně mimo očekávané mantinely. Až samotná analýza může naznačit, že požadavky kladené ze strany MZe na hotové dílo bude znamenat například navýšení vysoutěžené ceny.  | Zadavatel si je vědom rizik spojených s realizací rozsáhlých informačních systémů. Současně však konstatuje, že realizace veřejných zakázek formou dodávky zahrnující implementační analýzu i následnou implementaci v rámci jednoho projektu představuje běžný postup, který zadavatel dlouhodobě využívá i u dalších informačních systémů. | NE |  |
|  | Možnost zkrácení | NE |  |  |  |
|  |  | S ohledem na velký rozsah součinností ze strany Objednatele vidíme možnost zkrácení reálně pouze v případě aktivního přístupu Objednatele. Jako poskytovatel disponujeme dostatečným vývojovým týmem, abychom část realizovanou čistě v našem režimu dodali co nejdříve. | Zadavatel ponechá možnost nabídnout zkrácení doby realizace a související hodnoticí kritérium. Cílem Zadavatele je umožnit dodavatelům uplatnit jejich zkušenosti, kapacity, know-how a případné vlastní metodické či technologické postupy, které mohou vést k efektivnějšímu průběhu vývoje a rychlejšímu dodání řešení. Rozsah garantované součinnosti poskytované Zadavatelem je popsán v zadávací dokumentaci a Uchazeči by při stanovení nabízených termínů měli vycházet z těchto podmínek. Termín realizace nabídnutý Uchazečem v rámci tohoto hodnoticího kritéria bude pro vybraného dodavatele závazný. Zadavatel si je současně vědom skutečnosti, že v průběhu realizace mohou nastat okolnosti, které dodavatel nemůže objektivně ovlivnit, včetně případných prodlení způsobených na straně Zadavatele. Z tohoto důvodu smlouva obsahuje ustanovení, na jehož základě může dodavatel v odůvodněných případech požádat o prodloužení termínu plnění. Takový požadavek bude posouzen a případně schválen Zadavatelem v souladu se smluvními podmínkami. | NE |  |
|  | Zajištění dodržení harmonogramu | NIC |  |  |  |
|  |  |  |  |  |  |
| 5.&#9;Otázky k požadované technické kvalifikaci |  |  |  |  |  |
|  | Seznam významných služeb |  |  |  |  |
|  | Obecné požadavky na seznam služeb  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Předmět plnění referenční služby | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Požadavek na ISVS | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Služba na dodávku aplikace / IS | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Služba na provoz aplikace / IS | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Seznam členů realizačního týmu a jejich kvalifikace |  |  |  |  |
|  | (1) Obecné požadavky na realizační tým | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (2) Minimálně jedna (1) osoba v kategorii role Solution Architekt splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (3)Minimálně jedna (1) osoba v kategorii role Aplikační architekt splňující následující požadavky:  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (4) Minimálně jedna (1) osoba v kategorii role Projektový manažer splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (5) Minimálně dvě (2) osoby v kategorii role Analytik IT senior splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (6) Minimálně pět (5) osob v kategorii role Vývojář splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (7) Minimálně jedna (1) osoba v kategorii role Tester splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (8) Minimálně jedna (1) osoba v kategorii role Bezpečnostní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (9) Minimálně jedna (1) osoba v kategorii role Manažer provozu splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (10) Minimálně dvě (2) osoby v kategorii role Provozní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (11) Minimálně jedna (1) osoba v kategorii role Specialista uživatelské podpory splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (12) Minimálně jedna (1) osoba v kategorii role SCRUM master splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
| 6.&#9;Otázky ke kritériím hodnocení |  |  |  |  |  |
|  | Celková nabídková cena: 30 % | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Návrh vybraných částí řešení: 30 % | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Prokázání odborných znalostí: 30 % | NE |  |  |  |
|  |  | Prokazování technických dovedností členů týmu v oblastech, které jsou předmětem odborných testů v rámci certifikace a jsou prokázány účastí na úspěšně realizovaných referenčních zakázkách nedává smysl. Smysl dává pouze ověřování znalostí týkající se oblastí uvedeného zákona a vyhlášky pro Analytik IT senior. | Zadavatel s připomínkou nesouhlasí. Zadavatel je v případě tohoto projektu přesvědčen, že je účelné ověřit odborné znalosti členů realizačního týmu přímým způsobem. Referenční zakázky a certifikace sice prokazují předchozí zkušenosti a dosaženou odbornou úroveň, nezaručují však aktuální znalost problematiky ani znalost konkrétních principů a požadavků relevantních pro předmět této veřejné zakázky. | NE |  |
|  | Urychlení vývoje a dodání vybraných modulů: 10 % | NE |  |  |  |
|  |  | Je to možné, ale plnění kritéria je z velké části závislé na cílovém prostředí, jehož součástí je i dodávaný systém a urychlení vývoje tak není pouze v režii Dodavatele. Urychlení vývoje znamená i adekvátní poskytnutí součinnosti ze strany Zadavatele. Může se tak jednat pouze o deklarativní slib jednoho dodavatele, že to lze, ale ve výsledku není možné slib splnit. | Rozsah součinnosti Zadavatele je specifikován v zadávací dokumentaci. Zadavatel současně ponechává na posouzení jednotlivých uchazečů, zda a jakým způsobem jsou schopni dosáhnout zkrácení harmonogramu realizace. Odpovědnost za splnění navrženého harmonogramu a řádnou realizaci funkčního celku nese plně dodavatel. Zadavatel dále uvádí, že připravovaná smlouva obsahuje ustanovení, na jehož základě může dodavatel v odůvodněných případech požádat o prodloužení termínu plnění. Takový požadavek však podléhá schválení zadavatelem. | NE |  |
| 7.&#9;Další otázky zadavatele |  |  |  |  |  |
|  | Předpokládaná hodnota zakázky | NE |  |  |  |
|  |  | Při zohlednění očekávaného rozvoje v rozsahu 2760 MD, 50 MD součinnosti, dodání analýzy, dodání díla, migrace dat, pilotních provozů, školeních, školících materiálů a zajištění provozní podpory díla s podporou koncových uživatelů se předpokládaná hodnota zakázky jeví jako velmi nízká a nepřiměřená. | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. Limit pro výši nabídkové ceny byl na základě PTK zrušen, nabídková cena tedy může přesáhnout předpokládanou hodnotu VZ. | ANO | Úprava podmínek uvedených v zadávací dokumentaci. |
|  | Limity pro nabídkovou cenu | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Platební podmínky | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Bankovní záruka | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Lhůta pro podání nabídek | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
| Další připomínky mimo formulář |  | Nejsou |  |  |  |

Page 1

| Název obchodní společnosti: Dodavatel č. 1 |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- |
|  |  | Komentář Dodavatele č. 1 | Vysvětlení/Reakce | Dopad do ZD (ANO/NE) | Způsob zapracování |
|  | Otázky k předmětu plnění |  |  |  |  |
|  | Kapitola 1: Stávající stav ICT zajištění agendy VaK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 2: Požadavky na nový systém |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 3: Základní požadavky na funkční celek |  |  |  |  |
|  |  | 1. identifikace části zadání: Notifikace, tiskové výstupy 2. popis nepřesnosti: Zadávací dokumentace předpokládá generování tiskových výstupů a e-mailových notifikací, není však zřejmé, zda zadavatel požaduje použití konkrétní technologie pro tvorbu šablon, případně zda volba technologie zůstává na dodavateli. 3. dopad zjištěné nepřesnosti: Nejednoznačnost může vést k odlišnému technickému řešení a má přímý dopad na odhad pracnosti. 4. návrh upřesnění: Doporučujeme zvážit upřesnění, zda požaduje použití konkrétní technologie nebo nástroje pro tvorbu a správu tiskových a e-mailových šablon, nebo zda je volba technologie plně na dodavateli. | Zadavatel nepožaduje použití konkrétní technologie ani nástroje pro tvorbu a správu tiskových výstupů a e-mailových notifikací. Volba konkrétního technického řešení je na dodavateli, za předpokladu splnění všech funkčních, provozních a bezpečnostních požadavků zadávací dokumentace. | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 4: Požadavky na agendovou komponentu – modul MP VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 5: Požadavky na agendovou komponentu – modul VS VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 6: Požadavky na agendovou komponentu – modul PP VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 7: Požadavky na agendovou komponentu – modul PR VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 8: Požadavky na agendovou komponentu Evidence technicko bezpečnostního dohledu (ETBD) |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 9: Požadavky na agendovou komponentu Samostatná evidence dokumentů (SED) |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 10: Požadavky na komponentu Jmenného rejstříku |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
| 4.	Otázky k předpokládanému harmonogramu |  |  |  |  |  |
|  | Harmonogram realizace  | NE |  |  |  |
|  |  | Navrhované časy pro jednotlivé fáze nejsou dle našich zkušeností dostatečné. Riziková je především časová dotace na business analýzu, pro kterou navrhovaných 157MD je nedostatečných. Doporučujeme navýšení alespoň o 30MD | Zadavatel na základě připomínek získaných v rámci PTK prodlouží dobu na analýzu o 30 dní. | ANO | Úprava podmínek uvedených v Zadávací dokumentaci. |
|  | Možnost zkrácení | NE |  |  |  |
|  |  | Kritickým bodem implementace bude zajištění kapacit a součinnosti na straně Zadavatele. Doporučujeme, pokud je to možné, ponechat maximální možné časování, které Zadavatel může akceptovat. V opačném případě roste riziko nedodržení smluvních závazků nebo zanešení chyby.  | Zadavatel ponechá možnost nabídnout zkrácení doby realizace a související hodnoticí kritérium. Cílem Zadavatele je umožnit dodavatelům uplatnit jejich zkušenosti, kapacity, know-how a případné vlastní metodické či technologické postupy, které mohou vést k efektivnějšímu průběhu vývoje a rychlejšímu dodání řešení. Rozsah garantované součinnosti poskytované Zadavatelem je popsán v zadávací dokumentaci a Uchazeči by při stanovení nabízených termínů měli vycházet z těchto podmínek. Termín realizace nabídnutý Uchazečem v rámci tohoto hodnoticího kritéria bude pro vybraného dodavatele závazný. Zadavatel si je současně vědom skutečnosti, že v průběhu realizace mohou nastat okolnosti, které dodavatel nemůže objektivně ovlivnit, včetně případných prodlení způsobených na straně Zadavatele. Z tohoto důvodu smlouva obsahuje ustanovení, na jehož základě může dodavatel v odůvodněných případech požádat o prodloužení termínu plnění. Takový požadavek bude posouzen a případně schválen Zadavatelem v souladu se smluvními podmínkami. | NE |  |
|  | Zajištění dodržení harmonogramu | NE |  |  |  |
|  |  | V případě, že by Dodavatel sám navrhnul zkrácení harmonogramu, bude třeba zajistit kapacitně a kvalitativně silného zástupce pro pokrytí QA a koordinace mezi Dodavatelem a Zadavatelem. Případně doporučujeme zvážit řízení/koordinace některou z agilních metodik.  | Zadavatel ponechá možnost nabídnout zkrácení doby realizace a související hodnoticí kritérium. Cílem Zadavatele je umožnit dodavatelům uplatnit jejich zkušenosti, kapacity, know-how a případné vlastní metodické či technologické postupy, které mohou vést k efektivnějšímu průběhu vývoje a rychlejšímu dodání řešení. Rozsah garantované součinnosti poskytované Zadavatelem je popsán v zadávací dokumentaci a Uchazeči by při stanovení nabízených termínů měli vycházet z těchto podmínek. Termín realizace nabídnutý Uchazečem v rámci tohoto hodnoticího kritéria bude pro vybraného dodavatele závazný. Zadavatel si je současně vědom skutečnosti, že v průběhu realizace mohou nastat okolnosti, které dodavatel nemůže objektivně ovlivnit, včetně případných prodlení způsobených na straně Zadavatele. Z tohoto důvodu smlouva obsahuje ustanovení, na jehož základě může dodavatel v odůvodněných případech požádat o prodloužení termínu plnění. Takový požadavek bude posouzen a případně schválen Zadavatelem v souladu se smluvními podmínkami. | NE |  |
| 5.	Otázky k požadované technické kvalifikaci |  |  |  |  |  |
|  | Seznam významných služeb |  |  |  |  |
|  | Obecné požadavky na seznam služeb  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Předmět plnění referenční služby | NE |  |  |  |
|  |  | Doporučujeme více specifikovat požadavky na finální podobu dodaného řešení. Např. HA, horizontální škálování, případně provozní prostředí cloud/on-premise.  | Zadavatel tyto striktní kritéria neuplatní, aby byla nedošlo k neúměrnému omezení hospodářské soutěže a potenciálně diskriminačnímu nastavení kvalifikačních podmínek. | NE |  |
|  |  |  |  |  |  |
|  | Požadavek na ISVS | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Služba na dodávku aplikace / IS | NE |  |  |  |
|  |  | Doporučujeme zvýšení částky na min. 10mil. Kč v posledních 5ti letech.  | Zadavatel se rozhodl neuplatnit striktnější kritéria, aby nedošlo k neúměrnému omezení hospodářské soutěže a potenciálně diskriminačnímu nastavení kvalifikačních podmínek. | NE |  |
|  |  |  |  |  |  |
|  | Služba na provoz aplikace / IS | NE |  |  |  |
|  |  | Doporučujeme zvýšení částky na min. 10mil. Kč v posledních 5ti letech. | Zadavatel se rozhodl neuplatnit striktnější kritéria, aby nedošlo k neúměrnému omezení hospodářské soutěže a potenciálně diskriminačnímu nastavení kvalifikačních podmínek. | NE |  |
|  |  |  |  |  |  |
|  | Seznam členů realizačního týmu a jejich kvalifikace |  |  |  |  |
|  | (1) Obecné požadavky na realizační tým | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (2) Minimálně jedna (1) osoba v kategorii role Solution Architekt splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (3)Minimálně jedna (1) osoba v kategorii role Aplikační architekt splňující následující požadavky:  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (4) Minimálně jedna (1) osoba v kategorii role Projektový manažer splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (5) Minimálně dvě (2) osoby v kategorii role Analytik IT senior splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (6) Minimálně pět (5) osob v kategorii role Vývojář splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (7) Minimálně jedna (1) osoba v kategorii role Tester splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (8) Minimálně jedna (1) osoba v kategorii role Bezpečnostní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (9) Minimálně jedna (1) osoba v kategorii role Manažer provozu splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (10) Minimálně dvě (2) osoby v kategorii role Provozní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (11) Minimálně jedna (1) osoba v kategorii role Specialista uživatelské podpory splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (12) Minimálně jedna (1) osoba v kategorii role SCRUM master splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
| 6.	Otázky ke kritériím hodnocení |  |  |  |  |  |
|  | Celková nabídková cena: 30 % | NE |  |  |  |
|  |  | Sumarizace nákladů na pokrytí požadovaných služeb včetně rozvoje a podpory řešení neodpovídá maximální nabídkové ceně. Především 2760MD pro výkonové plnění je problematické a zásadně zdražuje celý projekt. Následná cena za 1MD blended se tímto dostává do nerealizovatelných úrovní ve srovná se současným trhem.  | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. | ANO | Úprava podmínek uvedených v Zadávací dokumentaci. |
|  | Návrh vybraných částí řešení: 30 % | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Prokázání odborných znalostí: 30 % | NE |  |  |  |
|  |  | Ověřování znalostí principů eGovernmentu pro účely hodnocení nabídek je z našeho pohledu zbytečné, příliš selektivní pro zachování regulérnosti veřejné soutěže a nepřináší projektu téměř žádnou přidanou hodnotu.  | Zadavatel s připomínkou nesouhlasí. Znalost principů eGovernmentu považuje za zásadní předpoklad úspěšné realizace informačního systému veřejné správy. Navrhované řešení musí být v souladu s principy eGovernmentu, požadavky Národního architektonického rámce a musí umožňovat využívání sdílených služeb veřejné správy, včetně základních registrů a dalších sdílených komponent eGovernmentu. Ověření znalostí této problematiky proto zadavatel nepovažuje za nadbytečné. | NE |  |
|  | Urychlení vývoje a dodání vybraných modulů: 10 % | NIC |  |  |  |
|  |  |  |  |  |  |
| 7.	Další otázky zadavatele |  |  |  |  |  |
|  | Předpokládaná hodnota zakázky | NE |  |  |  |
|  |  | Po prostudování technických, funkčních i nefunkčních požadavků, doplňkových služeb služeb provozu a rozvoje vnímáme navrhovanou maximální cenu jako nedostatečnou a navrhujeme její navýšení. Po sečtení požadavků na vývoj, podporu a rozvoj s přihlédnutím k obvyklým cenám ICT prací dle zveřejněného benchmarku MVČR není uvažovaný scope v navrhované ceně realizovatelný.  | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. | ANO | Úprava podmínek uvedených v Zadávací dokumentaci. |
|  | Limity pro nabídkovou cenu | NE |  |  |  |
|  |  | Maximální cena 49 844 000Kč není dostatečná pro pokrytí nákladů na vývoj, rozvoj a podporu provozu. Jako dodavatel dále nechápeme požadavek na 2760MD rozvoje ve 4 letech, jelikož se tento rozsah blíží nákladům na realizaci celého nového díla.  | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. Limit pro výši nabídkové ceny byl na základě PTK zrušen, nabídková cena tedy může přesáhnout předpokládanou hodnotu VZ. | ANO | Úprava podmínek uvedených v Zadávací dokumentaci. |
|  | Platební podmínky | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Bankovní záruka | NE |  |  |  |
|  |  | Doporučujeme upřesnit, zda bankovní záruka bude uvolněna po ukončení výroby/implementace. V opačném případě bude zdražovat realizaci přenesením nákladů na Zadavatele.  | Záměrem zadavatele je požadovat bankovní záruku po celou dobu účinnosti smlouvy, proto zadavatel ponechá příslušná ustanovení zadávací dokumentace a smlouvy v původním znění. | NE |  |
|  | Lhůta pro podání nabídek | NE |  |  |  |
|  |  | Doporučujeme navýšit na 60dní.  | Zadavatel s ohledem na běžně používané lhůty již přistoupil k prodloužení lhůty pro podání nabídek z 30 na 45 dnů. Současně zadavatel realizoval předběžnou tržní konzultaci, v jejímž rámci měli potenciální dodavatelé možnost se v předstihu seznámit s očekávaným předmětem plnění. Úpravy zadávací dokumentace provedené na základě výsledků předběžné tržní konzultace mají převážně upřesňující a doplňující charakter a nepředstavují podstatnou změnu rozsahu ani charakteru předmětu plnění. S ohledem na výše uvedené skutečnosti zadavatel považuje stanovenou lhůtu pro podání nabídek za dostatečnou a ponechává ji v délce 45 dnů. | NE |  |
|  |  |  |  |  |  |
| Další připomínky mimo formulář |  | Nejsou |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
| Název obchodní společnosti: Dodavatel č. 2 |  |  |  |  |  |
|  |  | Komentář Dodavatele č. 2 | Vysvětlení/Reakce | Dopad do ZD (ANO/NE) | Způsob zapracování |
|  | Otázky k předmětu plnění |  |  |  |  |
|  | Kapitola 1: Stávající stav ICT zajištění agendy VaK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 2: Požadavky na nový systém |  |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Kapitola 2.3. Požadavky na použité technologie a architekturu technologické vrstvy 2. popis nepřesnosti: Text opakovaně odkazuje na „kapitolu 11“ resp. „kapitolu 11.9“ (např. „podklad pro vlastní analýzu... podrobnosti viz 11.9“, „ 3. dopad zjištěné nepřesnosti: nelze jednoznačně dohledat, na kterou konkrétní část specifikace text odkazuje, což zvyšuje riziko nejednotného výkladu rozsahu požadované dokumentace. 4. návrh upřesnění: Doporučujeme opravit/doplnit číslování kapitol  | Text specifikace předmětu veřejné zakázky bude upřesněn a bude provedena kontrola odkazů na jednotlivé kapitoly. | ANO | Vysvětlující text k výstupům Detailní implementační analýzy je nyní uveden jako podkapitola 2.11.2. |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Kapitola 2.7 Požadavky na kapacitu a výkonnost funkčního celku 2. popis nepřesnosti: Text na dvou místech odkazuje na počty uživatelů uvedené v „tabulkách 5-7“ resp. „tabulce 5“, avšak příslušné tabulky jsou v dokumentu ve skutečnosti očíslovány jako „Tabulka 1“ (VAK a ETBD), „Tabulka 6“ (SED) a „Tabulka 7“ (Jmenný rejstřík) – číslo „5“ pro tabulku VAK/ETBD v dokumentu není použito. 3. dopad zjištěné nepřesnosti: Nesoulad číslování tabulek může vést k záměně, ke které tabulce se požadavek na kapacitu/zátěžové testování skutečně vztahuje. 4. návrh upřesnění: Doporučujeme opravit číslo tabulky 1 na tabulku 5 | Text specifikace předmětu veřejné zakázky bude upřesněn a číslování odkazů na tabulky opraveno. | ANO | Prevedena oprava označení tabulky v kapitole 2.7. |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Kapitola 2.5 Uživatelé a jejich role 2. popis nepřesnosti: V textu specifikace jsou použity Zkratky „CAAIS“ a „PKCE“, ale v úvodním seznamu „Použité termíny a zkratky“ chybí. 3. dopad zjištěné nepřesnosti: Chybějící definice zkratek v úvodním přehledu ztěžuje orientaci čtenáři, který se s pojmy CAAIS/PKCE nesetkal, a snižuje formální úplnost dokumentu. 4. návrh upřesnění: Doporučujeme doplnit zkratky CAAIS a PKCE (včetně stručného vysvětlení) do úvodního seznamu použitých termínů a zkratek. | Text specifikace předmětu veřejné zakázky bude upřesněn a tabulka pojmů doplněna o tyto zkratky. | ANO | Termín CAAIS byl doplněn do přehledu termínů a zkratek. Termín PKCE je vysvětlen v textu v místě výskytu. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitola 2.14 Předání funkčního celku 2. stávající formulace: Ukončení jakéhokoliv Milníku či Fáze 4 je podmíněno úspěšným akceptováním výstupů příslušného Milníku či Fáze, které konstatuje, že předávané výstupy neobsahují vady kategorie A a B 3. návrh nového znění: Ukončení jakéhokoliv Milníku či Fáze 4 je podmíněno úspěšným akceptováním výstupů příslušného Milníku či Fáze, které konstatuje, že předávané výstupy neobsahují vady kategorie A a je identifikováno nanejvýš 5 chyb kategorie B. 4. potvrzení vazby na cíl a účel: Je vhodné mít v akceptačních kritériích nenulový počet vad kategorie B z důvodu, aby chyby, které sice omezují běžný provoz, ale nepřevyšují svým dopadem dopad odložení nasazení systému do produkce, mohly být vyřešeny až v rámci provozu po akceptaci s výhradou. Cíl a účel zadání se tím nemění. 5. popis zjednodušení: Úprava umožňuje zadavateli předat do provozu systém flexibilněji a na základě dohody s dodavatelem řešit prioritu vad. 6. dopad navrhované úpravy: Zjednodušení nasazení systému do produkce a zvýšení pravděpodobnosti dodržení harmonogramu. | Zadavatel nepovažuje za účelné přebírat do provozu dílo, které má chyby kategorie A nebo B, proto ponechá ustanovení týkající se finální akceptace beze změny. | NE |  |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitola 2.4 Integrace systému (AgriBus, integrační rámec). 2. stávající formulace: Integrace probíhají přes AgriBus, jsou vyjmenovány napojené systémy (SEPO, ZR, SED, Jmenný rejstřík, AgriGIS) a je umožněn návrh alternativ v implementační analýze. 3. návrh nového znění: Doplnit pododdíl „Jednotná datová páteř ISVaK–DTM–PRVK/GIS“, který závazně stanoví: • referenční identifikátory pro průřezovou evidenci: IČME (majetek), IČPE (provozní celky), IDVD (vodní díla), ID karty PRVAK (obec/část/soustava) jako povinné pole všech API a exportů; • procesy a periodicitu synchronizace (min. roční + ad hoc při změně), verzování a audit dat napříč komponentami přes AgriBus; • povinné uchování vazeb na zdroj (ID prvku DTM, datum/verze datové sady) u prostorově vázaných objektů. 4. potvrzení vazby na cíl a účel: Úprava nemění cíl centralizovat administraci a odstranit souborové přenosy; zpřesňuje integrace tak, aby ISVaK plnil roli referenční evidence pro PRVAK a DTM/GIS. 5. popis zjednodušení: Jednoznačné ID a verzování sníží integrační ambiguitu, zlepší dohledatelnost a omezí manuální slaďování. 6. dopad navrhované úpravy: Nepožaduje změnu architektury, jde o upřesnění rozhraní a SLA; malé navýšení prací v analýze a integrační vrstvě. | Integrace mezi Digitální technickou mapou (DTM) a systémy MZe bude realizována prostřednictvím systému AgriGIS. Není proto účelné ani potřebné podrobně specifikovat tuto část integrace v rámci veřejné zakázky na IS VaK. Zadavatel současně považuje používání jednoznačných identifikátorů v integračních rozhraních za standardní součást návrhu řešení. Konkrétní rozsah a způsob využití identifikátorů bude vycházet z datových struktur a identifikátorů vedených v příslušných zdrojových systémech, zejména v DTM (např. IČME). Zadavatel nepovažuje za nutné závazně stanovovat navrhované procesy synchronizace, verzování a auditních vazeb mezi DTM a ostatními systémy, neboť tyto oblasti budou řešeny v rámci navrhované integrační architektury jednotlivých systémů a nejsou předmětem plnění IS VaK. Integrace na DTM zajišťuje systém AgriGIS. | NE |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. Identifikace části zadání: Kapitola 2.16 „Integrace se systémem AgriGIS" — požadavek na mechanismus předání kontextu a autorizace dat mezi Funkčním celkem a mapovou aplikací. 2. Popis nepřesnosti: Zadávací dokumentace stanovuje, že „v opačném směru musí být umožněno, aby mapová aplikace ověřila oprávnění uživatele a získala seznam agendových prvků, ke kterým má daný uživatel přístup" prostřednictvím „služby vystavené systémem, která na základě identity uživatele vrátí odpovídající množinu dat". Zadání však nespecifikuje, jakým způsobem bude tato služba autentizovat identitu uživatele přicházejícího z mapové aplikace. Rovněž není jasné, zda musí být tato služba vystavena přes ESB AgriBus, nebo přímo. 3. Dopad zjištěné nepřesnosti: Architektonické rozhodnutí o způsobu autentizace identity v tomto integračním bodě ovlivňuje návrh bezpečnostní architektury, rozsah analytické fáze (Fáze 2) i celkový odhad pracnosti. Různí dodavatelé mohou navrhnout nekompatibilní řešení, která splňují literu zadání, ale nikoliv záměr zadavatele. To ohrožuje porovnatelnost nabídek. 4. Návrh upřesnění: Zadavatel doplní do zadávací dokumentace popis stávajícího integračního vzoru, který je používán u jiných agendových systémů MZE pro předávání identity do AgriGIS. Pokud takový vzor dosud neexistuje, doporučujeme tuto skutečnost v zadání explicitně uvést a nechat na dodavateli návrh schválený Objednatelem v rámci implementační analýzy. | Zadavatel v tomto bodě upřesní, že předmětná integrace nebude realizována prostřednictvím ESB AgriBus. Komunikace mezi Funkčním celkem a systémem AgriGIS bude řešena prostřednictvím aplikačního rozhraní (API). Konkrétní způsob předávání identity uživatele a autorizace přístupu k datům není v této fázi stanoven. Jeho návrh bude součástí implementační analýzy dodavatele a musí respektovat bezpečnostní a architektonické požadavky objednatele. Navržené řešení bude podléhat schválení objednatele. | NE |  |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kap. 2.16 Integrace se systémem AgriGIS. 2. stávající formulace: AgriGIS je popsán jako vizualizační integrace s předáním kontextu z EVI do mapové aplikace a opačným ověřením oprávnění pro zobrazení. 3. návrh nového znění: Rozšířit na obousměrnou integraci s DTM/GIS: • povinný zápis a údržba vazeb EVI ↔ DTM (ID geo-prvku, verze vrstvy) u všech prostorových objektů; • služba pro „spatial reconcile“: při změně geometrie v DTM/AgriGIS založí (nebo označí) změnu v EVI a PRVAK kartě; • exportní API musí vždy uvádět identifikátory (IČME/IČPE/IDVD/ID karty) + metadata verze GIS/DTM. 4. potvrzení vazby na cíl a účel: Cíl zůstává, integrace s AgriGIS je již vyžadována; doplnění z ní dělá datovou (nejen mapovou) vazbu. 5. popis zjednodušení: Minimalizuje rozpad dat mezi ISVaK, PRVAK a DTM a zrychlí aktualizace. 6. dopad navrhované úpravy: Bez zásahu do základní architektury; rozšíření API, mapové služby a metadat. | Zadavatel v rámci požadované integrace se systémem AgriGIS nepředpokládá realizaci editací ani správu dat v Digitální technické mapě (DTM). Systém AgriGIS je v tomto případě konzumentem prostorových dat a ani jeho prostřednictvím nebude prováděna editace dat vedených v DTM. Požadovaná integrace je zamýšlena především pro účely zobrazení a využití prostorového kontextu dat evidovaných ve Funkčním celku. Zadavatel proto nepožaduje implementaci mechanismů pro synchronizaci změn do DTM, správu verzí prostorových objektů ani obousměrnou datovou integraci v navrhovaném rozsahu. Předávání identifikátorů objektů prostřednictvím integračních rozhraní zadavatel považuje za standardní součást návrhu integračního řešení. Detailní návrh struktury rozhraní a předávaných dat bude předmětem implementační analýzy a následné součinnosti mezi dodavatelem IS VaK a dodavatelem systému AgriGIS. | NE |  |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. Identifikace části zadání: Kapitola 2.16 „Integrace se systémem AgriGIS". 2. Stávající formulace: „Předání kontextu bude realizováno prostřednictvím parametrizovaného volání mapové aplikace (např. URL parametrů nebo lehkého API), přičemž systém poskytne identifikátory nebo filtrační kritéria pro zobrazení dat." 3. Návrh nového znění: Doporučujeme doplnit: „Zadavatel poskytne vítěznému dodavateli po podpisu smlouvy popis technického rozhraní AgriGIS relevantního pro tento integrační bod, včetně dokumentace způsobu autentizace identity uživatele a struktury filtračních parametrů. Dodavatel na základě těchto podkladů navrhne konkrétní implementaci v rámci implementační analýzy; návrh podléhá schválení Objednatele." 4. Potvrzení vazby na cíl a účel: Navrhovaná úprava nemění cíl — konzistentní řízení přístupu mezi Funkčním celkem a mapovou aplikací. Pouze explicitně přesouvá zodpovědnost za definici integračního vzoru na stranu, která má přístup ke stávající architektuře AgriGIS. 5. Popis zjednodušení: Dodavatel nebude muset spekulovat o interním fungování AgriGIS a navrhovat řešení „do prázdna". Snižuje se riziko odmítnutí architektonického návrhu v implementační analýze. 6. Dopad navrhované úpravy: Žádný dopad na harmonogram ani cenu, pokud jsou podklady předány v rámci NDA materiálů po podpisu smlouvy (jak je v zadání již předvídáno). Pozitivní dopad na kvalitu architektonického návrhu a na porovnatelnost nabídek. | Zadavatel upřesní specifikaci integračního rozhraní se systémem AgriGIS, zejména ve vztahu k odpovědnosti za návrh a implementaci integračního řešení. Zadavatel poskytne dodavateli v průběhu realizační fáze dostupné podklady nezbytné pro návrh integrace. Současně však upozorňuje, že technické možnosti integračního řešení jsou do značné míry dány technologickou platformou ESRI ArcGIS Enterprise a funkcionalitami poskytovanými systémem AgriGIS. Konkrétní návrh způsobu předávání kontextu, identity uživatele a využití dostupných integračních mechanismů bude součástí implementační analýzy dodavatele a bude podléhat schválení objednatele. | ANO | Do kapitoly 2.16 byl doplněn odkaz na dokumentaci produktu. |
|  |  |  |  |  |  |
|  | Kapitola 3: Základní požadavky na funkční celek |  |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Kapitola 3.5 Chyby v datech a práce s nimi“ – pravidla pro chybu kategorie 4 (Odchylka). 2. popis nepřesnosti: Specifikace uvádí, že chybu kategorie 4 (Odchylka) nebude možné zneaktivnit, ale nevysvětluje důvod tohoto omezení. 3. dopad zjištěné nepřesnosti: Chybějící odůvodnění může vést k uživatelským dotazům a nejasnostem při akceptačním testování. 4. návrh upřesnění: Doporučujeme doplnit do specifikace stručné odůvodnění, proč nelze chybu kategorie 4 (Odchylka) zneaktivnit/skrýt, případně zvážit umožnění uživatelského skrytí neblokující odchylky bez vlivu na hodnocení bezchybnosti záznamu. | Ze Zadávací dokumentace vyplývá, že Chyba kategorie 4 je jen odchylka a nemá vliv na blokaci nebo označení záznamu "s chybou". Z tohoto důvodu není potřeba ji zneaktivňovat. | NE |  |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitola 3.11 Správa číselníků (hierarchie, kaskády). 2. stávající formulace: Evidence hierarchických číselníků KÚ–ORP, vazby a kaskádové doplňování údajů; možnost aktualizací z jiných systémů, verzování a audit číselníků. 3. návrh nového znění: Doplnit závazný „Model hierarchie soustav“ (obecní/skupinové/regionální soustavy) a jeho uplatnění napříč moduly (MP, VS, PP, PR VAK) včetně kaskádových agregací; uložit povinnost kaskádových kontrol (blokace u porušení hierarchie) a synchronizovaných číselníků sdílených s PRVAK a DTM (např. karty soustav, aglomerace). 4. potvrzení vazby na cíl a účel: Zpřesnění číselníků podporuje stávající kontrolní logiku a sjednocené UI; cíl se nemění. 5. popis zjednodušení: Vynutí konzistenci napříč moduly a eliminuje duplicitní lokální „pravdy“. 6. dopad navrhované úpravy: Úprava definic číselníků a validací; bez změny architektury. | Požadavky na shlukování a hierarchii vychází z fungování stávající aplikace IS VAK. Zadavatel v zadávací dokumentaci požaduje zachování funkcionality stávajícího modulu PR VAK. S ohledem na tato fakta nepovažujeme za nutné stanovovat "závazný model hierarchie". Dodavatel může v rámci implementační analýzy doplnit požadovanou funkcionalitu o vylepšení a rozšíření, tato podléhají schválení Zadavatele. | NE |  |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitola 3.4 Spouštění datových kontrol (kvalita dat a reporting). 2. stávající formulace: Definovány formální/validační/kombinované kontroly, ukládání do „Protokolu chyb“ a jejich spouštění i přes API. 3. návrh nového znění: Doplnit kategorie „mezi-systémových kontrol“ konzistence (ISVaK–PRVAK–DTM) a povinný kvartální reporting KPI kvality dat (úplnost ID, vazby na DTM, chybovost) do rolí MZE/KÚ; zavést centrální číselník přeshraničních kontrol a SLA na jejich běh. 4. potvrzení vazby na cíl a účel: Kontrolní rámec už je součástí zadání; rozšíření posiluje datovou kvalitu bez změny účelu. 5. popis zjednodušení: Pravidelný přehled kvality dat umožní řídit nápravu a zkrátí řešení incidentů. 6. dopad navrhované úpravy: Rozšíření kontrol a dashboardů; bez dopadu na architekturu | Zadavatel neidentifikuje tento požadavek na funkcionalitu Funkčního celku. | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 4: Požadavky na agendovou komponentu – modul MP VAK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Kapitola 4.6 „Požadavky na proces“ popis stavů hlášení a pravidel pro editaci záznamu. 2. popis nepřesnosti: Specifikace životního cyklu hlášení MP VAK vyjmenovává stavy Přijaté → Ve zpracování → Zpracované (a Zrušené / Zneplatněné / Vráceno k doplnění); stav „Převzaté“ mezi nimi není. Text ale dále uvádí, že editaci může uživatel spustit „ve stavu Převzaté“ — tento stav v životním cyklu MP VAK neexistuje (na rozdíl od VS VAK, kde existuje). 3. dopad zjištěné nepřesnosti: Odkaz na neexistující stav je nejednoznačný a ztěžuje jednoznačnou implementaci pravidel pro editaci. 4. návrh upřesnění: Doporučujeme opravit/upřesnit, ve kterém z reálně existujících stavů životního cyklu MP VAK (pravděpodobně „Ve zpracování“) je editace záznamu skutečně povolena. | Zadavatel upraví zadavací dokumentaci v navrženém smyslu. V rámci zpracování dokumentace došlo k přejmenování a stav "Převzaté" je nyní označován "Ve zpracování". Z funkčního hlediska jsou oba stavy identické. | ANO | Došlo ke sjednocení označení stavů, v kapitole zaměřené na modul VS VAK a MP VAK. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitoly 4.3 (MP VAK integrace); 6.2 (PP VAK integrace); 7.3 (PR VAK integrace). 2. stávající formulace: Napojení na SEPO/SED/Jmenný rejstřík; v MP VAK generování IČME ID pro FO; v PR VAK obecné vazby na SED. 3. návrh nového znění: Stanovit povinnost uvádět a validovat IČME/IČPE/IDVD/ID karty PRVAK ve všech integračních výměnách (SEPO/SED/AgriBus) a exportech; chybějící nebo nevalidní identifikátor = blokační chyba při příjmu dat; doplnit povinné mapování na DTM (ID geo prvku + verze) pro prostorové agendy. Doplnit datový model o geoprostorové informace a topologii 4. potvrzení vazby na cíl a účel: Nemění účel modulů, posiluje jednoznačnost a dohledatelnost napříč systémy. 5. popis zjednodušení: Méně kolizí při párování záznamů a rychlejší automatizované kontroly. 6. dopad navrhované úpravy: Úpravy schémat API a validátorů; bez změny architektury. | Zadavatel doplní zadávací dokumentaci v navrženém smyslu a specifikuje požadavek na kontrolu identifikačních atributů prvků ve vzájemné komunikaci. | ANO | Text zaměřený na požadavek kontroly a validace identifikátorů byl vložen do kapitoly 2.4. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitola 4 (modul MP VAK) — požadavky na shodu s funkcionalitou stávající aplikace (ř. 1200, 1231, 1240, 1538, 1548, 1552); v návaznosti Kap. 7 (modul PR VAK, ř. 2389), kde je požadavek na kopírování stávajícího rozhraní explicitně rozšířen i na MP VAK a VS VAK. 2. stávající formulace: Zadání na několika místech modulu MP VAK stanovuje, že rozhraní, funkčnost a v jednom případě i výpočetní logika a pojmenování mají vycházet ze stávající aplikace IS VaK (např.: "Objednatel požaduje realizovat funkcionalitu v rozsahu a v souladu (tj. pojmenování, způsob výpočtu, umístění atd.) s funkcionalitou stávající aplikace"; "Rozhraní a funkčnost této stránky bude vycházet z rozložení grafického rozhraní stávající aplikace MP VAK"). V modulu PR VAK zadání dále přímo požaduje, aby zobrazení "kopírovalo" stávající kompaktní rozhraní, a to obdobně i pro MP VAK a VS VAK. 3. návrh nového znění: Doporučujeme Objednateli zvážit přeformulování těchto požadavků z vázání na konkrétní vzhled/pojmenování/umístění stávající aplikace na vázání na zachování funkčního obsahu a rozsahu (tj. jaké informace, výpočty a operace musí být uživateli k dispozici), bez závazného požadavku na kopírování konkrétního grafického rozhraní nebo přesného pojmenování legacy aplikace. Konkrétně navrhujeme u těchto bodů doplnit formulaci umožňující dodavateli navrhnout modernizované/zjednodušené rozhraní 4. potvrzení vazby na cíl a účel: Cíl zadání — zajistit uživatelům MP VAK a PR VAK plnohodnotnou náhradu stávající funkcionality bez ztráty informací nebo pracovních postupů — se nemění. Návrh pouze odděluje požadavek na funkční/obsahovou kontinuitu od požadavku na vizuální/pojmenovací kopii konkrétní legacy aplikace. 5. popis zjednodušení: Umožní dodavateli navrhnout jednotné, moderní a konzistentní uživatelské rozhraní napříč agendovými moduly Funkčního celku (MP VAK, PR VAK, VS VAK, PP VAK), místo replikace čtyř historicky oddělených a vzájemně odlišných rozhraní stávajících aplikací. Snižuje riziko přenesení zastaralých UX vzorů do nového řešení a zjednodušuje školení uživatelů, kteří budou pracovat s jedním konzistentním rozhraním. 6. dopad navrhované úpravy: Bez dopadu na rozsah požadované funkčnosti. Může mít pozitivní dopad na cenu a harmonogram implementace (menší vázanost na analýzu a replikaci specifik čtyř legacy rozhraní) a na budoucí udržitelnost řešení | Dodavatel je oprávněn v rámci předložení grafického návrhu navrhnout vlastní úpravy či vylepšení řešení. Takové návrhy však vždy podléhají předchozímu schválení Objednatele. Pokud Dodavatel předloží návrh, který se odchyluje od požadavků stanovených Zadávací dokumentací, a Objednatel takový návrh neschválí, nelze předložení takového návrhu považovat za splnění povinnosti Dodavatele na předložení návrhu řešení v souladu se zadáním. Za splnění této povinnosti lze považovat pouze návrh odpovídající požadavkům Zadávací dokumentace, případně návrh odchylující se od zadání, který byl Objednatelem výslovně schválen. | ANO | Text explicitně upravující možnost Dodavatele navrhovat vlastní řešení uživatelského rozhraní byl doplněn do kapitoly 2.11.3, která se zabývá výstupy analytické fáze projektu. |
|  |  |  |  |  |  |
|  | Kapitola 5: Požadavky na agendovou komponentu – modul VS VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 6: Požadavky na agendovou komponentu – modul PP VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 7: Požadavky na agendovou komponentu – modul PR VAK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. Identifikace části zadání: Kapitola 7.2 „Požadavky na zpracování dat" — výpočet průniku majetku s hranicemi obcí ve spolupráci se systémem AgriGIS. 2. Popis nepřesnosti: Zadávací dokumentace uvádí, že systém „provede nápočet průniku majetku s danými částmi obce" a že tuto funkcionalitu zajistí „ve spolupráci se systémem AgriGIS", přičemž výsledkem je „součet hodnot reprodukční pořizovací ceny majetků evidovaných průnikem fyzického výskytu infrastrukturních prvků s vymezenými hranicemi obcí a částí obcí". Fyzický výskyt infrastrukturního prvku na území obce (tj. přítomnost jakéhokoli bodu geometrie prvku v hranici obce) je jako princip srozumitelný. Zadání však nespecifikuje, která ze dvou komponent — Funkční celek, nebo AgriGIS — má prostorový průnik fakticky vyhodnotit, ani jakým způsobem budou výsledky průniku předány do Funkčního celku pro následný výpočet reprodukční pořizovací ceny. 3. Dopad zjištěné nepřesnosti: Prostorový průnik polygonů (hranice obcí/částí obcí) s geometriemi infrastrukturních prvků je ze své podstaty GIS operace, pro jejíž spolehlivé a výkonné vyhodnocení je přirozeným nástrojem geografický informační systém. MZe přitom již provozuje platformu AgriGIS (ArcGIS Enterprise), která disponuje nativní podporou prostorových analýz tohoto typu. Pokud by tuto operaci měl provádět Funkční celek vlastními prostředky (tj. mimo GIS), znamenalo by to nutnost implementovat prostorový výpočetní engine, spravovat aktuální vrstvu hranic obcí/částí obcí a zajistit jejich synchronizaci se RÚIAN — a to vše duplicitně vedle existující GIS infrastruktury MZe. Nejasnost v rozdělení zodpovědností tak přímo ovlivňuje architektonický návrh, odhad pracnosti i provozní model. 4. Návrh upřesnění: Zadavatel doplní, zda vyhodnocení prostorového průniku infrastrukturních prvků s hranicemi obcí a částí obcí bude v gesci systému AgriGIS (který k tomu má nativní prostorové analytické nástroje a přístup k referenčním geodatům), nebo Funkčního celku. Pokud bude tato operace svěřena AgriGIS, zadavatel upřesní: (a) způsob a frekvenci předání výsledků průniku do Funkčního celku (synchronní API / asynchronní batch), (b) strukturu a formát předávaných dat, (c) referenční vrstvu hranic obcí a částí obcí, která bude pro průnik použita (RÚIAN, případně jiný zdroj spravovaný v AgriGIS). Využití stávající GIS infrastruktury MZe pro tento účel se jeví jako přirozené a provozně efektivní řešení, které zamezí duplicitní implementaci prostorových výpočtů mimo GIS platformu. | Zadavatel upřesní dokumentaci v tom smyslu, aby bylo zřejmé, že systém AgriGIS pouze vyhodnotí prostorový průnik a zapíše výsledek do databáze. Hodnocení a výpočet reprodukční požizovací ceny nebo jiných statistických údajů je na agendovém informačním systému. | ANO | Text byl doplněn do podkapitoly 7.2. |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. Identifikace části zadání: Kapitola 7.2 „Požadavky na zpracování dat" — integrace s DTM krajů prostřednictvím atributu IČME 2. Popis nepřesnosti: Zadání předpokládá napojení IS VaK na DTM krajů, aniž by zohledňovalo skutečnou dvouvrstvou architekturu systému. IS DMVS provozovaný ČÚZK funguje jako centrální agregační brána nad všemi 14 krajskými IS DTM a poskytuje jednotné rozhraní (R19–R29), prostřednictvím kterého lze pokrýt území všech krajů jediným napojením. 3. Popis dopadu: Nejednoznačnost formulace může vést k podhodnocení nebo nadhodnocení rozsahu díla, nejasné architektuře řešení a neurčené odpovědnosti za správu přístupových oprávnění. 4. Návrh upřesnění: zadavatel by měl zvážit, zda napojení na centrální prvek systému IS DMVS nepostačuje a zda tedy přímá integrace na 14 krajských API je nebo není technicky nutná. | Zadavatel z části nesouhlasí s uvedeným tvrzením. Není požadováno napojení komponenty VAK na DTM/DMVS. Na DTM bude napojen systém AgriGIS. Zadavatel ovšem provede úpravu textu v tom smyslu, aby bylo zřejmé, že data budou konzumována z DMVS nikoliv z jednotlivých DTM krajů. | ANO | V textu byla provedena změna z označení DTM na DMVS v podkapitole 7.2. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. Identifikace části zadání: Kapitola 7.10 Statistické sestavy a přehledy. 2. Stávající formulace: „Rozsah a ergonomie poskytování statistických sestav a přehledů bude vycházet ze stávajících verzí modulu PR VAK. Kromě toho nově bude modul poskytovat statistické údaje o investičních nákladech v jednotlivých územních nebo jiných celcích." 3. Návrh nového znění: Doporučujeme doplnit: „Statistické výstupy na úrovni územních celků (ORP, kraj, povodí, ČR) budou exportovatelné ve strukturovaném formátu (minimálně XLSX, CSV) obsahujícím jednoznačné identifikátory územních celků (kód ORP, kód kraje dle RÚIAN) umožňující jednoznačné geografické přiřazení při zpracování v navazujících analytických nebo mapových nástrojích." Zároveň doporučujeme vyjasnit, zda výstupy PR VAK budou předávány do externích analytických nástrojů (benchmarking SOVAK, roční zprávy MZe) a v jakém formátu tyto nástroje data přijímají. 4. Potvrzení vazby na cíl a účel: Navrhovaná úprava nijak nemění věcný záměr zadavatele — poskytovat statistiku investičních nákladů po územních celcích. Pouze explicitně definuje výstupní formát tak, aby exportovaná data byla bez dalšího zpracování použitelná v navazujících analýzách. 5. Popis zjednodušení: Zabrání se situaci, kdy exportovaná data obsahují pouze textové názvy obcí/ORP (které jsou náchylné na překlepy a změny) místo standardizovaných číselných kódů z RÚIAN. Snižuje se pracnost zpracování na straně analytických nástrojů. 6. Dopad navrhované úpravy: Minimální dopad na implementaci (přidání atributů kódů RÚIAN do exportního modulu). Pozitivní dopad na datovou kvalitu a interoperabilitu výstupů. | Zadavatel provede upřesnění v tom smyslu, že zvýrazní požadavek na možnost exportu součtových údajů. | ANO | Text byl doplněn do podkapitoly 7.10. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitola 7.2 Požadavky na zpracování dat; 7.1/7.11 Karty a agregace. 2. stávající formulace: Součty přes hierarchii správního členění, průniky s AgriGIS a požadavek na propojení s DTM přes IČME (stávající i návrhové stavy). 3. návrh nového znění: Uložit povinnost evidovat u každé Karty PRVAK odkaz na příslušné DTM prvky a jejich verzi; definovat „propagační pravidla“: změna prvku v PRVAK/DTM vyvolá přenesení změny do ISVaK (nebo založení úlohy pro verifikaci); doplnit „ID karty soustavy“ a model nadobecních soustav (vazby a agregace) jako závazný číselník. Doplnit datový model geoprostorové informace, plánovaní s využitím topologie a prostorových dotazů/analýz. 4. potvrzení vazby na cíl a účel: PR VAK už počítá s agregacemi a vazbou na DTM/AgriGIS; doplnění je zpřesňuje. 5. popis zjednodušení: Automatizované sčítání a aktualizace bez ručního přepisu, vyšší konzistence. 6. dopad navrhované úpravy: Rozšíření datového modelu karet a integrací; bez změny architektury. | Údržba proměnlivých údajů uvedených v DMVS v rámci IS VAK se nezdá jako vhodný architektonický vzor. IS VAK bude skrze AgriGIS využívat aktuální data DMVS. Prvky v DMVS budou mít v sobě uvedený identifikátor IČME, přes který bude možné data párovat s údaji IS VAK. Jednotlivé části obce budou mít, na základě prostorového průniku realizovánu vazbu s infrastrukturním majetkem, tento nápočet zajistí systém AgriGIS a není součástí realizace veřejné zakázky, která byla předmětem PTK. Zadavatel provede doplní zadávací dokumentace v tom smyslu, že u jednotlivých evidovaných jednotek v rámci modulu PR VAK (tj. část obce, městská část, obec) budou uvedeny identifikátory IČME, které se tam vyskytují. | ANO | Text byl doplněn do podkapitoly 7.10. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle 1. identifikace části zadání: Kapitola 7 (modul PR VAK) a Kap. 8 (ETBD), v návaznosti na Kap. 2, sekce „Integrace se systémem AgriGIS". 2. stávající formulace: Zadání u PR VAK stanovuje funkční spolupráci s AgriGIS (nápočet průniku majetku, propojení s DTM) a u ETBD integraci s AgriGIS (ArcGIS Enterprise) pro automatické předvyplnění geografických atributů a mapové okno. Zadání ale u žádného z modulů nestanovuje, že by měly být přímo implementovány nad platformou ArcGIS Enterprise, na které AgriGIS již dnes běží. 3. návrh nového znění: Doporučujeme výslovně stanovit, že moduly PR VAK a ETBD budou implementovány nad platformou ArcGIS Enterprise (ESRI), tedy nad stejnou platformou, na které běží AgriGIS. Důvodem je jejich funkční závislost na prostorových datech (u PR VAK nápočet průniku majetku a vazba na DTM, u ETBD automatické doplnění geoatributů a mapové okno) a skutečnost, že nad platformou ArcGIS je provozován také Národní prováděcí plán, využívající obdobné datové modely, mapové služby a integrační mechanismy — využití stejné platformy tak snižuje rizika spojená s jeho provozem, rozvojem a správou a umožňuje zachovat kontinuitu bez nutnosti migrace nebo paralelního vývoje funkcionalit. Doporučujeme Objednateli zvážit obdobný přístup i u dalších modulů s prostorovým rozměrem, včetně MP VAK. 4. potvrzení vazby na cíl a účel: Cíl modulů PR VAK a ETBD nemění; návrh se týká pouze upřesnění technologické platformy, na které jsou realizovány již popsané GIS závislosti. 5. popis zjednodušení: Jednotná platforma pro PR VAK, ETBD, AgriGIS a Národní prováděcí plán odstraňuje potřebu synchronizace dat mezi odlišnými GIS technologiemi a zjednodušuje sdílení datových modelů a mapových služeb. MZe už má licenci k ESRI pro účely NPP, tedy využití ESRI pro IS VaK by nevyžadovalo žádné nové pořízení ze strany MZe. 6. dopad navrhované úpravy: Upřesnění zadání a stanovení technologie ESRI by umožnilo •	Zvýšení kvality řešení – zvýšení komfortu uživatelů při práci s daty •	Zvýšení využitelnosti dat pro reporting a pro sdílení mezi systémy •	Zefektivnění reportingu v rámci UWWTD (směrnice (EU) 2024/3019), která přináší celou řadu nových povinností, které musí ČR postupně splnit •	Pokud by nebyla využitá stejná platforma znamenalo by to implementaci dalších systémů pro integraci, transformaci a správu dat a toho plynoucí navýšení nákladů na naplnění povinností vycházející ze směrnic EU •	Umožnění údržby Národního prováděcího plánu, který je zpracován jako GIS aplikace na platformě ESRI •	Zjednodušení integrace s PRVKÚK – tyto systémy jsou také implementovány často na platformě ESRI •	Možnost integrace NPP jako živého systému, který při správně prováděné aktualizaci dat může poskytovat MZE i celému vodohospodářskému oboru zcela unikátní informace způsobem, který by měl být v 21. století standardem •	Pokud nebude tento systém implementován na stejné platformě jako systémy řešící příbuznou agendu, hrozí v budoucnu jeho rychlé zastarání, nárůst neefektivity a opakování scénáře, že systém je vnímán odbornou veřejností jako nevyhovující a neodpovídající potřebám a stále se zvyšujícím standardům oboru | Zadavatel nesouhlasí s navrženým doporučením. Agendové moduly fungují cca 20 let bez napojení na GIS, a proto nelze říci, že je výkon agendy funkčně závislý na GIS. Zadavatel souhlasí, že propojení s GIS může významně zlepšit uživatelský komfort, a proto se rozhodl pro jeho využití pro vizualizaci dat. | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 8: Požadavky na agendovou komponentu Evidence technicko bezpečnostního dohledu (ETBD) |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Příloha č. 4 – Technická specifikace; modul ETBD, definice role pro veřejné uživatele. 2. popis nepřesnosti: Role přiřazovaná všem veřejným uživatelům se nazývá „Farmář“ — v kontextu agendy technickobezpečnostního dohledu nad vodními díly působí tento název jako nesouvisející s předmětem agendy. 3. dopad zjištěné nepřesnosti: Nevhodně zvolený název role může působit zavádějícím dojmem na uživatele i na Dodavatele při implementaci. 4. návrh upřesnění: Doporučujeme přejmenovat roli veřejného uživatele v modulu ETBD na název odpovídající předmětu agendy (např. „Veřejný uživatel“), při zachování stejné funkce a rozsahu oprávnění. | Bohužel označení vychází z nativního označení základního uživatelského účtu v LDAP/AD a není možné ho zmněnit pro potřeby tohoto projektu. Označené role námá praktický dopad na realizaci a její pracnost. | NE |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. Identifikace části zadání: Kapitola 8.7 „Role a jejich oprávnění" — role Stavební úřad KU a Stavební úřad ORP; podkapitola „Data v agendě ETBD" — zápis výsledků prostorového průniku systémem AgriGIS. 2. Popis nepřesnosti: Zadávací dokumentace uvádí, že přiřazení stavebního úřadu k liniovým vodním dílům bude provedeno na základě „prostorového průniku liniového prvku s geografickou vrstvou působnosti jednotlivých stavebních úřadů" a že „údaje o prostorovém průniku zapíše k datům do databáze systém AgriGIS, tudíž je mimo rámec této realizace. V rámci realizace dojde k dohodě mezi Provozovatelem AgriGIS a Poskytovatelem o nejvhodnější formě a struktuře pro zápis těchto dat." Zadávací dokumentace nezodpovídá tyto otázky: (a) Kdo a kdy iniciuje spuštění prostorového průniku v AgriGIS — Funkční celek (jako API volání), nebo provozovatel AgriGIS (manuálně)? (b) S jakou frekvencí bude prostorový průnik přepočítáván — jednorázově při zaevidování vodního díla, nebo periodicky (např. při změnách správních obvodů)? (c) Jak bude Funkční celek notifikován o výsledcích průniku a jejich aktualizacích? 3. Dopad zjištěné nepřesnosti: Bez zodpovězení těchto otázek nelze navrhnout spolehlivou architekturu rozhraní mezi Funkčním celkem a AgriGIS pro tuto funkcionalitu. Pokud je průnik spouštěn asynchronně (např. jednou denně), musí Funkční celek počítat s tím, že nově zaevidovaná vodní díla dočasně nemají přiřazen stavební úřad — a musí tuto situaci ošetřit v uživatelském rozhraní a v logice přístupu k datům. Nevyjasněnost přímo ovlivňuje implementaci logiky přístupu k datům a odhad pracnosti. 4. Návrh upřesnění: Zadavatel doplní: (a) iniciátor a způsob spuštění prostorového průniku (synchronní API / asynchronní batch / manuální), (b) očekávanou latenci (jak rychle po zaevidování VD bude přiřazení stavebního úřadu dostupné), (c) způsob notifikace Funkčního celku o výsledcích (webhook, polling, sdílená DB tabulka), (d) chování systému v přechodovém stavu bez přiřazení. | Zadavatel na základě přeložených otázek upřesňuje, že: a) spuštění nápočtu nápočet iniciuje komponenta Funkčního celku EVI, která požádá o dopočtení údajů k ukládanému prvku, b) na vyžádání, c) výsledek nápočtu bude součástí doplňovaných atributů a bude možné si jej zkontrolovat, bude evidován processing_status; processing_time a processing_error Upřesnění budou také doplněna do zadávací dokumentace. | ANO | Text byl doplněn do podkapitoly 8.3. |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání (2) 1. Identifikace části zadání: Kapitola 8.5 „Požadavky na uživatelské rozhraní" — automatické doplňování polohopisných údajů na základě souřadnic vodního díla. 2. Popis nepřesnosti: Zadávací dokumentace uvádí: „Vybrané polohopisné údaje budou do systému doplňovány automaticky na základě souřadnic vodního díla — ORP, kraj, územní působnost s.p. Povodí apod. Součástí detailu bude i mapové okno obsahující mapové podklady agendy, po kliknutí do mapy budou odečteny informace o poloze." Zadání nespecifikuje: (a) zda je poloha vodního díla ukládána jako souřadnice bodu, nebo jako geometrie (linie, polygon), (b) kdo odpovídá za správnost a aktualizaci referenčních geodat ORP/kraj/Povodí — zda jsou tato data součástí AgriGIS, nebo je musí Funkční celek udržovat samostatně. 3. Dopad zjištěné nepřesnosti: Tabulka atributů ETBD (příloha zadání) přitom prokazuje, že různé druhy vodních děl vyžadují různé typy geometrie: pro bodová díla (čerpací stanice, jezy, ČOV) jsou evidovány souřadnice jednoho bodu X/Y v S-JTSK; pro liniové stavby (ochranné hráze, přivaděče — druh „H" a „SP") jsou povinné souřadnice počátečního i koncového bodu (atributy vdxpjtsk/vdypjtsk a vdxkjtsk/vdykjtsk); a pro plošná díla (vodní nádrže, suché nádrže — druh „VN", „SN") tabulka atributů sice uvádí jen bod, ale poznámka přímo v tabulce konstatuje, že „bude prezentováno jako bod v mapě podle souřadnic, ale zároveň souřadnice nebude možné vygenerovat v žádném z výstupních formátů (politika ochrany umístění vodárenských nádrží)". Pro nádrže jsou ovšem technicky relevantní parametry jako plocha, objem a kóta, které bodová reprezentace nepodporuje dostatečně. Bez jednoznačné definice geometrického modelu pro každý druh VD nelze správně implementovat algoritmus prostorového průniku pro automatické doplnění ORP/kraj/Povodí. 4. Návrh upřesnění: Zadavatel v analytické fázi specifikuje geometrický model vodních děl dle jejich druhu: bodová díla (CS, J, ČOV) jsou lokalizována jedním bodem X/Y v S-JTSK, liniové stavby (H, SP) párem souřadnic počátečního a koncového bodu, pro plošná díla (VN, SN, O) zadavatel upřesní, zda postačuje bodový centroid/referenční bod, nebo je požadována polygonová geometrie. Zadavatel vezme na vědomí, že u liniových a plošných vodních děl bodová nebo dvou-bodová reprezentace nezaručuje úplné přiřazení administrativních jednotek (ORP, kraj, územní působnost s.p. Povodí): hráz nebo nádrž se může fyzicky rozkládat přes více ORP nebo krajů, zatímco systém přiřadí jednotku pouze podle průniku s lokalizačním bodem. Zadavatel proto upřesní, zda pro tato vodní díla postačuje přiřazení administrativní jednotky podle lokalizačního bodu (zjednodušené řešení), nebo zda je požadováno přiřazení na základě plné prostorové geometrie linie či polygonu. | Zadavatel na základě přeložených otázek upřesňuje, že: a) polohy vodních děl mají charakter bodu, u liniových staveb jsou evidovány dvě souřadnice (počátek a konec) na mapě se vykresluje prvek na základě počáteční souřadnice, b) vrstvy prostorových dat sloužící pro nápočet průniku budou součástí AgriGIS. Zadavatel doplní zadávací dokumentaci o výše uvedené vysvětlení. | ANO | Text byl doplněn do podkapitoly 8.8. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle (1) 1. Identifikace části zadání: Kapitola 8.5 „Požadavky na uživatelské rozhraní" — vizuální odlišení vodních děl podle naléhavosti prohlídky v seznamu; podkapitola „Integrace se systémem AgriGIS" — přenos vyfiltrovaných záznamů do mapové aplikace. 2. Stávající formulace: „Ze seznamu bude možné se prokliknout do mapové aplikace. Mapová aplikace bude zohledňovat vyfiltrovaná vodní díla. U seznamu vodních děl bude možné vizuálně odlišit vodní díla podle naléhavosti provedení prohlídky — například barvou záznamu, barevnou značkou atd. Přesný způsob rozlišení bude předmětem grafického návrhu Poskytovatele a podléhá schválení Objednatele." 3. Návrh nového znění: Doporučujeme doplnit: „V případě přechodu uživatele do mapové aplikace (proklik ze seznamu nebo z detailu záznamu) budou spolu s identifikátory vodních děl předány i hodnoty atributu naléhavosti prohlídky, aby bylo možné toto vizuální odlišení zachovat i v mapovém zobrazení. Technický způsob předání tohoto atributu do mapové aplikace (URL parametr / API) navrhne dodavatel v rámci implementační analýzy; návrh podléhá schválení Objednatele." 4. Potvrzení vazby na cíl a účel: Navrhovaná doplňková formulace zachovává cíl zadavatele — vizuálně odlišit naléhavost prohlídky. Rozšiřuje jej konzistentně i na mapové zobrazení, které je součástí téhož uživatelského workflow. 5. Popis zjednodušení: Uživatel (správce povodí, stavební úřad) bude moci vyhodnotit naléhavost prohlídek přímo v mapě bez přepínání kontextu. Eliminuje nutnost paralelní práce v tabulkovém seznamu a v mapě. 6. Dopad navrhované úpravy: Minimální dopad na implementaci (přidání jednoho atributu do předávaného kontextu). Pozitivní dopad na použitelnost mapové aplikace pro prioritizaci terénních prohlídek. | Zadavatel upřesňuje, že v případě přechodu do mapové aplikace budou předávány pouze identifikátory vodních děl, hodnoty naléhavosti by měl systém AgriGIS, stejně jako všechny další údaje čerpat z databáze. Návrh konkrétní podoby rozhraní bude součástí dohody s dodavatelem AgriGIS a podléhá schválení Zadavatelem. | ANO | Text doplněn do podkapitoly 8.3. |
|  |  | Návrhy na úpravu formulace zadání při zachování sledovaného cíle (2) 1. Identifikace části zadání: Kapitola 8.8 „Data v agendě ETBD" — specifikace databázového schématu pro prostorová data. 2. Stávající formulace: „Předpokládáme, že Dodavatel doplní finální databázové schéma o další atributy nutné pro fungování agendové komponenty ETBD nebo pro správné fungování spolupracující mapové aplikace pro ETBD." 3. Návrh nového znění: Doporučujeme doplnit: „Dodavatel v rámci implementační analýzy navrhne způsob uložení prostorových dat vodních děl v databázi IS VaK, včetně volby souřadnicového systému, typu geometrie pro jednotlivé druhy vodních děl a způsobu synchronizace nebo propojení těchto dat s prostředím ArcGIS Enterprise (AgriGIS). Návrh musí být konzistentní s datovým modelem AgriGIS a podléhá schválení Objednatele ve spolupráci s Provozovatelem AgriGIS." 4. Potvrzení vazby na cíl a účel: Navrhovaná úprava zachovává cíl — správně fungující mapová aplikace pro ETBD. Explicitně zavazuje dodavatele k navržení konzistentního prostorového datového modelu v rámci analytické fáze, namísto ponechání tohoto architektonicky klíčového rozhodnutí zcela otevřeného. 5. Popis zjednodušení: Zabrání se situaci, kdy dodavatel navrhne prostorový datový model nekompatibilní s ArcGIS Enterprise, což by vyžadovalo přepracování v pozdní fázi projektu (vada kategorie A implementační analýzy). 6. Dopad navrhované úpravy: Bez dopadu na harmonogram. Vyžaduje, aby Objednatel zajistil součinnost Provozovatele AgriGIS při schvalování prostorového datového modelu v rámci implementační analýzy (Fáze 2). | Zadavatel se domnívá, že dotaz zřejmě vychází z představy komplikované datové strukty a různorodé palety geografických reprezentací prvků vodních děl podléhajících TBD. Vodní díla TBD jsou však evidována pouze bodově, jejich atributy budou součástí zadávací dokumentace a předpokládané kardinality jsou také naznačeny v zadávací dokumentaci. S ohledem na zde uvedená fakta Zadavatel nebude na podkladě této připomínky realizovat další doplnění nebo úpravu zadávací dokumentace. | NE |  |
|  | Kapitola 9: Požadavky na agendovou komponentu Samostatná evidence dokumentů (SED) |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Příloha č. 4 – Technická specifikace; komponenta SED, tabulky metadat dokumentů pro agendu ETBD. 2. popis nepřesnosti: Dvě různé tabulky metadat pro ETBD uvádí odlišný organizační kód útvaru – jedna „15112“, druhá „15122“ (kódy pro PPVAK/PRVAK a MPVAK/VSVaK jsou shodné v obou tabulkách). 3. dopad zjištěné nepřesnosti: Rozdílný kód pro tutéž agendu může vést k nesprávnému směrování dokumentů v SED. 4. návrh upřesnění: Doporučujeme sjednotit a jednoznačně potvrdit správný organizační kód útvaru pro agendu ETBD (15112, nebo 15122) v obou tabulkách metadat. | Zadavatel opraví chybu v textu Zadávací dokumentace. | ANO | Oprava textu dokumentu byla provedena v podkapitole 9.8. |
|  |  |  |  |  |  |
|  | Kapitola 10: Požadavky na komponentu Jmenného rejstříku |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: Příloha č. 4 – Technická specifikace; komponenta Jmenný rejstřík, datový model atributu IČO. 2. popis nepřesnosti: Datový model definuje IČO nekonzistentně – u FO jako „text, max 50 znaků“, u PO jako „INTEGER, max 50 znaků“ (vnitřně rozporné, celočíselný typ se počtem znaků neomezuje). 3. dopad zjištěné nepřesnosti: Uložení IČO jako INTEGER by mohlo vést ke ztrátě úvodních nul, což by způsobilo chybnou identifikaci subjektu. 4. návrh upřesnění: Doporučujeme sjednotit datový typ atributu IČO pro fyzické i právnické osoby na textový typ, aby nedocházelo ke ztrátě úvodních nul. | Dodavatel provede sjednocení požadavků na datové typy. | ANO | Oprava textu dokumentu byla provedena v podkapitole 10.6 |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Harmonogram realizace  | NE |  |  |  |
|  |  | Zadání používá, názvy Fáze 2, Fáze 3, Fáze 4, aniž by tyto fáze byly uvedeny v harmonogramu projektu. Doporučujeme doplnit definice jednotlivých fází a jejich doplnění do harmonogramu. | Vysvětlení jednotlivých fází je součástí návrhu smlouvy v Zadávací dokumentaci k realizaci Funkčního celku. Tento text nebyl součástí PTK. | NE |  |
|  | Možnost zkrácení | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Zajištění dodržení harmonogramu | NE |  |  |  |
|  |  | Nedoporučujeme jako výběrové kritérium používat zkrácení harmonogramu. Navrhujeme tyto mechanismy: Navržení pravidelných akceptačních a platebních milníků, které dodavatele finančně průběžně motivují dodávat včas průběžné výstupy. Pravidelný, formalizovaný status reporting s explicitním trackováním odchylky od harmonogramu (nikoli jen ad hoc informování) Řízení rizik s pravidelnou aktualizací rizikového registru a jasnou eskalační cestou při identifikaci hrozícího zpoždění. Průběžné/inkrementální akceptace dílčích výstupů (nikoli jen finální akceptace celku), aby se rizika zpoždění a nekvality odhalila co nejdříve. Řídicí výbor se zástupci Objednatele i Dodavatele, s pravidelnou frekvencí (např. měsíční) a jasně definovanou eskalační pravomocí. Úprava počtu vad kategorie B, které podmiňují úspěšné ukončení Milníku či Fáze na nenulový.  | Zadavatel děkuje za přípomínku, v tomto případě však ponechá text zadávací dokumentace v původním smyslu. | NE |  |
|  |  |  |  |  |  |
|  | Seznam významných služeb |  |  |  |  |
|  | Obecné požadavky na seznam služeb  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Předmět plnění referenční služby | NE |  |  |  |
|  |  | Vzhledem k zaměření VZ považujeme předmět referenční služby za příliš obecně definovaný. Pokud chce zadavatel garantovat zkušenost dodavatele s dodávkami obdobného typu IS (sw řešení), doporučujeme doplnit definici referenční služby o IS v oblasti vodohospodářství. Zároveň doporučujeme zvážit přidání požadavku na referenci v oblasti systémů implementující procesní řízení.  | Vzhledem k úzkému a vysoce specializovanému charakteru tohoto odvětví by stanovení takového požadavku mohlo vést k neúměrnému omezení hospodářské soutěže a potenciálně diskriminačnímu nastavení kvalifikačních podmínek. Zadavatel proto požaduje reference na informační systémy obdobného rozsahu a složitosti bez omezení na konkrétní odvětví. | NE |  |
|  |  |  |  |  |  |
|  | Požadavek na ISVS | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Služba na dodávku aplikace / IS | NE |  |  |  |
|  |  | Vzhledem k předpokládané hodnotě VZ považujeme minimální hodnotu referenční zakázky za nepřiměřeně nízkou a navrhujeme zvýšit na 10 mil. Kč | Zadavatel se rozhodl neuplatnit striktnější kritéria, aby nedošlo k neúměrnému omezení hospodářské soutěže a potenciálně diskriminačnímu nastavení kvalifikačních podmínek. | NE |  |
|  |  |  |  |  |  |
|  | Služba na provoz aplikace / IS | NE |  |  |  |
|  |  | Garantovaná provozní doba je uvedena z našich zkušeností a námi dodávaných servisních služeb v nestandardní hodnotě. Většinou se jedná o 5x8 (resp. ve výjimečných případech 5x9), nebo o 7x24. Doporučujeme vyžadovat referenci na službu, která odpovídá obvyklým parametrům, aby nedošlo ke znevýhodnění uchazečů a napadnutelnosti výběrového řízení (tedy 5x8 nebo 7x24) | Požadovaná garantovaná provozní doba v rámci referenční zakázky je stanovena jako minimálně 5x10. Tento požadavek vychází z provozních potřeb a parametrů budoucího funkčního celku. Zadavatel se nedomnívá, že by požadavek byl diskriminační nebo bezdůvodně omezoval hospodářskou soutěž, neboť uchazeči mohou prokázat splnění kvalifikace i referenční zakázkou s přísnějšími parametry poskytovaných služeb (např. 7x24). | NE |  |
|  |  |  |  |  |  |
|  | Seznam členů realizačního týmu a jejich kvalifikace |  |  |  |  |
|  | (1) Obecné požadavky na realizační tým | NE |  |  |  |
|  |  | Odborné znalosti a složení týmu reflektuje pouze IT část dodávky a zcela pomíjí, že pro zajištění kvality řešení je potřeba aby dodavatel disponoval i odborným know-how. Z našeho pohledu je potřeba doplnit tým o odborníky minimálně v těchto rolích: 1. osoba, která za vlastníka nebo provozovatele VHI zpracovává vedení majetkové a provozní evidence vodovodů a kanalizací v rozsahu dle § 5 zák. č. 274/2001 Sb. Tato osoba by měla být ideálně ze společnosti, která vlastní nebo provozuje velký rozsah vodohospodářského majetku, který garantuje širokou škálu řešených druhů a typů VHI, které by navrhované technické řešení mělo pokrýt. 2. osoba která za vlastníka a provozovatele VHI zpracovává plán financování obnovy vodovodů a kanalizací dle části 5., § 13 vyhl. 428/2001 Sb., kterou se provádí zákon č. 274/2001 Sb. o vodovodech a kanalizacích. Jako v bodě 1) platí, že daná osoba by měla být ideálně ze společnosti, která vlastní nebo provozuje velký rozsah vodohospodářského majetku, který garantuje širokou škálu řešených druhů a typů VHI, které by navrhované technické řešení mělo pokrýt. 3. právník s dokonalou znalostí vodního práva, který zná všechny povinnosti vlastníka a provozovatele VHI v souvislostech. Garantuje, že se při návrhu technického řešení nic neopomene. 4. specialista konzultant ESRI s pětiletou zkušeností na projektech vývoje Geografických informačních systému s certifikací ESRI na úrovni Associate. Garantuje, že návrh řešení využije efektivně existující řešení MZE na platformě ESRI zejména integraci a AgriGIS a NPP. | Zadavatel neomezuje počet osob v jednotlivých rolích. Uchazeči tak mohou do role analytiků nominovat odborníky disponující znalostmi z oboru VaK a vodního zákona. Tyto oblasti budou také testovány v rámci testu pro roli analytika. | NE |  |
|  | (2) Minimálně jedna (1) osoba v kategorii role Solution Architekt splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (3)Minimálně jedna (1) osoba v kategorii role Aplikační architekt splňující následující požadavky:  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (4) Minimálně jedna (1) osoba v kategorii role Projektový manažer splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (5) Minimálně dvě (2) osoby v kategorii role Analytik IT senior splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (6) Minimálně pět (5) osob v kategorii role Vývojář splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (7) Minimálně jedna (1) osoba v kategorii role Tester splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (8) Minimálně jedna (1) osoba v kategorii role Bezpečnostní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (9) Minimálně jedna (1) osoba v kategorii role Manažer provozu splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (10) Minimálně dvě (2) osoby v kategorii role Provozní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (11) Minimálně jedna (1) osoba v kategorii role Specialista uživatelské podpory splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (12) Minimálně jedna (1) osoba v kategorii role SCRUM master splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Celková nabídková cena: 30 % | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Návrh vybraných částí řešení: 30 % | ANO, s doporučením |  |  |  |
|  |  | Doporučujeme jako některou z úloh, které mají být zpracovány, realizovat také úlohy a) demonstrující konzistenci datového modelu, topologie a zobrazení nad mapou b) demonstrující využítí ArcGIS Online | Zadavatel děkuje za námět nicméně v tomto případě ponechá parametry bez změny. Požadované demonstrace konzistence datového modelu, topologie a mapového zobrazení, stejně jako demonstrace využití ArcGIS Online, nespadají do předmětu plnění funkčního celku EVI. GIS kompetence, správa prostorových dat, datového modelu, topologických pravidel a konfigurace mapových aplikací jsou v cílové architektuře řešení svěřeny systému AgriGIS a jeho provozovateli. | NE |  |
|  | Prokázání odborných znalostí: 30 % | NE |  |  |  |
|  |  | Doporučujeme rozšířit. Odborné znalosti a složení týmu reflektuje pouze IT část dodávky a zcela pomíjí, že pro zajištění kvality řešení je potřeba aby dodavatel disponoval i odborným know-how. Z našeho pohledu je potřeba doplnit tým o odborníky minimálně v těchto rolích: 1. osoba, která za vlastníka nebo provozovatele VHI zpracovává vedení majetkové a provozní evidence vodovodů a kanalizací v rozsahu dle § 5 zák. č. 274/2001 Sb. Tato osoba by měla být ideálně ze společnosti, která vlastní nebo provozuje velký rozsah vodohospodářského majetku, který garantuje širokou škálu řešených druhů a typů VHI, které by navrhované technické řešení mělo pokrýt. 2. osoba která za vlastníka a provozovatele VHI zpracovává plán financování obnovy vodovodů a kanalizací dle části 5., § 13 vyhl. 428/2001 Sb., kterou se provádí zákon č. 274/2001 Sb. o vodovodech a kanalizacích. Jako v bodě 1) platí, že daná osoba by měla být ideálně ze společnosti, která vlastní nebo provozuje velký rozsah vodohospodářského majetku, který garantuje širokou škálu řešených druhů a typů VHI, které by navrhované technické řešení mělo pokrýt. 3. právník s dokonalou znalostí vodního práva, který zná všechny povinnosti vlastníka a provozovatele VHI v souvislostech. Garantuje, že se při návrhu technického řešení nic neopomene. | Zadavatel neomezuje počet osob v jednotlivých rolích. Uchazeči tak mohou do role analytiků nominovat odborníky disponující znalostmi z oboru VaK a vodního zákona. | NE |  |
|  | Urychlení vývoje a dodání vybraných modulů: 10 % | NE |  |  |  |
|  |  | Kritérium považujeme za nevhodné. Ze zkušenosti z podobných tendrů dochází ke splnění takového požadavku u všech uchazečů. Není pak naplněn cíl takového kritéria, tj. vybrat takového dodavatele, který má dostatek zdrojů realizaci dodávky. Doporučujeme spíše navýšit váhu kritéria 3 – prokázání odborných znalostí, které lépe prokazuje schopnost uchazeče dodat zakázku v plánovaném harmonogramu. | Zadavatel ponechá možnost nabídnout zkrácení doby realizace a související hodnoticí kritérium. Cílem Zadavatele je umožnit dodavatelům uplatnit jejich zkušenosti, kapacity, know-how a případné vlastní metodické či technologické postupy, které mohou vést k efektivnějšímu průběhu vývoje a rychlejšímu dodání řešení. Rozsah garantované součinnosti poskytované Zadavatelem je popsán v zadávací dokumentaci a Uchazeči by při stanovení nabízených termínů měli vycházet z těchto podmínek. Termín realizace nabídnutý Uchazečem v rámci tohoto hodnoticího kritéria bude pro vybraného dodavatele závazný. Zadavatel si je současně vědom skutečnosti, že v průběhu realizace mohou nastat okolnosti, které dodavatel nemůže objektivně ovlivnit, včetně případných prodlení způsobených na straně Zadavatele. Z tohoto důvodu smlouva obsahuje ustanovení, na jehož základě může dodavatel v odůvodněných případech požádat o prodloužení termínu plnění. Takový požadavek bude posouzen a případně schválen Zadavatelem v souladu se smluvními podmínkami. | NE |  |
|  |  |  |  |  |  |
|  | Předpokládaná hodnota zakázky | NE |  |  |  |
|  |  | Vzhledem k rozsahu díla považujeme předpokládanou cenu za podhodnocenou. Rozsah poptávaného díla byl oproti minulé zakázce rozšířen o moduly SED, Jmenný rejstřík a ETBD a toto rozšíření scopu není v předpokládané ceně nijak reflektováno. Celkovou hodnotu zakázky předpokládáme ve výši 75–110 mil Kč bez DPH  | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. Limit pro výši nabídkové ceny byl na základě PTK zrušen, nabídková cena tedy může přesáhnout předpokládanou hodnotu VZ. | ANO | Úprava podmínek uvedených v zadávací dokumentaci. |
|  | Limity pro nabídkovou cenu | NE |  |  |  |
|  |  | Předpokládaná cena za Služby s fixním plněním a Služby s výkonovým plněním v rozsahu 2760 MD uvedená zadavatelem je 16 225 000 Kč, což je z našeho pohledu jednoznačně podhodnocené. Je třeba vzít v úvahu že pouze dodávka 2760 MDs představuje cenu okolo 30 mil Kč, pokud budeme vycházet z průměrné MD sazby na českém IT trhu | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. Limit pro výši nabídkové ceny byl na základě PTK zrušen, nabídková cena tedy může přesáhnout předpokládanou hodnotu VZ. | ANO | Úprava podmínek uvedených v zadávací dokumentaci. |
|  | Platební podmínky | NE |  |  |  |
|  |  | Vzhledem k rozsahu díla a době trvání dodávky (analytická a implementační část) považujeme za vhodné rozdělit platbu za vývoj a dodání funkčního celku 1) na dílčí platební milníky vázané na dodávku jednotlivých částí díla (modulů) 2) doplnit platební milník po zahájení projektu (podpisu smlouvy) Za Konkrétně tedy celkem 6 platebních milníků: 1.	po podepsání smlouvy 2.	po akceptaci implementační analýzy 3.	po akceptaci Milník 1 4.	po akceptaci Milník 2 5.	po akceptaci Milník 3 6.	po akceptaci funkčního celku Důvodem pro takovou změnu je to, že dílčími platebními milníky se snižuje celková cena, protože dodavatel není nucen nést veškeré náklady na financování výroby po celou dobu realizace. | Připomínka není akceptována. Zadavatel na základě interního posouzení rozhodl ponechat způsob úhrady plnění v původním znění. | NE |  |
|  | Bankovní záruka | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Lhůta pro podání nabídek | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  |  | Nejsou |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
| Název obchodní společnosti: Dodavatel č. 3 |  |  |  |  |  |
|  |  | Komentář Dodavatele č. 3 | Vysvětlení/Reakce | Zapracováno |  |
|  | Otázky k předmětu plnění |  |  |  |  |
|  | Kapitola 1: Stávající stav ICT zajištění agendy VaK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | Nepřesnosti, nejasnosti nebo rozpory v návrhu zadání 1. identifikace části zadání: 1.1. Stávající datové zdroje (k 1.2.): „Struktura jednotlivých databází vychází z příloh vyhlášky č. 428/2001 Sb., kterou se provádí zákon č. 274/2001 Sb., o vodovodech a kanalizacích pro veřejnou potřebu a o změně některých zákonů.“ 2. popis nepřesnosti: 2.1. „Struktury jednotlivých databází“ jsou v platné legislativě popsané s různou mírou podrobnosti a vzájemné konzistence (jak po věcné, tak formální stránce) 3. dopad zjištěné nepřesnosti: 3.1. Pokud zadávací dokumentace vychází při návrhu datových struktur z platné legislativy, pak její vzájemná nekonzistence komplikuje návrh jednotného datového modelu, zvyšuje složitost implementace a vytváří prostor pro rozdílnou interpretaci požadavků jednotlivými uchazeči. 4. návrh upřesnění: 4.1. Doporučujeme, aby zadávací dokumentace v případech, kdy legislativa připouští více možných výkladů nebo obsahuje vzájemně nekonzistentní datové definice, jednoznačně stanovila referenční datový model a jeho interpretaci pro účely návrhu informačního systému. (Poznámka: Z dlouhodobé praktické zkušenosti považujeme za systémově nejvhodnější řešení sjednocení datových definic v legislativě (věcně i formálně). Uvědomujeme si však, že taková změna přesahuje rámec této veřejné zakázky i kompetence adresáta PTK.) | Součástí plnění dodavatele je návrh a implementace takového datového modelu, který bude vycházet z požadavků platné legislativy a současně bude odpovídat požadovaným funkcionalitám systému. Zadavatel nepovažuje za účelné stanovovat úplný referenční datový model, neboť jeho finální podoba může být definována až na základě implementační analýzy provedené Dodavatelem. | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 2: Požadavky na nový systém |  |  |  |  |
|  |  | 1.1 Základní architektura systému (kap 2.2) 2.1 Pro Testovací a Pre-produkční instanci je jasně specifikováno, že je zajišťuje Objednatel. Z textu zadávací dokumentace není zcela jednoznačné, zda způsob zajištění Produkčního prostředí odpovídá stejnému modelu jako u prostředí Testovacího a Pre-produkčního, nebo zda se předpokládá odlišné rozdělení odpovědností. Odstavec, který se týká vývojového prostředí je možné vnímat, jako součást bloku uvedeného „Pro všechna prostředí platí“. 3.1 Povede minimálně k doplňujícím dotazům a může vést k rozdílnému vymezení rozsahu plnění jednotlivými uchazeči, a tím i k obtížně porovnatelným nabídkám. 4.1 Sourodým způsobem popsat všechna prostředí vč. Vývojového. | Objednatel v rámci Specifikace předmětu veřejné zakázky explicitně doplnít, že zajištění Produkčního prostředí je shodný s Testovacím a preprodukčním. Současně Objednatel upozorňuje, že vývojové prostředí není součástí požadovaného plnění a Specifikace předmětu veřejné zakázky. Zajištění vývojového prostředí je plně v odpovědnosti dodavatele. | ANO | V podkapitole 2.2 došlo k doplnění informace o zajištění provozu infrastruktury provozního prostředí v souladu s prostředím testovacím a preprodukčním. |
|  |  | 1.2 Integrace systému (kap. 2.4.) 2.2 Není jednoznačně vymezen rozsah integračních služeb poskytovaných platformou AgriBus a služeb, které jsou součástí dodávky uchazeče. Ze zadání není zřejmé zejména to, zda je součástí plnění také návrh a implementace nových integračních služeb, jejich publikace, transformace zpráv, orchestrace nebo konfigurace integrační platformy. 3.2 Může vést k nepřesnému nacenění nabídky a následným jednáním o vícepráce. 4.2 Přesněji specifikovat kdo řeší služby AgriBus vč. Nových, které mohou být potřeba pro dodávané řešení. | Vzhledem k obecné povaze dotazu není možné jednoznačně vymezit odpovědnost za všechny potenciální integrační scénáře. Zadavatel obecně předpokládá, že tam, kde již integrační rozhraní existují a jejich existence není zpětně ovlivněna systémem IS VaK, budou primárně využita tato existující rozhraní. V případech, kdy bude nezbytné vytvořit nové integrační služby nebo služby budou vznikem IS VaK, bude jejich návrh a specifikace řešena v součinnosti s dodavatelem integrovaného systému a dalšími dotčenými stranami (to se týká zejména systémů SEPO a AgriGIS a všech služeb v rámci propojení komponent funkčního celku). Implementace a provoz integrační platformy AgriBus nejsou součástí plnění dodavatele IS VaK a je v gesci Zadavatele. Dodavatel IS VaK je odpovědný za poskytnutí specifikace požadovaných služeb a rozhraní, přičemž konfiguraci a nastavení integrační platformy AgriBus zajistí Zadavatel. Dodavatel poskytuje nezbytnou součinnost ke které je vyzván a poskytuje nezbytnou součinnost při realizaci takového rozhraní. | NE |  |
|  |  | 1.3 Implementační analýza (kap. 2.11) 2.3 Implementační analýza může podstatným způsobem doplnit zadání, nejsou jasně specifikovaná kritéria jejího hodnocení, řešení, které dodavatel nabídne a následně podpoří v implementační analýze může Poskytovatel odmítnout a trvat na jiném, finančně náročnějším. 3.3 Zadávací dokumentace nevymezuje postup pro případ, kdy objednatel v rámci implementační analýzy neakceptuje navržené řešení a požaduje jeho přepracování nebo nahrazení jiným řešením. Není zřejmé, jak bude v takovém případě posuzováno, zda se stále jedná o upřesnění zadání, nebo již o změnu rozsahu plnění. 4.3 Jednoznačně vymezit rozsah implementační analýzy a stanovit kritéria, podle kterých bude posuzováno, zda navržené úpravy představují pouze zpřesnění zadání, nebo již změnu rozsahu plnění. Současně doporučujeme popsat proces schvalování výstupů implementační analýzy, vč. lhůt pro jejich posouzení a postupu při neshodě mezi objednatelem a dodavatelem. | Zadavatel s připomínkou nesouhlasí. Implementační analýza slouží k upřesnění způsobu realizace požadavků zadavatele a návrhu technického řešení v mezích zadávací dokumentace. Nejedná se o nástroj pro změnu rozsahu plnění veřejné zakázky. | NE |  |
|  |  | Doporučení: Přesné vymezení hranic odpovědnosti mezi agendovou komponentou a sdílenými službami Technická specifikace popisuje integrační vazby mezi agendovou komponentou a sdílenými službami (AgriBus, SED, Jmenný rejstřík, AgriGIS). Není však ve všech případech jednoznačně vymezen rozsah funkcionality, která je součástí dodávky agendové komponenty, a funkcionality zajišťované sdílenými platformami nebo jejich provozovateli. Zejména není vždy zřejmé: • kdo odpovídá za návrh a implementaci nových integračních služeb, • kdo zajišťuje transformace dat a orchestrace integračních toků, • kdo publikuje a spravuje integrační rozhraní, • kdo odpovídá za konfiguraci integrační platformy, • které části řešení jsou součástí plnění této veřejné zakázky a které budou dodány nebo provozovány jiným subjektem. Doporučujeme jednoznačně vymezit hranice odpovědnosti jednotlivých systémů, sdílených platforem a dodavatelů, aby všichni uchazeči oceňovali stejný rozsah plnění. | Připomínka obsahuje několik samostatných otázek: Kdo odpovídá za návrh a implementaci nových integračních služeb? V tomto bodě záleží na tom, zda je služba již v provozu a IS VaK je pouze konzumentem (např. základní registry) nebo zda je služba vývíjena a upravována v kontextu IS VAK (například vešklerá komunikace se SEPO, komunikace mezi komponentami Funkčního celku). Ve druhém případě Dodavatel IS VaK ve splupráci s dodavatelem druhého systému připraví návrh rozhraní. V případě potřeby nových integračních služeb budou jejich specifikace připraveny v součinnosti se správci a dodavateli integrovaných systémů. Pro zajištění porovnatelnosti Zadavatel do ZD uvede infomraci o nacenění v takovém smyslu, že Uchazeč v rámci zadávacího řízení by měl v nabídce počítat s takovou pracností, jako by integrační rozhraní v takovém případě navhroval sám. Kdo zajišťuje transformace dat a orchestraci integračních toků? Pokud je v rámci komunikace potřeba orchestrace, zajišťuje ji platforma AgriBus. Transformace dat je možné zajistit na urovni AgriBus nebo v systému. V současném zadání nepředpokládáme transformaci dat na AgriBus. Specifické požadavky na transformaci příchozích zpráv v SED jsou uvedeny v popisu dané komponenty. Kdo publikuje a spravuje integrační rozhraní? Pokud je potřeba vystavit novou službu, je jejich specifikace předána provozovateli AgriBus. Kdo odpovídá za konfiguraci integrační platformy? Konfigurace a provoz integrační platformy AgriBus nejsou součástí plnění dodavatele IS VaK a jsou zajišťovány provozovatelem platformy AgriBus. Které části řešení jsou součástí plnění této veřejné zakázky a které budou dodány nebo provozovány jiným subjektem? Součástí plnění této veřejné zakázky je návrh a implementace funkčních celků IS VaK včetně jejich rozhraní vůči okolním systémům. Součástí plnění nejsou sdílené resortní platformy a systémy (zejména AgriBus, AgriGIS, SED a Jmenný rejstřík), které jsou dodávány a provozovány samostatně. Konkrétní podoba integračních vazeb bude upřesněna v rámci implementační analýzy. Zadavatel na podkladě této připomínky doplní text zadávací dokumentace o informace uvedené v odpovědích na předložené otázky. | ANO | Text byl doplněn na konec kapitoly 2.4. |
|  |  |  |  |  |  |
|  | Kapitola 3: Základní požadavky na funkční celek |  |  |  |  |
|  |  | 1.1 Chyby v datech a práce s nimi (kap. 3.5) 2.1.1. Není jednoznačně specifikován význam pojmů: • konfigurační přehled chyb • aktivní • deaktivovaná chyba 2.1.2. Není zřejmý vztah mezi evidovanými chybami a validačními pravidly ani jejich životní cyklus. Ze zadání není jednoznačné zejména: jak chyba vzniká, kdo a za jakých podmínek ji může deaktivovat nebo znovu aktivovat, zda se deaktivuje konkrétní výskyt chyby nebo typ chyby, jaký je vztah mezi odstraněním chyby a opětovným vyhodnocením validačních pravidel. 3.1. Nejednoznačná specifikace práce s chybami může vést k rozdílnému návrhu mechanismu validací, evidence chyb a jejich životního cyklu jednotlivými uchazeči. Výsledkem mohou být funkčně odlišná řešení i rozdílné ocenění nabídek. 4.1. Doporučujeme jednoznačně definovat význam pojmů "aktivní chyba", "deaktivovaná chyba" a "konfigurační přehled chyb", jejich vztah k validačním pravidlům a popsat celý životní cyklus chyby vč. podmínek jejího vzniku, deaktivace a opětovné aktivace. | Zadavatel nesouhlasí s tím, že by nebylo zřejmé, co je aktivní a neaktivní chyba, nicméně Zadávací dokumentace bude doplněna tak, aby lépe vysvětlila životní cyklus chyby. Chyba vzniká po provedení validace, může tedy být již součástí příchozích dat. Část formuláře obsahujícího chyby se označuje Protokol chyb. Dále může vzniknout, resp. být odhalena a zaznamenána, po kliknutí na tlačítko "Kontrola" v komponentě Funkčního celku. V takovém případě je zařazena do protokolu chyb. Pokud dojde ke změně vstupních polí pro výpočet chyby a chyba se již nevyskytuje, pak chyba z protokolu chyb mizí. Konfigurační přehled chyb v rozhraní systémového administrátora bude mít formu seznamu chyb vyhodnocovaných v dané agendové komponentě. Parametry chyb, které může administrátor měnit jsou v zadávací dokumentaci uvedeny v části: "Konfigurace chyb". | ANO | Do textu podkapitoly 3.5 byl doplněn nový bod "Životní cyklus chyby". K popisu činností a funkcí dostupných systémovému administrátorovi (podkapitola 3.10) byl doplněn text, týkající se konfigurace chyb. |
|  |  | 1.2. Export dat (kap 3.6) 2.2. Nejsou jednoznačně definovány požadavky: „Asynchronní generování rozsáhlého exportu“. Není jasné, co znamená časový údaj „v jednom čase“ v popisu „Každý uživatel může v jednom čase zadat právě jednu asynchronní operaci tohoto typu.“ 3.2. Nejednoznačné vymezení omezení asynchronních exportů může vést k rozdílné implementaci mechanismu plánování, souběžného zpracování a řízení dlouhotrvajících exportních operací. 4.2. Doporučujeme jednoznačně vymezit význam pojmu "v jednom čase", rozsah tohoto omezení a chování systému při dlouhotrvajících nebo neúspěšně dokončených asynchronních exportech. Zejména není jasné, co je míněno pojmem "v jednom čase". Zda se omezení vztahuje na celý systém, jednotlivé komponenty nebo pouze konkrétní typ exportu, kdy je asynchronní operace považována za ukončenou, jak se systém zachová v případě dlouhotrvajících nebo neúspěšně dokončených exportů. | Pojmem „v jednom čase“ zadavatel rozumí, že jeden uživatel může mít současně spuštěnu pouze jednu asynchronní exportní operaci daného typu. Do doby dokončení, zrušení nebo ukončení této operace chybovým stavem není umožněno založení další exportní operace stejného typu týmž uživatelem. Zadavatel v tomto smyslu upraví znění zadání. | ANO | Text doplněn do podkapitoly 3.6, konkrétně k požadavku na "Asynchronní generování rozsáhlého exportu".  |
|  |  | 1.3. Osobní a interní poznámky (kap. 3.8.) 2.3. Požadavek na možnost vložit do systému nestrukturované informace, bez kterých není možná interpretace, popř. další zpracování dat, není v zadání specifikován jednoznačně s ohledem na to: • zda jsou poznámky součástí auditní stopy, • zda podléhají verzování • zda jsou součástí exportů a importů • zda jsou přenášeny prostřednictvím integračních rozhraní • zda a jak ovlivňují další automatizované zpracování dat 3.3. Nedostatečná specifikace práce s interními a osobními poznámkami může vést k rozdílnému způsobu jejich implementace zejména ve vztahu k auditní stopě, verzování, exportům, integracím a automatizovanému zpracování dat. 4.3. Doporučujeme jednoznačně specifikovat životní cyklus interních a osobních poznámek, jejich vztah k auditní stopě, verzování, exportům, integračním rozhraním a jejich vliv na další automatizované zpracování dat. | Zadavetel upřesňuje: • zda jsou poznámky součástí auditní stopy Ano poznámky jsou součástí auditní stopy. • zda podléhají verzování Není přesně uvedeno o jaké verzování se má jednat. Osobní poznámka se dle požadavku přepisuje a je pouze součástí auditního logu, který je uživateli přístupný. • zda jsou součástí exportů a importů Mohou být součástí exportů. • zda jsou přenášeny prostřednictvím integračních rozhraní Poznámky nejsou součástí integračních rozhraní. • zda a jak ovlivňují další automatizované zpracování dat Poznámky neovlivňují zpracování dat. Zadavatel požadované upřesnění doplní do zadávací dokumentace. | ANO | Text doplněn do podkapitoly 3.8.  |
|  |  |  |  |  |  |
|  | Kapitola 4: Požadavky na agendovou komponentu – modul MP VAK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1.1. Nadpis kapitoly 4. POŽADAVKY NA AGENDOVOU KOMPONENTU – MODUL MP VAK (a identicky v případě dalších modulů komponenty VAK) 2.1. Jde o komponentu VAK, z nadpisu to vypadlo 3.1. Může vést k nesystematickému chápání termínů Komponenta / Modul 4.1. Změnit nadpis na „…4. POŽADAVKY NA AGENDOVOU KOMPONENTU VAK – MODUL MP VAK | Zadavatel upraví zadavací dokumentaci v navrženém smyslu. | ANO | Nadpisy byly opraveny, aby lépe rozlišily agendovou komponentu VAK. |
|  |  | 1.2. Editace přijatých dat – geografická příslušnost (str. 47) 2.2. Není jasné, co znamená „geografická příslušnost“. 3.2. Upřesnění umožní ošetřit dotčené komponenty tak, aby mohly s „geografickou příslušností“ pracovat. 4.2. Vysvětlit, co „geografická příslušnost“ znamená a k jakým entitám se vztahuje. | Geografická příslušnost se týká potenciálně všech úřadů veřejné správy a s.p. Povodí a její rozsah vychází z platných právních předpisů. V rámci systému je specifikována v atributech prvku. | ANO | Pojem byl doplněn do přehledu "Použité termíny a zkratky". |
|  |  | 1.3. Výsledky kontroly (str. 48) 2.3. Zde se píše o „Deaktivaci kontrol“, ale odkazováno je do tabulky „Chyby v datech a práce s nimi“, kde se hovoří o „deaktivaci chyb“ 3.3. Uvedený rozpor zvyšuje nejistotu v tom, zda se nastavují parametry kontrol nebo chyb a zda se deaktivují některé kontroly (pak některé údaje nebudou vyhodnoceny jako chyby), popř. lze chybným údajům „nastavit pardon“ a označit ho za validní („deaktivací chyby“) 4.3. Striktně definovat, zda se mají nastavovat parametry kontrol nebo deaktivovat detekované chyby v záznamech. | Zadavatel provede korekci zadavací dokumentaci tak, aby došlo k odstranění rozporu. | ANO | Text na straně 57 byl upraven, aby nezmiňoval deaktivaci kontrol. |
|  |  | 1.4. Kapitola 4.2. Požadavky na zpracování dat a práci se záznamy 2.4. Není jednoznačně definován pojem „sada navázaných vlastníků“ ani způsob, jakým systém vyhodnocuje existenci více záznamů o majetku s rozdílnou sadou navázaných vlastníků. 3.4. Není zřejmé, podle jakých pravidel má být existence „sady navázaných vlastníků“ vyhodnocována ani jaká je její vazba na evidované záznamy o majetku. To může vést k rozdílné implementaci této funkcionality jednotlivými uchazeči. 4.4. Definovat pojem „skupina navázaných vlastníků“ a způsob vazby této entity na záznamy o majetku | Skupina navázaných vlastníků je soubor vlastníků uvedených na daném hlášení. Tento soubor se může v jednotlivých letech lišit vlivem změn vlastnické struktury. Zadavatel nesouhlasí s tvrzením, že není zřejmé, jak bude vyhodnocována situace, kdy existuje více záznamů s rozdílnou sadou vlastníků. V zadávací dokumentaci je uvedeno, že se pracuje s nejnovější sadou. V případě pohledu do detailu majetku by měl mít uživatel možnost zobrazit všechny evidované vlastníky. Zadávací dokumentace uvádí: „Součástí tohoto rozhraní bude možnost podívat se na historické verze údajů evidovaných k majetku.“ Toto ustanovení se vztahuje i na údaje o vlastnících. | NE |  |
|  |  | 1.5. IČME ID (str. 52) 2.5. Zadávací dokumentace sama identifikuje potřebu zavést nový identifikátor (IČME ID) pro případy, kdy vlastníkem infrastruktury je fyzická osoba. Domníváme se, že stejná analýza by měla být provedena i pro konstrukci identifikátoru IČME jako celku, protože některé jeho části (zejména identifikace vlastníka a vazba na katastrální území) mohou obdobným způsobem komplikovat dlouhodobou stabilitu datového modelu. 3.5. Jedním z principů konstrukce IČME je zakódování identity vlastníka infrastruktury. To znamená, že při změně vlastníka dochází ke změně identifikátoru infrastruktury, přestože samotná infrastruktura zůstává beze změny. IČME se objevuje jako vazebný klíč mezi daty IS VAK a DTM. Pokud zadávací dokumentace navrhuje změnu konstrukce identifikátoru pro případy, kdy vlastníkem infrastruktury je fyzická osoba, považujeme za vhodné posoudit konstrukci identifikátoru IČME jako celku, vč. případů právnických osob. Další část identifikátoru IČME vychází z katastrálního území, zatímco jiné části zadání (např. PR VAK) pracují primárně s částmi obcí. Tyto územní jednotky nejsou vzájemně ekvivalentní ani hierarchicky skladebné, což může komplikovat jejich společné využití při agregacích, vyhodnocování a integračních vazbách. 4.5. Doporučujeme v rámci implementační analýzy prověřit, zda stávající konstrukce identifikátoru IČME dlouhodobě vyhovuje požadavkům nového systému, zejména z hlediska stability identifikace infrastruktury, integračních vazeb mezi IS VAK, DTM a dalšími systémy a požadovaných územních agregací. Z dlouhodobé zkušenosti upozorňujeme, že tato konstrukce může představovat riziko pro dlouhodobou stabilitu datového modelu. Domníváme se, že případná revize konstrukce identifikátoru IČME by měla být provedena na samém počátku implementační analýzy, protože následně ovlivňuje datový model, integrační vazby i migraci dat napříč celým řešením. V případě, že analýza prokáže omezení stávající konstrukce, doporučujeme zvážit návrh nového interního identifikátoru infrastruktury při zachování zpětné kompatibility s IČME. | Zadavatel nepředpokládá změny ve způsobu generování IČME. IČME ID slouží čístě k tomu, aby došlo k odstranění informací o fyzické osobě z IČME. | NE |  |
|  | Kapitola 5: Požadavky na agendovou komponentu – modul VS VAK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1. identifikace části zadání: 1.1. str. 68 odst. 2 odrážka „lokalita“ 2. popis nepřesnosti: 2.1. Zadávací dokumentace používá pojem „lokalita“, aniž by jej jednoznačně definovala. Není zřejmé, zda se jedná o samostatnou evidovanou entitu, geograficky vymezené území, lokalitu definovanou prostřednictvím GIS nebo pouze o textový údaj. Současně nejsou popsány případné vazby této entity na prostorová data ani způsob její identifikace. 3. dopad zjištěné nepřesnosti: 3.1. Nejednoznačné vymezení pojmu „lokalita“ může vést k rozdílné interpretaci této entity jednotlivými uchazeči, zejména ve vztahu k datovému modelu a případným vazbám na GIS. 4. návrh upřesnění: 4.1. Doporučujeme jednoznačně definovat pojem „lokalita“, jeho význam v datovém modelu systému, způsob jeho identifikace a případné vazby na geografická data nebo jiné evidované entity. | Pojem lokalita vychází z metodických pokynů Ministerstva financí k dané agendě, viz https://mf.gov.cz/cs/kontrola-a-regulace/cenova-regulace-a-kontrola/cenova-regulace-v-oboru-vak | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 6: Požadavky na agendovou komponentu – modul PP VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 7: Požadavky na agendovou komponentu – modul PR VAK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1.1. Kapitola 7. – úvodní odstavec. 2.1. Odkaz na legislativu, která nekonzistentně definuje datový model a vazby různých systémů (IS VAK / DTM), více viz. Obecná připomínka č. 1. 3.1. Nejednoznačné vymezení referenčních územních jednotek může vést k rozdílnému návrhu datového modelu jednotlivými uchazeči. 4.1. Jednoznačně určit referenční územní jednotku pro modul PR VAK a její vztah k ostatním komponentám systému. (Podle našich zkušeností by mohlo být vhodnější sledovat údaje majetkové a provozní evidence na části obcí ne na katastr, protože další údaje z ČSÚ jsou dostupné pouze na části obcí). | Zadavatel upřesňuje, že nejmenší referenční jednotkou je část obce nebo městská část. | NE |  |
|  |  | 1.2. Kapitola 7.2. Nápočty dat pomocí AgriGIS 2.2. Není jednoznačně popsán způsob provádění prostorových „nápočtů“ prostřednictvím AgriGIS ani rozsah funkcionality poskytované touto službou. Současně není zřejmé, jak budou řešeny přepočty údajů evidovaných na různých územních jednotkách (katastrální území × části obcí). 3.2. Rozdílné interpretace způsobu prostorových nápočtů mohou vést k odlišným implementacím integračních vazeb na AgriGIS. strana 11 z 31 4.2. Doplnit chybějící specifikace a upravit KÚ/KÚ nebo Část obce/Část obce | Provádění nápočtů bude řešeno s dodavatelem systému AgriGIS, bude se jednat o realizaci prostorového průniku prvků a zápis údajů do databáze prvků EVI. | NE |  |
|  |  | 1.3. Celá kapitola 7. 2.3. V dokumentaci se střídají pojmy „karta obce“ a „karta části obce“, aniž je jednoznačně určeno, která z těchto entit představuje základní evidenční jednotku modulu PR VAK. 3.3. Nejednoznačné vymezení evidenční jednotky (obec × část obce) může ovlivnit rozsah implementace i ocenění nabídky. 4.3. Jasně specifikovat, zda je požadováno sledovat údaje na obec / část obce, popř. katastrální území v souvislosti s tím, jak se zadavatel postaví k řešení rozporu katastr/část obce. | Pojem karta obce je zaužívaným pojmem v agendě PR VAK, nicméně Zadavatel upřesňuje, že nejmenší referenční jednotkou je část obce nebo městská část, pokud jsou v dané obci vymezeny. Pokud vymezeny nejsou je nejnižší jednotkou evidence obec. | NE |  |
|  |  | 1.4. Historická data (kap. 7.7.) 2.4. Není jasné, zda je požadovaný import historických geodat, která jsou součástí karet částí obcí v řadě stávajících PRVK. 3.4. Zcela jistě vyvolá diskusi o tom, jak se postavit k rozpornému požadavku vyplývajícímu z legislativy, kdy geodata infrastruktury VaK jsou v DTM, ale současně jsou ve fakticky mnohem lepším a konsolidovanějším a pro potřebu agendy PRVK na krajské úrovni mnohem vhodnějším stavu v krajských databázích PRVK. 4.4. Jasně specifikovat, jaká data a v jakém rozsahu se mají importovat a rozhodnout, zda stávající geodata PRVK ignorovat a nahradit je daty DTM, popř. je na základě dat DTM aktualizovat, jakkoli, ale jasně definovat. | Import historických geodat není součástí importu, proto se o něm zadávací dokumentace nezmiňuje. | NE |  |
|  |  | 1.5. Evidované atributy (kap. 7.11.) 2.5. Dále budou evidovány součtové údaje za ORP, kraje, ČR, povodí, aglomerace atd. – Použití formulace „atd.“ neumožňuje jednoznačně určit rozsah požadovaných agregací. 3.5. Nejednoznačný rozsah agregovaných údajů může způsobit rozdílné ocenění implementace této funkcionality. 4.5. Buď jasně vymezit množinu, nebo zadat jako parametrizovatelnou úlohu jejímž vstupem mohou být libovolné objekty s polygonovou geometrií.  | Zadavatel provede úpravu textu, aby byla odstraněna nejistota ohledně rozsahu požadované funkcionality. | ANO | Text v podkapitole 7.11 byl upraven tak, aby představoval taxativní výčet. |
|  |  |  |  |  |  |
|  | Kapitola 8: Požadavky na agendovou komponentu Evidence technicko bezpečnostního dohledu (ETBD) |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1a) V požadavcích na integraci je uveden požadavek na napojení Agrigis. 2a) b) MZe disponuje systémem LPIS, který je implementován jak nyní na SEPO, tak i přes ESB na jiné systémy resortu (např. SZIF nebo ÚKZÚZ). Vytvářením dalšího způsobu integrace ze SEPO a úpravami v Agrigis SW se výrazně navyšují náklady na integrace, které jsou již v základním režimu funkční. Ve stejném odstavci je uvedeno, že Dodavatel zajistí, že mapová aplikace bude čerpat prostorová data … Ze zadání není jasné, zda Dodavatel pod smlouvou na rozvoj ISVAK má zajistit úpravy mapové aplikace (Agrigis/LPIS) nebo se jedná o mapovou aplikaci, která je uvnitř ISVAK. Bylo by vhodné tuto část v bodě 8.3 přesněji specifikovat. | Využití platformy AgriGIS vychází z požadavků zadavatele na GIS řešení a z cílové architektury systému. Od GIS komponenty zadavatel požaduje zejména vysokou míru flexibility při zobrazování prostorových dat a možnost škálovatelného začlenění mapových funkcí do jednotlivých modulů a uživatelských rozhraní systému. Zadavatel uvádí, že systém AgriGIS je postaven na platformě ArcGIS Enterprise (https://enterprise.arcgis.com/en/). Úpravy mapových aplikací budou realizovány provozovatelem systému AgriGIS. Dodavatel funkčního celku EVI zajistí integraci mapových aplikací do uživatelského rozhraní EVI. Možnosti integrace jsou popsány v dokumentaci platformy ArcGIS Enterprise. Jako vhodná varianta se nabízí zejména využití ArcGIS Maps SDK for JavaScript (dříve ArcGIS API for JavaScript). | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 9: Požadavky na agendovou komponentu Samostatná evidence dokumentů (SED) |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 10: Požadavky na komponentu Jmenného rejstříku |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Harmonogram realizace  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Možnost zkrácení | NE |  |  |  |
|  |  | Harmonogram, jak je navržen, nedává prostor pro významné zkrácení. | Zadavatel ponechá možnost nabídnout zkrácení doby realizace a související hodnoticí kritérium. Cílem Zadavatele je umožnit dodavatelům uplatnit jejich zkušenosti, kapacity, know-how a případné vlastní metodické či technologické postupy, které mohou vést k efektivnějšímu průběhu vývoje a rychlejšímu dodání řešení. Rozsah garantované součinnosti poskytované Zadavatelem je popsán v zadávací dokumentaci a Uchazeči by při stanovení nabízených termínů měli vycházet z těchto podmínek. Termín realizace nabídnutý Uchazečem v rámci tohoto hodnoticího kritéria bude pro vybraného dodavatele závazný. Zadavatel si je současně vědom skutečnosti, že v průběhu realizace mohou nastat okolnosti, které dodavatel nemůže objektivně ovlivnit, včetně případných prodlení způsobených na straně Zadavatele. Z tohoto důvodu smlouva obsahuje ustanovení, na jehož základě může dodavatel v odůvodněných případech požádat o prodloužení termínu plnění. Takový požadavek bude posouzen a případně schválen Zadavatelem v souladu se smluvními podmínkami. | NE |  |
|  | Zajištění dodržení harmonogramu | NIC |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Seznam významných služeb |  |  |  |  |
|  | Obecné požadavky na seznam služeb  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Předmět plnění referenční služby | Srozumitelné – ANO Přiměřené – NE Splnitelné - ANO |  |  |  |
|  |  | Chybí vazba IS na výrazně specifickou oblast VaK. Zkušenosti s obecnými IT systémy mohou být v kontextu takto specifických agend nedostatečné. | Vzhledem k úzkému a vysoce specializovanému charakteru tohoto odvětví by stanovení takového požadavku mohlo vést k neúměrnému omezení hospodářské soutěže a potenciálně diskriminačnímu nastavení kvalifikačních podmínek. Zadavatel proto požaduje reference na informační systémy obdobného rozsahu a složitosti bez omezení na konkrétní odvětví. | NE |  |
|  |  |  |  |  |  |
|  | Požadavek na ISVS | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Služba na dodávku aplikace / IS | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Služba na provoz aplikace / IS | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Seznam členů realizačního týmu a jejich kvalifikace |  |  |  |  |
|  | (1) Obecné požadavky na realizační tým | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (2) Minimálně jedna (1) osoba v kategorii role Solution Architekt splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (3)Minimálně jedna (1) osoba v kategorii role Aplikační architekt splňující následující požadavky:  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (4) Minimálně jedna (1) osoba v kategorii role Projektový manažer splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (5) Minimálně dvě (2) osoby v kategorii role Analytik IT senior splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (6) Minimálně pět (5) osob v kategorii role Vývojář splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (7) Minimálně jedna (1) osoba v kategorii role Tester splňující následující požadavky: | ANO/NE |  |  |  |
|  |  |  |  |  |  |
|  | (8) Minimálně jedna (1) osoba v kategorii role Bezpečnostní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (9) Minimálně jedna (1) osoba v kategorii role Manažer provozu splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (10) Minimálně dvě (2) osoby v kategorii role Provozní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (11) Minimálně jedna (1) osoba v kategorii role Specialista uživatelské podpory splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (12) Minimálně jedna (1) osoba v kategorii role SCRUM master splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Celková nabídková cena: 30 % | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Návrh vybraných částí řešení: 30 % | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Prokázání odborných znalostí: 30 % | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Urychlení vývoje a dodání vybraných modulů: 10 % | NE |  |  |  |
|  |  | Kolize s otázkami k harmonogramu. | Zadavatel ponechá možnost nabídnout zkrácení doby realizace a související hodnoticí kritérium. Cílem Zadavatele je umožnit dodavatelům uplatnit jejich zkušenosti, kapacity, know-how a případné vlastní metodické či technologické postupy, které mohou vést k efektivnějšímu průběhu vývoje a rychlejšímu dodání řešení. Rozsah garantované součinnosti poskytované Zadavatelem je popsán v zadávací dokumentaci a Uchazeči by při stanovení nabízených termínů měli vycházet z těchto podmínek. Termín realizace nabídnutý Uchazečem v rámci tohoto hodnoticího kritéria bude pro vybraného dodavatele závazný. Zadavatel si je současně vědom skutečnosti, že v průběhu realizace mohou nastat okolnosti, které dodavatel nemůže objektivně ovlivnit, včetně případných prodlení způsobených na straně Zadavatele. Z tohoto důvodu smlouva obsahuje ustanovení, na jehož základě může dodavatel v odůvodněných případech požádat o prodloužení termínu plnění. Takový požadavek bude posouzen a případně schválen Zadavatelem v souladu se smluvními podmínkami. | NE |  |
|  |  |  |  |  |  |
|  | Předpokládaná hodnota zakázky | NE |  |  |  |
|  |  | Nepřiměřené k ceně za kterou MZE poptávalo dodávku menšího početu Komponent za srovnatelnou cenu v r. 2023. Nepřiměřené aktuálním požadavkům na integrace, importy, složení týmu, …. | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. Limit pro výši nabídkové ceny byl na základě PTK zrušen, nabídková cena tedy může přesáhnout předpokládanou hodnotu VZ. | ANO | Úprava podmínek uvedených v zadávací dokumentaci. |
|  | Limity pro nabídkovou cenu | NE |  |  |  |
|  |  | Viz výše | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. Limit pro výši nabídkové ceny byl na základě PTK zrušen, nabídková cena tedy může přesáhnout předpokládanou hodnotu VZ. | ANO | Úprava podmínek uvedených v zadávací dokumentaci. |
|  | Platební podmínky | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Bankovní záruka | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Lhůta pro podání nabídek | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  |  | NE |  |  |  |
|  |  | Integrace na AgriGis: Rozhraní mapové aplikace není specifikováno (API, autentizace, filtrace, formát dat)  | API rozhraní pro komunikaci s AgriGIS, který je postaven na platformě ArcGIS Enterprise, bude navrženo v rámci realizace projektu. Technologické možnosti a omezení integračního rozhraní proto vycházejí z funkcionalit a standardních integračních mechanismů této platformy. https://enterprise.arcgis.com/en/ Zadavatel uvádí, že za určení rozsahu objektů určených k zobrazení odpovídá příslušná komponenta funkčního celku. Zadavatel nepovažuje za vhodné přenášet business logiku a rozhodování o rozsahu předávaných dat do obecné sdílené GIS platformy poskytující primárně vizualizační služby. Formát předávaných dat bude stanoven v součinnosti s dodavatelem systému AgriGIS. Zadavatel však předpokládá, že prostřednictvím rozhraní budou předávány identifikátory objektů určených k zobrazení, případně jiné údaje nezbytné pro jejich jednoznačnou identifikaci. AgriGIS následně zajistí dohledání odpovídajících geoprostorových prvků a jejich zobrazení na základě údajů evidovaných ve svém datovém úložišti. Ověřování oprávnění uživatele a rozhodování o rozsahu zobrazovaných dat tak zůstává na straně funkčního celku. Zadavatel doplní zadávací dokumentaci tak, aby reflektovala výše uvedené vysvětlení. | ANO | Text doplněn do podkapitoly 2.16. |
|  |  | Historická data a jejich import: Není dostatečně specifikováno, v jakém rozsahu je požadovaná migrace dat ze stávajících systémů.  | Zadavatel doplní zadávací dokumentaci o informace týkající se rozsahu historických dat v agendách ETBD a PP VAK. Zadavatel dále uvádí, že součástí zadávací dokumentace budou také popisy datových struktur a tabulek historických dat. Je přesvědčen, že tyto informace poskytnou dodavatelům dostatečný podklad pro odhad rozsahu migračních prací. Konkrétní způsob migrace a transformace dat bude následně navržen dodavatelem v rámci jím předloženého řešení. | ANO | Text byl doplněn o kapitolu 6.6 zaměřenou na definici rozsahu historických dat v modulu PP VAK, a dále o podkapitolu 8.9 zaměřenou na definici rozsahu historických dat v agendě ETBD. |
|  |  | Kontroly: Zadávací dokumentace předpokládá rozsáhlý systém validačních kontrol. Není však jednoznačně určeno, které kontroly jsou blokující, které mají pouze informativní charakter a jaký je jejich vliv na další zpracování dat. | Konfiguraci závažnosti chyby je možné realizovat v nastavení administrátora. Stanovovat u jednolitých validací jejich závažnost není účelné, protože ho bude možné měnit v tomto rozhaní. Další vysvětlení vlivu chyb na zpracování dat je předmětem požadavků zadávací dokumentace. | NE |  |
|  |  | Atributy / datový model: Zadávací dokumentace na více místech předpokládá doplnění nebo rozšíření evidovaných atributů v rámci implementační analýzy. Není však jednoznačně stanoveno, jaký rozsah změn je ještě považován za zpřesnění zadání a od jakého okamžiku se již jedná o změnu rozsahu plnění.  | Z pohledu zadavatele lze evidovaná data rozdělit na agendová data, jejichž rozsah je definován příslušnými právními předpisy, a systémová data, která slouží k zajištění fungování funkčního celku a poskytování požadovaných funkcí a služeb. V případě agendových dat je jejich rozsah dán příslušnou legislativou. Součástí zadávací dokumentace bude struktura stávající datové základny systému IS VAK i datové základny ETBD. Zadavatel do zadávací dokumentace explicitně uvede, že předpokládaný rozsah agendových dat, se kterým má dodavatel při návrhu řešení počítat, bude odpovídat 150 % současného objemu evidovaných dat. V případě systémových dat je na odbornosti a zkušenostech dodavatele, aby na základě požadovaných funkcionalit a služeb, jakož i své předchozí praxe, kterou mimo jiné prokazuje referenčními zakázkami, navrhl takový datový model, který zajistí řádné fungování požadovaných funkcí a služeb. | NE |  |
|  |  | Exporty: Zadávací dokumentace definuje XML jako výměnný formát pro import některých dat, není však zřejmé, zda je požadována i podpora exportů ve stejném nebo jiném standardizovaném výměnném formátu. Doporučujeme zvážit požadavek na podporu exportů ve formátu XML, případně jednoznačně definovat podporované výměnné formáty jednotlivých komponent. Není jednoznačně specifikován obsah jednotlivých exportů ani rozsah exportovaných atributů. | Zadavatel upřesní dokumentaci s ohledem na formáty exportovaných dat. Zadavatel dále uvádí, že rozsah exportů je volitelný a proměnlivý a souvisí s nastavením rozhraní uživatele. Nebo je naopak dán strukturou záznamu a vychází ze stávající aplikace. | ANO | Text byl doplněno nový požadavek v podkapitole 3.6, který definuje, že detail záznamů bude možné exportovat ve formátech XLSX, XML a PDF. Dále došlo ke sjednocení požadavku na formáty v podkapitole 3.6 v části "Formáty exportu". V jednotlivých modulech a komponentách byly informace ponechány, jen pokud představují nějakou odchylku od těchto požadavků nebo se jedná o specifický příklad exportu. Pokud informace v textu uvedena není, počítá se s možností exportu XLSX a PDF. Zadavatel připomíná, v návaznosti na připomínku, že je nutné definovat obsah jednotlivých exportů, že exporty (v případě seznamů) mají proměnlivý obsah na základě výsledku filtrování. Pokud není filtrování možné exportují se všechny dosupné atributy. Dále v detailu záznamu je možné vyexpotovat všechny atributy. Pokud je někde specificky zvedeno, že funkcionalita vychází ze stávající aplikace, pak rozsah exportu odpovídá stávající aplikaci jejíž instalační soubory budou součástí Zadávací dokumentace. |
|  |  |  |  |  |  |
| Název obchodní společnosti: Dodavatel č. 4 |  |  |  |  |  |
|  |  | Komentář Dodavatele č. 4 | Vysvětlení/Reakce | Zapracováno |  |
|  | Otázky k předmětu plnění |  |  |  |  |
|  | Kapitola 1: Stávající stav ICT zajištění agendy VaK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 2: Požadavky na nový systém |  |  |  |  |
|  |  | 1. identifikace části zadání: a) Záměr vybudování komponent SeD a Jmenný rejstřík se částečně obsahově překrývá s již existujícími systémy v resortu MZe – Společný zemědělský registr SZR a DMS MZe (Spisová služba MZe). 2a) Oba stávající systémy v resortu MZe fungují ve stabilní provozu a pokrývají funkčnosti, které lze v budoucnu z velké části očekávat i po komponentách uvedený v zadávací dokumentaci. 3a) Funkčnosti sice nejsou v této nulové fázi uvedeny, ale je velká pravděpodobnost, že při provozu tyto funkčnosti budou požadovány a MZe bude muset do budoucna řešit rozvoj, a i provoz fakticky totožných systémů. 4a) Zvážit požadavky na architekturu budoucího systému a s využitím existujících systémů snížit nároky na implementaci jak finanční, tak i časovou. | Navržená architektura vychází z požadavků Zadavatele na zajištění požadovaných funkcionalit systému, a to zejména ve vazbě na požadavky Digitální a informační agentury a Národního architektonického rámce. Zadavatel se otázkou využití stávajících resortních systémů zabýval, nicméně po posouzení účelu a požadovaných funkcí jednotlivých komponent a po zpracování SWOT analýzy jednotlivých variant nepředpokládá změnu navržené architektury ani požadovaného rozdělení systému na jednotlivé komponenty. | NE |  |
|  |  | b) Požadavek na migraci dat. 4b) Z podkladů předaných v rámci PTK není dostatečně zřejmý rozsah ani původ dat, které mají být migrovány. Vzhledem k faktu, že analýza cílového řešení teprve má vznikat není jasné jakou formou a jak hodně bude nutné původní data přizpůsobovat novému systému. Pokud by proběhl nejdříve projekt na analýzu cílového systému a až následně projekt na vývoj a migraci (dle analýzy), bude už větší prostor pro přesnější možnost přípravy zadávací dokumentace. | Zadavatel doplní zadávací dokumentaci o informace o počtu evidovaných prvků v jednotlivých agendách. Současně budou součástí podkladů pro realizaci řešení popisy datových struktur a tabulek zdrojových systémů. Zadavatel je přesvědčen, že tyto informace poskytnou dodavatelům dostatečný podklad pro odhad rozsahu migračních prací. Konkrétní způsob migrace a transformace dat bude následně navržen v rámci řešení dodavatele. | ANO | Text byl doplněn o podkapitolu 6.6 zaměřenou na definici rozsahu historických dat v modulu PP VAK, a dále o podkapitolu 8.9 zaměřenou na definici rozsahu historických dat v agendě ETBD. |
|  |  | c) Požadavky na vlastní databázi pro každou komponentu. 2c) V podkladech PTK je uveden požadavek na vlastní databáze pro každou komponentu a není úplně zřejmě, zda tento požadavek znamená samostatné oddělení instance Oracle (s dopady na licenční politiku Oracle a HW požadavky) nebo je možné toto řešit pouze formou DB schémat. | Zadavatel na základě detailního analýzy zhodnotil možnosti provozu databází jednotlivých komponent a optimalizoval svoje požadavky na rozsah, a to při současném zachování požadavků na jejich technologickou oddělitelnost, nezávislý rozvoj a možnost samostatného škálování. Konkrétní požadavky v této oblasti budou v zadávací dokumentaci případně dále upřesněny. | ANO | Text byl doplněn o podkapitolu 2.2.3, která vysvětluje požadavky na členění databází. |
|  |  | 1d) V požadavcích je uvedeno, že nejsou povoleny vazby na databáze jiných komponent. 2d) V resortu MZe je velké množství sdílených datových zdrojů (RUIAN, RPP, číselník útvarů, číselník subjektů, aj. (např. číselníky CUZK – číselník států)) u kterých lze předpokládat, že je bude nový systém využívat. Vyloučením přístupu do těchto sdílených datových zdrojů znamená, že si každá ze 4 nových komponent má udržovat svou vlastní kopii tohoto datového zdroje a zajišťovat aktualizaci tohoto datového zdroje.  | Specifikace požadavku na omezení přímých vazeb mezi databázemi je vedena obecnějším požadavkem na technologickou oddělitelnost jednotlivých komponent, tedy požadavkem na omezení přímých závislostí mezi jejich aplikačními databázemi a zajištění jejich nezávislého rozvoje a provozu. | NE |  |
|  |  | e) Nesoulad počtu běhového prostředí ISVAK a ESB. Nutná součinnost ESB a stanovení cílového řešení za ESB. 2e) V PTK je uvedeno, že prostředí ISVAK bude provozováno na třech prostředích. Dále je uváděna přímá vazba na Agribus. ESB v současné podobě má pouze dvě prostředí a routování komunikací přes 3 prostředí bude vyžadovat úpravy na ESB. 4e) PTK i budoucí zadávací dokumentace, by měla striktně uvádět místa, kdy je vyžadována součinnost po jiném systému, ale zamýšlená funkčnost tohoto systému není v době zadání výběrového řízení funkční. Lze tedy očekávat, že předložená analýza na ISVAK může být revidována, protože MZe nezajistí součinnost u třetí strany. Vhodnější by bylo zadávací dokumentaci uvádět s již před dohodnutým technickým řešením u třetích straně (SEPO, ESB, OracleDB, infrastruktura). Vhodnější je řešit analýzu vlastním projektem, kdy výstupem je již dohodnuté řešení, které je pro všechny strany akceptovatelné a poté vyvíjet SW již do tohoto prostředí – usnadní se jak forma nacenění, tak MZe i aktivně předejte případným implementačním problémům mezi systémy. | Připomínka v bodu e) obsahuje dvě témata: 1) Zadavatel konstatuje, že pro účely integrací bude preprodukční prostředí IS VaK využívat testovací prostředí AgriBus. Tento přístup odpovídá i charakteru navazujících integračních vazeb, kdy jsou na preprodukční prostředí IS VaK napojovány testovací nebo neprodukční instance integrovaných systémů. Zadavatel proto v této oblasti nepředpokládá potřebu dalších úprav ani rozšíření prostředí platformy AgriBus. 2) Zadavatel konstatuje, že součinnost je požadována u všech systémů, které jsou integrovány. V případě prodlení, která nebudou způsobena na straně Dodavatele obsahuje Smlouva mechanismus pro prodloužení termínů dodání v odůvodněných případech. | NE |  |
|  |  | f) Omezený rozsah standardních technologií. 2f) V soupisu standardních technologií MZe neuvádí možnosti použití jazyka python. Jedná se o nejpopulárnější vývojový jazyk v současnosti, a tedy by bylo vhodné upřesnit, zda jej MZe ignoruje z nějakého jasného důvodu. | Standardní technologie uvedené v zadávací dokumentaci vymezují technologie, jejichž licence, instalaci, provoz a maintenance zajišťuje zadavatel. Tento seznam nepředstavuje výčet povolených programovacích jazyků ani technologické omezení pro návrh řešení. Zadavatel použití programovacího jazyka Python nijak nevylučuje ani neomezuje. Volba konkrétních programovacích jazyků a technologií je na dodavateli, pokud jsou splněny požadavky zadávací dokumentace a navržené řešení je v souladu s architektonickými a provozními požadavky zadavatele. | NE |  |
|  |  | g) PTK předpokládá pro autentizaci vlastní nástroj. 2g) V PTK je uvedeno (kapitola 2.5), že se pro autentizaci nevyužije používané SSO, ale Authorization Code Flow. Tento nástroj MZe nyní nemá a MZe nemá funkční ani napojení na CAAIS. 4g) V rámci budoucího zadání na dodávku IS VAK by bylo vhodné uvádět pouze technologie a datové zdroje, které MZe má k dispozici, aby nebyl případný dodavatel překvapen, že popisované řešení v zadávací dokumentaci nelze realizovat z důvodů nedostatků na straně Zadavatele. Napojení mimo stávající SSO přinese komplikace v překlikávání mezi systémy – ISVAK to SEPO, ISVAK to LPIS, SEPO to ISVAK. | Zadavatel hodlá využívat autentizační technologii uvedenou v zadávací dokumentaci, v době realizace projektu budou tyto prvky dostupné. Případné problémy související s její dostupností budou v průběhu realizace projektu řešeny standardními postupy projektového řízení a v souladu se smluvním rámcem, kterým se bude řídit realizace předmětu veřejné zakázky. | NE |  |
|  |  | h) Penetrační testování ze strany Dodavatele. 2h) Pokud Zadavatel provádí své penetrační testování je požadavek bodu 2.13 nadbytečný a zbytečně by celé dílo prodražilo. | Po zvážení připomínek, interních kapacit a rizik souvisejícíh s úpravou, bude provedena úprava požadavku v navrženém smyslu. | ANO | Text byl upraven v podkapitole 2.13, kde došlo ke změně textu zabývajícího se penetračním testováním. |
|  |  | i) Integrace na GIS (kapitola 2.16) 4i) Napojení na systém stávající GIS nástroj LPIS se jeví jako výhodnější než používat AgriGIS. V LPIS je plná podpora pro přihlášení přes SSO a identifikace subjektů ve vazbě na loginy. Možnost práce s různými vrstvami (KN, voda, CRVE), příjem dat z LPIS přes ESB, předávání údaje přes postmessaging (již dnes funguje mezi SEPO a LPIS), možnost práce se SHP a i možnosti kreslení a přenos SHP do ISVAK. Propojení s LPIS umožní i přenos identity uživatele jak je uvedeno ve větě: Toto bude zajištěno prostřednictvím služby vystavené systémem, která na základě identity uživatele vrátí odpovídající množinu dat (např. seznam dostupných prvků nebo jejich identifikátorů).  | Využití platformy AgriGIS vychází z požadavků zadavatele na GIS řešení a z cílové architektury systému. Zadavatel od GIS komponenty požaduje zejména vysokou míru flexibility při zobrazování prostorových dat a možnost škálovatelného začlenění mapových funkcí do jednotlivých modulů a uživatelských rozhraní systému. Zadavatel současně nepředpokládá využití GIS komponenty pro editaci prostorových dat. | NE |  |
|  | Kapitola 3: Základní požadavky na funkční celek |  |  |  |  |
|  |  | 1a) použití zabezpečeného protokolu. 2a) V části logování je uveden požadavek na použití zabezpečeného komunikačního protokolu. Z PTK není jasné, zda zajištění této komunikace je věcí infrastrukturního prostředí MZe nebo si celou organizaci přístupu uživatelů k aplikačním systémům musí řešit Dodavatel sám. | Zajištění infrastrukturních prostředků pro zabezpečenou komunikaci je odpovědností zadavatele. Dodavatel je odpovědný za kompatibilitu dodávaného řešení s těmito prostředky a za podporu využití standardních bezpečných komunikačních protokolů. | NE |  |
|  |  | 1b) využití sdílených číselníků 2b) v části 3.11 je odkaz na číselníky, které již resort v rámci svých systémů sdílí (RPP a číselník ORP). Není smysluplné realizovat v rámci ISVAK (a vlastně samostatně v každé komponentě) replikaci těchto číselníků, a i trvalou aktualizaci. | Specifikace požadavku na omezení přímých vazeb mezi databázemi je vedena obecnějším požadavkem na technologickou oddělitelnost jednotlivých komponent, tedy požadavkem na omezení přímých závislostí mezi jejich aplikačními databázemi a zajištění jejich nezávislého rozvoje a provozu. | NE |  |
|  |  | 1c) funkčnosti SEPO | Popis funkčnosti SEPO bude součástí NDA dokumentace. | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 4: Požadavky na agendovou komponentu – modul MP VAK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1a) Očekávání funkcí, které systémy MZe nemají. 2a) v bodě 4.4 jsou na systém SEPO kladeny funkční požadavky, které systém nyní neposkytuje. PTK by mělo v rámci svého popisu vycházet z funkčností, které Zadavatel již má implementované. V bodě je i uvedeno přesměrování do rozhraní SEPO, které ale vyžaduje jasné sdílení přihlášeného účtu přes SSO a tím předejetí situace odlišného přihlášení v jednotlivých systémech. 3a)Nepřesnosti v PTK a v budoucnu i v zadávací dokumentaci mohou být k tíži dodavatele, který může nabýt dojmu, že funkčnost specifikovaná ze strany Zadavatele je k dispozici a nebude předpokládat, že celou realizaci ISVAK jak analýzu, tak i samotnou dodávku může komplikovat součinnost třetí strany. Zadavatel by měl z důvodů očekávané cenové nabídky na dodání díla přesněji specifikovat, zda v rámci etapy analýzy očekává součinnost se třetí stranou, jak tato bude financována a jak bude řešeno případné prodlení ze strany třetí strany.  | Zadavatel předpokládá, že funkcionality a integrační rozhraní systému SEPO, které jsou v zadávací dokumentaci zohledněny, budou v době realizace projektu dostupné. Zadavatel současně počítá s nezbytnou součinností správců a dodavatelů integrovaných systémů při realizaci integračních vazeb. Skutečnost, že některé související systémy procházejí vlastním rozvojem, není v prostředí rozsáhlých informačních systémů neobvyklá. Zadavatel proto nepovažuje za nutné omezovat návrh cílového řešení výhradně na funkčnosti dostupné ke dni přípravy zadávací dokumentace. Případná koordinace rozvoje navazujících systémů bude zajištěna zadavatelem v rámci realizace projektu.  | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 5: Požadavky na agendovou komponentu – modul VS VAK |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1a) a) Využití SEPO i pro potřeby hlášení přímo do SED. 3a) a) Vytváření vstupních formulářů (a návazné logiky) na dvou místech (SEPO a SED) může být v budoucnu komplikované pro zajištění konzistence a také dvojnásobení nákladů na provoz této části systému. Jako výhodnější se jeví ruční vstup dat také přes SEPO, ale v odlišném režimu, nicméně s využitím stejné struktury formuláře i přenosu dat do ISVAK. | Zadavatel nesouhalsí s Doporučením a ponechá Zadávací dokumentaci v části komponenty SED, resp. její existence a uvažované funkcionality, nezměněnou. | NE |  |
|  |  | 3b) V rámci kapitoly je uvedeno propojení přes ESB VAK a SEPO. Jako hlavní identifikátor subjektů by mělo sloužit SZRID. To sice uvedené v části Jmenného rejstříku je, ale není uveden žádný požadavek na napojení SZR a jeho služby a logiku. Bylo by tedy vhodné do zadávací dokumentace uvést, že napojení na SZR je bezpodmínečně nutné pro funkčnost jak ISVAK, tak i integračních vazeb. | SZRID je součástí komunikace autentizačního a autorizačního systému MZe. Zadavatel doplní integraci na systém SZR, která umožňuí na základě SZRID získat údaje o subjektu a naopak. | ANO | Do pokapitoly 2.4 Integrace systému byl doplněn text o napojení na SZR. |
|  |  |  |  |  |  |
|  | Kapitola 6: Požadavky na agendovou komponentu – modul PP VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 7: Požadavky na agendovou komponentu – modul PR VAK |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 8: Požadavky na agendovou komponentu Evidence technicko bezpečnostního dohledu (ETBD) |  |  |  |  |
|  |  | NIC |  |  |  |
|  |  |  |  |  |  |
|  | Kapitola 9: Požadavky na agendovou komponentu Samostatná evidence dokumentů (SED) |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1a) Vývoj systému nahrazující elektronickou spisovou službu 2a) a) V prostředí MZe již existuje elektronická spisová služba. Vytváření dalšího systému, který tento systém nahrazuje komplikuje celý proces implementace. Lze očekávat, že v první fázi bude SED pokrývat třeba 20% funkčnosti stávajícího systému DMS, ale lze očekávat, že se časem ukáže nutnost rozvoje SED, které ve výsledku budou podobné nebo totožné s DMS, a to bude znamenat provozovat dva velmi shodné systémy a zajišťovat soulad s legislativou. Už jenom tvorba SIP balíčků nebo práce se spisy je operace, kterou lze přes národní standard pro spisové služby vyžadovat po DMS a neřešit toto odděleným systémem. DMS MZe je přes národní standard publikované do ESB a využití služeb národního standardu umožní nahlížet na SED jako na plně transparentní systém, který je přes národní standard dostupný a snadno vyměnitelný. | Navržená architektura vychází z požadavků Zadavatele na zajištění požadovaných funkcionalit systému, a to zejména ve vazbě na požadavky Digitální a informační agentury a Národního architektonického rámce. Zadavatel se otázkou využití stávajících resortních systémů zabýval, nicméně po posouzení účelu a požadovaných funkcí jednotlivých komponent a po zpracování SWOT analýzy jednotlivých variant nepředpokládá změnu navržené architektury s ohledem na komponentu SED. | NE |  |
|  |  |  |  |  |  |
|  | Kapitola 10: Požadavky na komponentu Jmenného rejstříku |  |  |  |  |
|  |  | ANO |  |  |  |
|  |  | 1a) Jmenný rejstřík jako komponenta 2a) Z podstaty se jedná o obdobné funkčnosti, které již dnes nabízí systém SZR, který veškeré očekávané funkčnosti má implementované a pokryté provozní podporou, a hlavně vyjasněné funkčnosti s ohledem na integraci na ISZR a několik agendových systémů. SZRID jakožto jednotný identifikátor může sloužit jak pro práci v SEPO u podání, tak i zpětný identifikátor pro vizualizaci dat v mapě. Lze jej také používat pro vazby na DMS. Se SZRID se níže počítá, a tedy se počítá s propojením na SZR. Je tedy možné využít jak funkčnosti SZR směrem k externím systémů, tak i řešení EXTID s cílem evidence rolí subjektu v dílčích komponentách ISVAK (garant MP VAK nebo referent MP VAK). Pokud by zůstal Jmenný rejstřík je stejně nutné IS VAK napojit na SZR, a tím umožnit držení kontextu subjektu mezi systémy MZe – ISVAK a LPIS nebo SEPO a ISVAK. 4a) Funkčnost Jmenného rejstříku může zastoupit SZR, které poskytuje veškeré funkcionality týkající se subjektů a to jak omezení duplicit, tak i propojení na externí registry a propojení na NIA a DS. | Navržená architektura vychází z požadavků Zadavatele na zajištění požadovaných funkcionalit systému, a to zejména ve vazbě na požadavky Digitální a informační agentury a Národního architektonického rámce. Zadavatel se otázkou využití stávajících resortních systémů zabýval, nicméně po posouzení účelu a požadovaných funkcí jednotlivých komponent a po zpracování SWOT analýzy jednotlivých variant nepředpokládá změnu navržené architektury s ohledem na komponentu SED. | NE |  |
|  |  |  |  |  |  |
| 4.	Otázky k předpokládanému harmonogramu |  |  |  |  |  |
|  | Harmonogram realizace  | NE |  |  |  |
|  |  | Reálné riziko vnímáme ve sloučení analýzy i dodávky do jedné zakázky s fixní cenou. Analýza tak rozsáhlého systému, včetně návrhu integrací, odsouhlasení těchto integrací a zajištění spolupráce třetích stran na úpravy existujících systémů na MZe může celý harmonogram dodávky posunout úplně mimo očekávané mantinely. Až samotná analýza může naznačit, že požadavky kladené ze strany MZe na hotové dílo bude znamenat například navýšení vysoutěžené ceny.  | Zadavatel si je vědom rizik spojených s realizací rozsáhlých informačních systémů. Současně však konstatuje, že realizace veřejných zakázek formou dodávky zahrnující implementační analýzu i následnou implementaci v rámci jednoho projektu představuje běžný postup, který zadavatel dlouhodobě využívá i u dalších informačních systémů. | NE |  |
|  | Možnost zkrácení | NE |  |  |  |
|  |  | S ohledem na velký rozsah součinností ze strany Objednatele vidíme možnost zkrácení reálně pouze v případě aktivního přístupu Objednatele. Jako poskytovatel disponujeme dostatečným vývojovým týmem, abychom část realizovanou čistě v našem režimu dodali co nejdříve. | Zadavatel ponechá možnost nabídnout zkrácení doby realizace a související hodnoticí kritérium. Cílem Zadavatele je umožnit dodavatelům uplatnit jejich zkušenosti, kapacity, know-how a případné vlastní metodické či technologické postupy, které mohou vést k efektivnějšímu průběhu vývoje a rychlejšímu dodání řešení. Rozsah garantované součinnosti poskytované Zadavatelem je popsán v zadávací dokumentaci a Uchazeči by při stanovení nabízených termínů měli vycházet z těchto podmínek. Termín realizace nabídnutý Uchazečem v rámci tohoto hodnoticího kritéria bude pro vybraného dodavatele závazný. Zadavatel si je současně vědom skutečnosti, že v průběhu realizace mohou nastat okolnosti, které dodavatel nemůže objektivně ovlivnit, včetně případných prodlení způsobených na straně Zadavatele. Z tohoto důvodu smlouva obsahuje ustanovení, na jehož základě může dodavatel v odůvodněných případech požádat o prodloužení termínu plnění. Takový požadavek bude posouzen a případně schválen Zadavatelem v souladu se smluvními podmínkami. | NE |  |
|  | Zajištění dodržení harmonogramu | NIC |  |  |  |
|  |  |  |  |  |  |
| 5.	Otázky k požadované technické kvalifikaci |  |  |  |  |  |
|  | Seznam významných služeb |  |  |  |  |
|  | Obecné požadavky na seznam služeb  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Předmět plnění referenční služby | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Požadavek na ISVS | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Služba na dodávku aplikace / IS | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Služba na provoz aplikace / IS | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  | Seznam členů realizačního týmu a jejich kvalifikace |  |  |  |  |
|  | (1) Obecné požadavky na realizační tým | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (2) Minimálně jedna (1) osoba v kategorii role Solution Architekt splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (3)Minimálně jedna (1) osoba v kategorii role Aplikační architekt splňující následující požadavky:  | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (4) Minimálně jedna (1) osoba v kategorii role Projektový manažer splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (5) Minimálně dvě (2) osoby v kategorii role Analytik IT senior splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (6) Minimálně pět (5) osob v kategorii role Vývojář splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (7) Minimálně jedna (1) osoba v kategorii role Tester splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (8) Minimálně jedna (1) osoba v kategorii role Bezpečnostní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (9) Minimálně jedna (1) osoba v kategorii role Manažer provozu splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (10) Minimálně dvě (2) osoby v kategorii role Provozní specialista splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (11) Minimálně jedna (1) osoba v kategorii role Specialista uživatelské podpory splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  | (12) Minimálně jedna (1) osoba v kategorii role SCRUM master splňující následující požadavky: | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
| 6.	Otázky ke kritériím hodnocení |  |  |  |  |  |
|  | Celková nabídková cena: 30 % | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Návrh vybraných částí řešení: 30 % | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Prokázání odborných znalostí: 30 % | NE |  |  |  |
|  |  | Prokazování technických dovedností členů týmu v oblastech, které jsou předmětem odborných testů v rámci certifikace a jsou prokázány účastí na úspěšně realizovaných referenčních zakázkách nedává smysl. Smysl dává pouze ověřování znalostí týkající se oblastí uvedeného zákona a vyhlášky pro Analytik IT senior. | Zadavatel s připomínkou nesouhlasí. Zadavatel je v případě tohoto projektu přesvědčen, že je účelné ověřit odborné znalosti členů realizačního týmu přímým způsobem. Referenční zakázky a certifikace sice prokazují předchozí zkušenosti a dosaženou odbornou úroveň, nezaručují však aktuální znalost problematiky ani znalost konkrétních principů a požadavků relevantních pro předmět této veřejné zakázky. | NE |  |
|  | Urychlení vývoje a dodání vybraných modulů: 10 % | NE |  |  |  |
|  |  | Je to možné, ale plnění kritéria je z velké části závislé na cílovém prostředí, jehož součástí je i dodávaný systém a urychlení vývoje tak není pouze v režii Dodavatele. Urychlení vývoje znamená i adekvátní poskytnutí součinnosti ze strany Zadavatele. Může se tak jednat pouze o deklarativní slib jednoho dodavatele, že to lze, ale ve výsledku není možné slib splnit. | Rozsah součinnosti Zadavatele je specifikován v zadávací dokumentaci. Zadavatel současně ponechává na posouzení jednotlivých uchazečů, zda a jakým způsobem jsou schopni dosáhnout zkrácení harmonogramu realizace. Odpovědnost za splnění navrženého harmonogramu a řádnou realizaci funkčního celku nese plně dodavatel. Zadavatel dále uvádí, že připravovaná smlouva obsahuje ustanovení, na jehož základě může dodavatel v odůvodněných případech požádat o prodloužení termínu plnění. Takový požadavek však podléhá schválení zadavatelem. | NE |  |
| 7.	Další otázky zadavatele |  |  |  |  |  |
|  | Předpokládaná hodnota zakázky | NE |  |  |  |
|  |  | Při zohlednění očekávaného rozvoje v rozsahu 2760 MD, 50 MD součinnosti, dodání analýzy, dodání díla, migrace dat, pilotních provozů, školeních, školících materiálů a zajištění provozní podpory díla s podporou koncových uživatelů se předpokládaná hodnota zakázky jeví jako velmi nízká a nepřiměřená. | Zadavatel upravil předpokládanou hodnotu veřejné zakázky (původně vypočtenou na základě nabídek předchozího zadávacího řízení) na základě aktualizovaných údajů Ceníku ICT prací. V důsledku změny průměrné ceny za ad hoc plnění došlo k navýšení předpokládané hodnoty veřejné zakázky. Limit pro výši nabídkové ceny byl na základě PTK zrušen, nabídková cena tedy může přesáhnout předpokládanou hodnotu VZ. | ANO | Úprava podmínek uvedených v zadávací dokumentaci. |
|  | Limity pro nabídkovou cenu | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Platební podmínky | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Bankovní záruka | ANO |  |  |  |
|  |  |  |  |  |  |
|  | Lhůta pro podání nabídek | ANO |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
| Další připomínky mimo formulář |  | Nejsou |  |  |  |