Procurement observatory.

<!-- PAGE 1 -->**VYSVĚTLENÍ ZADÁVACÍ DOKUMENTACE Zadavatel: Česká agentura pro standardizaci, státní příspěvková organizace**

se sídlem Biskupský dvůr 1148/5, 110 00 Praha 1 IČO: 06578705 V Praze dne 22. 10. 2026

**VEŘEJNÁ ZAKÁZKA: „ČAS – Elektronický systém spisové služby"**

Zadavatel tímto poskytuje **vysvětlení zadávací dokumentace č. 1** k nadlimitní veřejné zakázce na služby zadávané v otevřeném řízení s názvem „

**ČAS – Elektronický systém spisové služby"**

, systémové číslo NEN N006/26/V00033924, evidenční číslo zakázky ve VVZ: Z2026-056348. Vysvětlení zadávací dokumentace je poskytováno na základě žádosti obdržené dne 19. 10. 2026.

**Dotaz č. 1:**

*„Vážení, jako dodavatel působící v oblasti elektronické správy dokumentů se obracíme na zadavatele s žádostí o vysvětlení zadávacích podmínek. Po prostudování přílohy č. 2, přílohy č. 10 a návrhu smlouvy máme vážné pochybnosti, zda bodové zvýhodnění konkrétní technologie uživatelského rozhraní sleduje objektivní užitnou hodnotu a respektuje přiměřenou otevřenost hospodářské soutěže.*

1. *Objektivní zdůvodnění bodového zvýhodnění nativní aplikace Příloha č. 10 pro totožných dvanáct uživatelských scénářů PP03–PP14 stanoví 2 body za nativní aplikaci a 1 bod za responzivní webové rozhraní, včetně PWA. Při úplném funkčním splnění všech scénářů tak vzniká rozdíl 10 bodů ze 100, tedy poloviny celého kvalitativního kritéria. Žádný z popsaných kroků přitom zjevně nevyžaduje výhradně nativní vlastnost operačního systému: jde o zobrazování, formulářové vyjádření či rozhodnutí, práci s metadaty a elektronický podpis, pro který pravidla sama připouštějí vyvolání externí podpisové služby. Jaké konkrétní, měřitelné provozní, bezpečnostní či uživatelské výhody nativní aplikace odůvodňují dvojnásobné hodnocení i při prokazatelně identických výsledcích všech scénářů? Proč nebyl jako hodnoticí parametr zvolen přímo požadovaný funkční nebo kvalitativní výsledek místo technologie jeho realizace?"*

**Odpověď č. 1:**

**Dostupnost podpisové knihy na mobilních zařízeních je pro vedoucí pracovníky zadavatele zásadní, a proto je předmětem samostatného hodnoticího kritéria. Zadavatel preferuje nativní aplikaci, která poskytuje samostatné pracovní prostředí**

<!-- PAGE 2 -->**přímo v mobilním zařízení. S ohledem na zachování širší hospodářské soutěže však připustil také responzivní webové rozhraní.**

**Bodovým rozlišením zadavatel vyjadřuje význam preferovaného způsobu mobilního zpřístupnění. Hodnoceno je tedy vedle splnění jednotlivých funkcí také prostředí, v němž je uživatel využívá. Možnost vyvolání externí podpisové služby na tomto rozlišení nic nemění.**

**Dotaz č. 2:**

*„2. Přiměřenost a průzkum trhu Žádáme, aby zadavatel vysvětlil, z jakých podkladů vycházel při stanovení hodnoticího rozdílu a jak ověřil jeho dopad na hospodářskou soutěž. Kolik dostupných produktů eSSL na trhu dokáže podle zadavateli známých skutečností předvést všech 12 scénářů v nativní aplikaci a kolik v plnohodnotném responzivním webu? Proběhla před vyhlášením soutěže předběžná tržní konzultace nebo jiné posouzení dostupnosti takových řešení? Nežádáme důvěrné obchodní informace ani jména dodavatelů, nýbrž konkrétní vysvětlení objektivního podkladu a úvahy zadavatele pro takto podstatnou bodovou asymetrii. Jak zadavatel vyloučil riziko, že kritérium bez prokazatelné užitné hodnoty fakticky zvýhodní jediného či úzký okruh výrobců?"*

**Odpověď č. 2: Zadavatel stanovil požadavky a jejich bodové hodnocení s ohledem na své objektivní provozní potřeby a význam mobilní podpisové knihy pro vedoucí pracovníky. Obdobné požadavky se vyskytují také v jiných veřejných zakázkách, například v zakázce na elektronický systém spisové služby pro Úřad vlády České republiky dostupné na https://zakazky.vlada.cz/contract_display_1388.html.**

**Zadavatel připouští nativní i responzivní webové řešení a nestanoví konkrétního výrobce ani vývojový framework. Bodové zvýhodnění se vztahuje k vlastnostem nabízeného řešení a uplatní se shodně vůči všem účastníkům.**

**Dotaz č. 3:**

*„3. Žádost o zvážení změny Žádáme zadavatele, aby znovu posoudil přiměřenost kritéria a zvážil jeho úpravu tak, aby funkčně, uživatelsky a bezpečnostně rovnocenné mobilní provedení získalo stejné body. Pokud zadavatel na rozlišení trvá, žádáme o výslovné a přezkoumatelné zdůvodnění poměru 2:1 i váženého rozdílu 10 bodů a jeho vztahu k potřebám zadavatele."*

**Odpověď č. 3:**

<!-- PAGE 3 -->**Zadavatel přiměřenost kritéria opětovně posoudil a na stanovených podmínkách trvá. Poměr 2 : 1 vyjadřuje preferenci nativního mobilního klienta z důvodů uvedených v odpovědi č. 1. Rozdíl nejvýše 10 bodů v celkovém hodnocení odpovídá významu tohoto způsobu zpřístupnění podpisové knihy pro zadavatele. Zadavatel proto ke změně hodnoticího kritéria nepřistupuje.**

**Dotaz č. 4:**

*„4. Složené řešení a hranice atestace Technická specifikace obsahuje nadstandardní podpisovou knihu a agendové workflow (zejména FP131–FP133, FP144, FP165–FP169) a připouští řešení využívající produkty třetích stran. Potvrzuje zadavatel, že jsou přípustné samostatné integrované procesní a mobilní komponenty odlišného výrobce od základního atestovaného eSSL, pokud celek naplní všechny požadavky a zachová soulad atestovaného eSSL? Pokud by zadavatel takovou architekturu vylučoval, žádáme o konkrétní právní či technické ustanovení, z něhož omezení vyplývá. Jakým důkazem může dodavatel prokázat zachování rozsahu atestu při integraci nadstandardních funkcí, které samy nejsou povinnými funkcemi eSSL?"*

**Odpověď č. 4: Zadavatel potvrzuje, že jsou přípustné samostatné integrované procesní a mobilní komponenty odlišného výrobce od výrobce základního atestovaného eSSL, pokud řešení jako celek splní všechny zadávací požadavky a integrace zachová soulad eSSL s požadavky na atestaci. Prokazování existence, platnosti a rozsahu atestu se řídí požadavky návrhu smlouvy. Vztah integrovaných komponent k atestovanému eSSL lze podle konkrétního řešení objasnit technickou dokumentací nebo vyjádřením výrobce; tyto podklady samotný atest nenahrazují. Dotaz č. 5:**

*„5. Technologické vymezení nativního klienta Návrh smlouvy odmítá PWA i funkcionalitu realizovanou pouze vloženým webovým rozhraním. Prosíme o potvrzení, že je jako nativní aplikace způsobilý i klient vytvořený multiplatformním frameworkem (např. React Native), jehož uživatelské obrazovky jsou vykreslovány nativními prvky operačního systému, zatímco obchodní logika, metadata, workflow a vzdálené podpisové služby jsou provozovány na backendu. Zadavatel tím nebude zvýhodňovat žádný konkrétní mobilní vývojový framework?*

<!-- PAGE 4 -->*Žádáme o uveřejnění vysvětlení v souladu s § 98 ZZVZ a případnou úpravu zadávací dokumentace podle § 99 ZZVZ tak, aby měli všichni dodavatelé srovnatelné podmínky pro přípravu nabídek."*

**Odpověď č. 5: Zadavatel potvrzuje, že jako nativní aplikace může být způsobilý také klient vytvořený multiplatformním frameworkem, například React Native, pokud splní všechny stanovené požadavky. Provozování obchodní logiky, metadat, workflow a podpisových služeb na serverové straně tomu nebrání. Zadavatel nezvýhodňuje konkrétní vývojový framework. Nadále platí vymezení nativní aplikace podle zadávacích a smluvních podmínek, včetně odlišení od PWA a funkcionality realizované pouze vloženým webovým rozhraním.**

S úctou

1. s. JUDr. Jakub Klatovský, LL.M., advokát

**Advokátní kancelář Bártová Frk Česká agentura pro standardizaci, státní příspěvková organizace**

Mgr. Zdeněk Veselý, generální ředitel

Page 1

**VYSVĚTLENÍ ZADÁVACÍ DOKUMENTACE Zadavatel: Česká agentura pro standardizaci, státní příspěvková organizace**

se sídlem Biskupský dvůr 1148/5, 110 00 Praha 1 IČO: 06578705 V Praze dne 22. 10. 2026

**VEŘEJNÁ ZAKÁZKA: „ČAS – Elektronický systém spisové služby"**

Zadavatel tímto poskytuje **vysvětlení zadávací dokumentace č. 1** k nadlimitní veřejné zakázce na služby zadávané v otevřeném řízení s názvem „

**ČAS – Elektronický systém spisové služby"**

, systémové číslo NEN N006/26/V00033924, evidenční číslo zakázky ve VVZ: Z2026-056348. Vysvětlení zadávací dokumentace je poskytováno na základě žádosti obdržené dne 19. 10. 2026.

**Dotaz č. 1:**

*„Vážení, jako dodavatel působící v oblasti elektronické správy dokumentů se obracíme na zadavatele s žádostí o vysvětlení zadávacích podmínek. Po prostudování přílohy č. 2, přílohy č. 10 a návrhu smlouvy máme vážné pochybnosti, zda bodové zvýhodnění konkrétní technologie uživatelského rozhraní sleduje objektivní užitnou hodnotu a respektuje přiměřenou otevřenost hospodářské soutěže.*

1. *Objektivní zdůvodnění bodového zvýhodnění nativní aplikace Příloha č. 10 pro totožných dvanáct uživatelských scénářů PP03–PP14 stanoví 2 body za nativní aplikaci a 1 bod za responzivní webové rozhraní, včetně PWA. Při úplném funkčním splnění všech scénářů tak vzniká rozdíl 10 bodů ze 100, tedy poloviny celého kvalitativního kritéria. Žádný z popsaných kroků přitom zjevně nevyžaduje výhradně nativní vlastnost operačního systému: jde o zobrazování, formulářové vyjádření či rozhodnutí, práci s metadaty a elektronický podpis, pro který pravidla sama připouštějí vyvolání externí podpisové služby. Jaké konkrétní, měřitelné provozní, bezpečnostní či uživatelské výhody nativní aplikace odůvodňují dvojnásobné hodnocení i při prokazatelně identických výsledcích všech scénářů? Proč nebyl jako hodnoticí parametr zvolen přímo požadovaný funkční nebo kvalitativní výsledek místo technologie jeho realizace?"*

**Odpověď č. 1:**

**Dostupnost podpisové knihy na mobilních zařízeních je pro vedoucí pracovníky zadavatele zásadní, a proto je předmětem samostatného hodnoticího kritéria. Zadavatel preferuje nativní aplikaci, která poskytuje samostatné pracovní prostředí**

Page 2

**přímo v mobilním zařízení. S ohledem na zachování širší hospodářské soutěže však připustil také responzivní webové rozhraní.**

**Bodovým rozlišením zadavatel vyjadřuje význam preferovaného způsobu mobilního zpřístupnění. Hodnoceno je tedy vedle splnění jednotlivých funkcí také prostředí, v němž je uživatel využívá. Možnost vyvolání externí podpisové služby na tomto rozlišení nic nemění.**

**Dotaz č. 2:**

*„2. Přiměřenost a průzkum trhu Žádáme, aby zadavatel vysvětlil, z jakých podkladů vycházel při stanovení hodnoticího rozdílu a jak ověřil jeho dopad na hospodářskou soutěž. Kolik dostupných produktů eSSL na trhu dokáže podle zadavateli známých skutečností předvést všech 12 scénářů v nativní aplikaci a kolik v plnohodnotném responzivním webu? Proběhla před vyhlášením soutěže předběžná tržní konzultace nebo jiné posouzení dostupnosti takových řešení? Nežádáme důvěrné obchodní informace ani jména dodavatelů, nýbrž konkrétní vysvětlení objektivního podkladu a úvahy zadavatele pro takto podstatnou bodovou asymetrii. Jak zadavatel vyloučil riziko, že kritérium bez prokazatelné užitné hodnoty fakticky zvýhodní jediného či úzký okruh výrobců?"*

**Odpověď č. 2: Zadavatel stanovil požadavky a jejich bodové hodnocení s ohledem na své objektivní provozní potřeby a význam mobilní podpisové knihy pro vedoucí pracovníky. Obdobné požadavky se vyskytují také v jiných veřejných zakázkách, například v zakázce na elektronický systém spisové služby pro Úřad vlády České republiky dostupné na https://zakazky.vlada.cz/contract_display_1388.html.**

**Zadavatel připouští nativní i responzivní webové řešení a nestanoví konkrétního výrobce ani vývojový framework. Bodové zvýhodnění se vztahuje k vlastnostem nabízeného řešení a uplatní se shodně vůči všem účastníkům.**

**Dotaz č. 3:**

*„3. Žádost o zvážení změny Žádáme zadavatele, aby znovu posoudil přiměřenost kritéria a zvážil jeho úpravu tak, aby funkčně, uživatelsky a bezpečnostně rovnocenné mobilní provedení získalo stejné body. Pokud zadavatel na rozlišení trvá, žádáme o výslovné a přezkoumatelné zdůvodnění poměru 2:1 i váženého rozdílu 10 bodů a jeho vztahu k potřebám zadavatele."*

**Odpověď č. 3:**

Page 3

**Zadavatel přiměřenost kritéria opětovně posoudil a na stanovených podmínkách trvá. Poměr 2 : 1 vyjadřuje preferenci nativního mobilního klienta z důvodů uvedených v odpovědi č. 1. Rozdíl nejvýše 10 bodů v celkovém hodnocení odpovídá významu tohoto způsobu zpřístupnění podpisové knihy pro zadavatele. Zadavatel proto ke změně hodnoticího kritéria nepřistupuje.**

**Dotaz č. 4:**

*„4. Složené řešení a hranice atestace Technická specifikace obsahuje nadstandardní podpisovou knihu a agendové workflow (zejména FP131–FP133, FP144, FP165–FP169) a připouští řešení využívající produkty třetích stran. Potvrzuje zadavatel, že jsou přípustné samostatné integrované procesní a mobilní komponenty odlišného výrobce od základního atestovaného eSSL, pokud celek naplní všechny požadavky a zachová soulad atestovaného eSSL? Pokud by zadavatel takovou architekturu vylučoval, žádáme o konkrétní právní či technické ustanovení, z něhož omezení vyplývá. Jakým důkazem může dodavatel prokázat zachování rozsahu atestu při integraci nadstandardních funkcí, které samy nejsou povinnými funkcemi eSSL?"*

**Odpověď č. 4: Zadavatel potvrzuje, že jsou přípustné samostatné integrované procesní a mobilní komponenty odlišného výrobce od výrobce základního atestovaného eSSL, pokud řešení jako celek splní všechny zadávací požadavky a integrace zachová soulad eSSL s požadavky na atestaci. Prokazování existence, platnosti a rozsahu atestu se řídí požadavky návrhu smlouvy. Vztah integrovaných komponent k atestovanému eSSL lze podle konkrétního řešení objasnit technickou dokumentací nebo vyjádřením výrobce; tyto podklady samotný atest nenahrazují. Dotaz č. 5:**

*„5. Technologické vymezení nativního klienta Návrh smlouvy odmítá PWA i funkcionalitu realizovanou pouze vloženým webovým rozhraním. Prosíme o potvrzení, že je jako nativní aplikace způsobilý i klient vytvořený multiplatformním frameworkem (např. React Native), jehož uživatelské obrazovky jsou vykreslovány nativními prvky operačního systému, zatímco obchodní logika, metadata, workflow a vzdálené podpisové služby jsou provozovány na backendu. Zadavatel tím nebude zvýhodňovat žádný konkrétní mobilní vývojový framework?*

Page 4

*Žádáme o uveřejnění vysvětlení v souladu s § 98 ZZVZ a případnou úpravu zadávací dokumentace podle § 99 ZZVZ tak, aby měli všichni dodavatelé srovnatelné podmínky pro přípravu nabídek."*

**Odpověď č. 5: Zadavatel potvrzuje, že jako nativní aplikace může být způsobilý také klient vytvořený multiplatformním frameworkem, například React Native, pokud splní všechny stanovené požadavky. Provozování obchodní logiky, metadat, workflow a podpisových služeb na serverové straně tomu nebrání. Zadavatel nezvýhodňuje konkrétní vývojový framework. Nadále platí vymezení nativní aplikace podle zadávacích a smluvních podmínek, včetně odlišení od PWA a funkcionality realizované pouze vloženým webovým rozhraním.**

S úctou

1. s. JUDr. Jakub Klatovský, LL.M., advokát

**Advokátní kancelář Bártová Frk Česká agentura pro standardizaci, státní příspěvková organizace**

Mgr. Zdeněk Veselý, generální ředitel