číslo jednací: 48649/2023/500
spisová značka: S0312/2023

• Instance: I.
• Věc: Vývoj a technická podpora webového klienta pro NCTS, AES a eDovoz
• Účastníci:
  1. Česká republika – Generální ředitelství cel
  2. HAWIKK CZ, s. r. o.
• Typ správního řízení: Veřejná zakázka
• Výrok: § 66 odst. 1 písm. b) zákona č. 500/2004 Sb.
• Rok: 2023
• Datum nabytí právní moci: 23. 12. 2023 (výrok VI. rozhodnutí)
• Související rozhodnutí: 48649/2023/500; 07818/2024/161

Spisová značka:  ÚOHS-S0312/2023/VZ Číslo jednací:      ÚOHS-48649/2023/500

Brno 6. 12. 2023

Úřad pro ochranu hospodářské soutěže příslušný podle § 248 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, ve správním řízení zahájeném dne 29. 5. 2023 na návrh z téhož dne, jehož účastníky jsou:

• zadavatel – Česká republika – Generální ředitelství cel, IČO 71214011, se sídlem Budějovická 1387/7, 140 00 Praha 4,
• navrhovatel – HAWIKK CZ s.r.o., IČO 11925388, se sídlem Fibichova 55, 261 01 Příbram, ve správním řízení zastoupena na základě plné moci ze dne 4. 5. 2023 JUDr. Janem Boltnarem, Ph.D., advokátem, ev. č. ČAK 13948, se sídlem Růžová 972/1, 110 00 Praha 1,

ve věci přezkoumání úkonů zadavatele učiněných v otevřeném řízení zahájeném za účelem uzavření rámcové dohody „Vývoj a technická podpora webového klienta pro NCTS, AES a eDovoz“, jehož oznámení bylo odesláno k uveřejnění dne 3. 4. 2023 a uveřejněno ve Věstníku veřejných zakázek dne 5. 4. 2023 pod ev. č. Z2023-012786 a v Úředním věstníku Evropské unie dne 7. 4. 2023 pod ev. č. 2023/S 070-213108,

rozhodl takto:

I.

Zadavatel – Česká republika – Generální ředitelství cel, IČO 71214011, se sídlem Budějovická 1387/7, 140 00 Praha 4 – stanovil zadávací podmínky otevřeného řízení zahájeného za účelem uzavření rámcové dohody „Vývoj a technická podpora webového klienta pro NCTS, AES a eDovoz“, jehož oznámení bylo odesláno k uveřejnění dne 3. 4. 2023 a uveřejněno ve Věstníku veřejných zakázek dne 5. 4. 2023 pod ev. č. Z2023-012786 a v Úředním věstníku Evropské unie dne 7. 4. 2023 pod ev. č. 2023/S 070-213108, v rozporu s § 36 odst. 1 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, v rozhodném znění, ve spojení s § 73 odst. 6 písm. b) citovaného zákona a zásadami přiměřenosti a zákazu diskriminace zakotvenými v § 6 odst. 1 a odst. 2 citovaného zákona tím, že nestanovil minimální úroveň pro splnění kritérií technické kvalifikace přiměřeně vzhledem ke složitosti a rozsahu předmětu uzavírané rámcové dohody, když v rámci požadavků na technickou kvalifikaci podle § 79 odst. 2 písm. b) citovaného zákona stanovil v kapitole VI. „Podmínky kvalifikace“ části (1) odst. C) „Technické kvalifikace podle § 79 odst. 2 písm. b) ZZVZ“ písmene a) zadávací dokumentace požadavek na prokázání nejméně dvou realizovaných významných služeb mimo jiné tak, že jejich předmětem musel být vývoj webového řešení, které muselo umožňovat identifikaci uživatele napojením na Národní Identitní Autoritu (NIA) a Informační systém datových schránek (ISDS), aniž by pro takto stanovenou minimální úroveň požadovaných významných služeb existoval objektivní důvod, a tedy nevymezil minimální úroveň tohoto kritéria technické kvalifikace v souladu se zásadou přiměřenosti a zásadou zákazu diskriminace tak, aby odpovídala rozsahu a složitosti předmětu plnění rámcové dohody, čímž vytvořil bezdůvodné překážky hospodářské soutěže, a mohl tak omezit okruh potenciálních dodavatelů.

II.

Zadavatel – Česká republika – Generální ředitelství cel, IČO 71214011, se sídlem Budějovická 1387/7, 140 00 Praha 4 – stanovil zadávací podmínky otevřeného řízení zahájeného za účelem uzavření rámcové dohody „Vývoj a technická podpora webového klienta pro NCTS, AES a eDovoz“, jehož oznámení bylo odesláno k uveřejnění dne 3. 4. 2023 a uveřejněno ve Věstníku veřejných zakázek dne 5. 4. 2023 pod ev. č. Z2023-012786 a v Úředním věstníku Evropské unie dne 7. 4. 2023 pod ev. č. 2023/S 070-213108, v rozporu s § 36 odst. 3 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, v rozhodném znění, ve spojení se zásadou transparentnosti zakotvenou v § 6 odst. 1 citovaného zákona, když v kapitole VI. „Podmínky kvalifikace“ části (1) odst. D) „Technické kvalifikace podle § 79 odst. 2 písm. c) ZZVZ“ písmene c)  „2 vývojoví pracovníci pro portálové technologie“ zadávací dokumentace stanovil pro tyto členy týmu požadavek spočívající v tom, že oba vývojoví pracovníci musí být držiteli „mezinárodní certifikace v oblasti portálového řešení“, aniž by tento neurčitý pojem blíže vymezil a byl tedy jednoznačný a dostatečně konkrétní, tj. nepřipouštějící rozdílné výklady, a tedy nestanovil zadávací podmínky v podrobnostech nezbytných pro účast dodavatele v předmětném zadávacím řízení.

III.

Jako opatření k nápravě nezákonného postupu zadavatele – Česká republika – Generální ředitelství cel, IČO 71214011, se sídlem Budějovická 1387/7, 140 00 Praha 4 - uvedeného ve výrocích I. a II. tohoto rozhodnutí Úřad pro ochranu hospodářské soutěže podle § 263 odst. 3 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, v rozhodném znění, ruší zadávací řízení zahájené za účelem uzavření rámcové dohody „Vývoj a technická podpora webového klienta pro NCTS, AES a eDovoz“, jehož oznámení bylo odesláno k uveřejnění dne 3. 4. 2023 a uveřejněno ve Věstníku veřejných zakázek dne 5. 4. 2023 pod ev. č. Z2023-012786 a v Úředním věstníku Evropské unie dne 7. 4. 2023 pod ev. č. 2023/S 070-213108.

IV.

Zadavateli – Česká republika – Generální ředitelství cel, IČO 71214011, se sídlem Budějovická 1387/7, 140 00 Praha 4 – se podle § 263 odst. 8 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, v rozhodném znění, až do pravomocného skončení správního řízení vedeného Úřadem pro ochranu hospodářské soutěže pod sp. zn. ÚOHS-S0312/2023/VZ ve věci návrhu navrhovatele            – HAWIKK CZ s.r.o., IČO 11925388, se sídlem Fibichova 55, 261 01 Příbram– ze dne  29. 5. 2023 na zahájení řízení o přezkoumání úkonů zadavatele, ukládá zákaz uzavřít smlouvu v otevřeném řízení zahájeném za účelem uzavření rámcové dohody „Vývoj a technická podpora webového klienta pro NCTS, AES a eDovoz“, jehož oznámení bylo odesláno k uveřejnění dne 3. 4. 2023 a uveřejněno ve Věstníku veřejných zakázek dne 5. 4. 2023 pod ev. č. Z2023-012786 a v Úředním věstníku Evropské unie dne 7. 4. 2023 pod ev. č. 2023/S 070-213108.

V.

Podle § 266 odst. 1 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, v rozhodném znění, v návaznosti na § 1 vyhlášky č. 170/2016 Sb., o stanovení paušální částky nákladů řízení o přezkoumání úkonů zadavatele při zadávání veřejných zakázek, se zadavateli – Česká republika – Generální ředitelství cel, IČO 71214011, se sídlem Budějovická 1387/7, 140 00 Praha 4 – ukládá povinnost

uhradit náklady řízení ve výši 30 000,- Kč (třicet tisíc korun českých).

Náklady řízení jsou splatné do dvou měsíců od nabytí právní moci tohoto rozhodnutí.

VI.

Správní řízení vedené ve věci návrhu navrhovatele – HAWIKK CZ s.r.o., IČO 11925388, se sídlem Fibichova 55, 261 01 Příbram – ze dne 29. 5. 2023 na zahájení řízení o přezkoumání úkonů zadavatele – Česká republika – Generální ředitelství cel, IČO 71214011, se sídlem Budějovická 1387/7, 140 00 Praha 4  – učiněných v otevřeném řízení zahájeném za účelem uzavření rámcové dohody „Vývoj a technická podpora webového klienta pro NCTS, AES a eDovoz“, jehož oznámení bylo odesláno k uveřejnění dne 3. 4. 2023 a uveřejněno ve Věstníku veřejných zakázek dne 5. 4. 2023 pod ev. č. Z2023-012786 a v Úředním věstníku Evropské unie dne 7. 4. 2023 pod ev. č. 2023/S 070-213108, se v části týkající se požadavku cit. navrhovatele, aby Úřad pro ochranu hospodářské soutěže uložil cit. zadavateli  povinnost nahradit navrhovateli náklady řízení, které mu vznikly v souvislosti s jeho zastoupení advokátem, podle § 66 odst. 1 písm. b) zákona č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů, zastavuje, neboť žádost (návrh) cit. navrhovatele je v této části zjevně právně nepřípustná.

Odůvodnění

I.               POSTUP ZADAVATELE V ZADÁVACÍM ŘÍZENÍ

1.             Zadavatel – Česká republika – Generální ředitelství cel, IČO 71214011, se sídlem Budějovická 1387/7, 140 00 Praha 4 (dále jen „zadavatel") – jakožto veřejný zadavatel ve smyslu § 4 odst. 1 písm. a) zákona č. 134/2016 Sb., o zadávání veřejných zakázek, v rozhodném znění (dále jen „zákon") zahájil dne 3. 4. 2023 otevřené řízení zahájené za účelem uzavření rámcové dohody „Vývoj a technická podpora webového klienta pro NCTS, AES a eDovoz“, jehož oznámení bylo odesláno k uveřejnění dne 3. 4. 2023 a uveřejněno ve Věstníku veřejných zakázek dne 5. 4. 2023 pod ev. č. Z2023-012786 a v Úředním věstníku Evropské unie dne 7. 4. 2023 pod ev.  č.  2023/S 070-213108 (dále jen „rámcová dohoda“ a „zadávací řízení“).

2.             V kapitole II. „Předmět veřejné zakázky“ zadávací dokumentace zadavatel specifikoval předmět plnění jako: „vývoj a technická podpora webového klienta pro NCTS, AES a eDovoz pro obchodní veřejnost, kterého poskytuje CS ČR malým a středním podnikům zdarma, na základě nových legislativních a technických požadavků, požadavků uživatelů aplikace, požadavků týkajících se propojení aplikace s jinými aplikacemi informačního systému CS ČR a dalších požadavků. Zadavatel zamýšlí jednotlivé fáze vývoje objednávat postupně na základě dílčích objednávek. Z důvodu nezbytné technické jednotnosti vyvíjené aplikace webového klienta a současně předpokládané doby nutné na realizaci předmětu zadávacího řízení je nezbytné, aby délka smluv byla delší než 4 roky.“

3.             Z kapitoly IV. „Požadavky na způsob zpracování nabídkové ceny“ části (5) písmene a) a b) zadávací dokumentace je zřejmé, že předpokládaná hodnota plnění z rámcové dohody je 21 898 500,- Kč bez DPH za služby vývoje systému webového klienta pro NCTS, AES a eDovoz a 18 648 000,- Kč bez DPH za služby technické podpory webového klienta pro NCTS, AES a eDovoz. Celková předpokládaná hodnota plnění z rámcové dohody tedy představuje 40 546 500,- Kč bez DPH.

4.             V kapitole VI. „Podmínky kvalifikace“ části (1) odst. C) „Technické kvalifikace podle § 79 odst. 2 písm. b) ZZVZ“ písmene a) zadávací dokumentacevymezil zadavatel požadavek na prokázání technické kvalifikace spočívající v předložení seznamu významných služeb, ze kterého musí vyplývat, že dodavatel poskytl: „nejméně 2 (dvě) významné služby, jejichž předmětem byl vývoj webového řešení (zahrnující analýzu, návrh řešení, realizaci, testování, uvedení do provozu) pro elektronická podání, včetně tvorby xml zpráv, přičemž řešení muselo umožnit identifikaci uživatele napojením na Národní Identitní Autoritu (NIA) a Informační systém datových schránek (ISDS). Každá z těchto významných služeb musí splňovat následující požadavky:

• významná služba byla poskytnuta dodavatelem za posledních 6 let před zahájením zadávacího řízení (počítáno zpětně ode dne zahájení zadávacího řízení, dále jen ,rozhodné období´).
• významná služba dosahovala hodnoty minimálně 5 000 000,- Kč vč. DPH, přičemž alespoň část významné služby odpovídající požadované minimální hodnotě (5 000 000,- Kč vč. DPH) byla realizována v rozhodném období.“

5.             V kapitole VI. „Podmínky kvalifikace“ části 1 odst. D) „Technické kvalifikace podle § 79 odst. 2 písm. c) ZZVZ“ písmene c) „2 vývojoví pracovníci pro portálové technologie“ zadávací dokumentace zadavatel stanovil požadavek, že oba vývojoví pracovníci musí být držiteli „mezinárodní certifikace v oblasti portálového řešení“.

6.             Navrhovatel – HAWIKK CZ s.r.o., IČO 11925388, se sídlem Fibichova 55, 261 01 Příbram, ve správním řízení zastoupena na základě plné moci ze dne 4. 5. 2023 JUDr. Janem Boltnarem, Ph.D., advokátem, ev. č. ČAK 13948, se sídlem Růžová 972/1, 110 00 Praha 1 (dále jen „navrhovatel“) – podal dne 4. 5. 2023 zadavateli námitky směřující proti zadávacím podmínkám zadávacího řízení. Zadavatel námitky navrhovatele rozhodnutím ze dne 18. 5. 2023, které bylo navrhovateli doručeno téhož dne, odmítl.

7.             Vzhledem k tomu, že navrhovatel se způsobem vypořádání svých námitek ze strany zadavatele nesouhlasil, podal dne 29. 5. 2023 k Úřadu pro ochranu hospodářské soutěže (dále jen „Úřad") návrh na zahájení řízení o přezkoumání úkonů zadavatele z téhož dne (dále jen „návrh").

II.             OBSAH NÁVRHU

8.             První bod navrhovatelem podaného návrhu se týkal předmětu plnění rámcové dohody, přičemž navrhovatel namítá, že v zadávací dokumentaci není uvedeno nic o popisu předmětu jednotlivých uzavíraných dílčích smluv včetně termínů plnění. Dle navrhovatele tak není zadávací dokumentace úplná, a to i přesto, že dle stanoveného předmětu plnění zadavateli již nyní musí být zřejmé, co bude požadovat poskytnout. Součástí této části návrhu je také kalkulace navrhovatele, která odkazuje na tabulku A a tabulku B zadávací dokumentace, které nastiňují předpokládané personální vytížení v rámci plnění rámcové dohody. Dle této kalkulace navrhovatel došel k údajnému rozporu v zadávací dokumentaci, který spočívá v tom, že z údajů v této tabulce vyplývá, že v období od uzavření smlouvy do konce roku 2023 předpoklad nutnosti nasazení minimálně 8 lidí denně, což je dle zadavatele v rozporu s předcházejícím odstavcem zadávací dokumentace, v němž je uvedeno, že zadavatel předpokládá, že vývoj aplikace webového klienta pro NCTS, AES a eDovoz bude vyžadovat nasazení minimálně 2 – 2,5 člověka denně.

9.             Zadavatel v zadávací dokumentaci uvedl, že předmětem plnění této rámcové dohody je vývoj a technická podpora webového klienta pro NCTS, AES a eDovoz pro obchodní veřejnost. K tomuto vymezení předmětu rámcové dohody navrhovatel uvedl, což je další námitka navrhovatele, že nové legislativní a technické požadavky existují pouze na webové klienty NCTS a AES. Z tohoto důvodu není navrhovateli zřejmé, co má být předmětem plnění ve vztahu k webovému klientu eDovoz.

10.         Dále navrhovatel poukazuje na to, že součástí zadávací dokumentace k předmětné rámcové dohodě, konkrétně v příloze č. 1 zadávací dokumentace – Technická specifikace, jsou uvedeny odkazy na webové stránky, kde jsou dostupné funkční požadavky, které jsou přímou součástí dílčích hodnotících kritérií a jejich hodnocení, a to ve formátu xlsx., tedy dokumentu aplikace Microsoft Excel. Navrhovatel namítá, že tímto zadavatel porušil zákonný požadavek na transparentnost zadávacího řízení, neboť jsou tyto dokumenty uvedeny v editovatelném formátu.

11.         Dále zadavatel dle navrhovatele též nestanovil kritéria a způsob hodnocení nabídek tak, aby nedocházelo k porušování pravidel a zásad zadávání veřejných zakázek, a to tím, že zadavatel stanovil v pravidlech pro hodnocení nabídek celkem 4 dílčí hodnotící kritéria, přičemž v případě 3 z nich (kvalitativní kritéria) bude předmětem hodnocení v nabídce předložený návrh nabízeného řešení. U popisu nároků na jednotlivé návrhy řešení se pak u jednotlivých dílčích kritérií uvádí, že plný počet bodů obdrží takový návrh řešení, který „plně vyhovuje současným požadavkům zadavatele a zároveň i nejlépe vyhovuje cílům zadavatele“ či, že „prokazatelně splňuje všechny zadavatelem stanovené požadavky a naplňuje případné cíle stanovené zadavatelem“. Dle názoru navrhovatele z uvedeného vyplývá, že předkládané návrhy řešení tak musí též splňovat dle navrhovatele obecně a vágně vymezený požadavek stanovený v kapitole II. „Předmět veřejné zakázky“ odst. 6) zadávací dokumentace: „Vybraný dodavatel je povinen zajistit, aby součástí předmětu plnění veřejné zakázky bylo pouze programové a technické vybavení, jehož použití nepředstavuje hrozbu v oblasti kybernetické bezpečnosti.“ Tímto dle navrhovatele zadavatel zavedl bezbřehou možnost při hodnocení nabídek, kdy dle navrhovatele není nikterak zřejmé, jakou úroveň ochrany kybernetické bezpečnosti bude zadavatel považovat za dostatečnou pro udělení plného počtu bodů.

12.         V rámci návrhu se navrhovatel dále napadá zákonnost vymezení požadavku na technickou kvalifikaci podle § 79 odst. 2 písm. b) zákona, kterou zadavatel stanovil v kapitole VI. „Podmínky kvalifikace“ části (1) odst. C) „Technické kvalifikace podle § 79 odst. 2 písm. b) ZZVZ“ písmene a) zadávací dokumentace, tedy požadavku na prokázání nejméně dvou realizovaných významných služeb, kterými se dle zadávací dokumentace rozumí: „vývoj webového řešení (zahrnující analýzu, návrh řešení, realizaci, testování, uvedení do provozu) pro elektronická podání, včetně tvorby xml zpráv, přičemž řešení muselo umožnit identifikaci uživatele napojením na Národní Identitní Autoritu (NIA) a Informační systém datových schránek (ISDS),“ přičemž uvedené věcné vymezení je dle navrhovatele diskriminační a ovlivňuje hospodářskou soutěž. Navrhovatel namítá, že „takovýchto webových řešení je v České republice omezený počet a zároveň požadovaná funkcionalita v zadávací dokumentaci je zcela běžná, neboť tato rozhraní jsou standardní API,[1]  (viz ISDS: Informační systém datových schránek (ISDS) - Ministerstvo vnitra České republiky (mvcr.cz) NIA: Stránky pro vývojáře - Overview (azure.com)) a jejich implementace spadá do běžných zkušeností a znalostí vývojářských společností – možných dodavatelů. Skutečnost, že Stěžovatel nikdy nerealizoval zakázku s těmito rozhraními, ale neznamená, že by nebyl schopen plnohodnotně vytvořit aplikaci, která je předmětem veřejné zakázky. Takové kritérium-požadavek nic nevypovídá o kvalifikacích a kvalitách dodavatelů a není proto třeba je takto specificky uvádět a vyžadovat v tomto ohledu referenční zakázky, kterých je z povahy věci navíc omezené množství.“

13.         Navrhovatel ve vztahu k uvedenému požadavku na prokázání referenčních služeb současně též napadá stanovený požadavek, že se musí jednat o službu, která dosahovala hodnoty minimálně 5 000 000,- Kč vč. DPH. Takovéto stanovení technické kvalifikace považuje navrhovatel za nepřiměřené, neboť mu zabraňuje v účasti v zadávacím řízení, byť je dle svých slov „nepochybně jedním z nejvhodnějších subjektů k realizaci plnění předmětu této veřejné zakázky, neboť má bohaté rozsáhlé znalosti a dlouholeté zkušenosti právě v oblasti předmětu plnění této Veřejné zakázky.“

14.         V návaznosti na předchozí námitky navrhovatel též napadá jako diskriminační podmínku stanovenou ve vztahu k požadavkům na člena týmu „Senior projektový manažer“, neboť u této osoby je v rámci technické kvalifikace požadována: „zkušenost s pozicí projektového manažera alespoň na jedné z významných zakázek uvedených v seznamu významných služeb splňující požadavky na významnou službu dle čl. VI. (1) C) 1) této ZD“.

15.         V souvislosti s dalším požadavkem na prokázání technické kvalifikace dle § 79 odst. 2 písm. c) zákona, a to na člena realizačního týmu „Analytik informačních systémů“ navrhovatel napadá, že u této osoby je požadováno, že musí být držitelem „mezinárodní certifikace OMG Certified UML Professional 2 (OCUP 2)“[2], přičemž navrhovatel namítá, že tento certifikát není běžný, ale znalost UML[3] zcela běžná je, takto nastavená podmínka je tedy dle jeho názoru diskriminační a omezující hospodářskou soutěž.

16.         Obsahem návrhu je také zpochybnění požadavků na technickou kvalifikaci, kdy v kapitole VI. „Podmínky kvalifikace“ části (1) odst. D) „Technické kvalifikace podle § 79 odst. 2 písm. c) ZZVZ“ písmene c) „2 vývojoví pracovníci pro portálové technologie“ zadávací dokumentace zadavatel stanovil pro tyto členy týmu požadavek spočívající v tom, že oba vývojoví pracovníci musí být držiteli „mezinárodní certifikace v oblasti portálového řešení“. Navrhovatel namítá, že je tento kvalifikační požadavek stanoven příliš obecně, a to do té míry, že navrhovatel „nevěděl a neví jakou konkrétní specifikaci by měl do své nabídky přiložit, protože si Stěžovatel není vědom nějaké konkrétní a relevantní existující takové certifikace v Evropském prostoru.“

17.         Poslední část návrhu míří proti lhůtě pro podání nabídek, která byla dle navrhovatele příliš krátká, když představovala pouze 19 pracovních dní. Takto stanovená lhůta je dle navrhovatele diskriminační. Navrhovatel rovněž upozorňuje na to, že dle jeho názoru se zadavatel v rozhodnutí o námitkách dostatečně nevypořádal se všemi jím namítanými skutečnostmi.

18.         Navrhovatel v rámci návrhu též navrhuje doplnění a provedení důkazů, a to „prověření všech podaných nabídek, prověření splnění všech parametrů všech podaných nabídek, zpracování znaleckého posudku se zaměřením na prokázání kvality dodavatele na základě požadavku kvalifikace na významnou službu s napojením na NIA a ISDS, provedení analýz případných dalších námitek, které byly podány proti zadávacím podmínkám a jejich vypořádání zadavatelem, oslovení dodavatelů, kteří podali žádosti o vysvětlení zadávací dokumentace, námitky a nabídky nepodali, nebo nabídky podali a byli vyloučeni.“

19.         Závěrem návrhu se navrhovatel domáhá uložení nápravného opatření spočívajícího ve zrušení zadávacího řízení, dále uložení zadavateli povinnosti náhrady nákladů řízení ve smyslu § 266 zákona, a též uložení povinnosti zadavateli uhradit navrhovateli náhradu nákladů řízení, „a to z důvodu jeho zastoupení advokátem“, a to ve výši advokátního tarifu.

III.           PRŮBĚH SPRÁVNÍHO ŘÍZENÍ

20.         Úřad obdržel předmětný návrh dne 29. 5. 2023 a tímto dnem bylo podle § 249 zákona ve spojení s § 44 odst. 1 zákona č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů (dále jen „správní řád"), zahájeno správní řízení o přezkoumání úkonů zadavatele. Zadavatel obdržel stejnopis návrhu rovněž dne 29. 5. 2023.

21.         Účastníky správního řízení podle § 256 zákona jsou zadavatel a navrhovatel.

22.         Zahájení správního řízení oznámil Úřad jeho účastníkům přípisem č. j. ÚOHS-20734/2023/536 ze dne 2. 6. 2023.

23.         Usnesením č. j. ÚOHS-20816/2023/536 ze dne 2. 6. 2023 stanovil Úřad zadavateli lhůtu k provedení úkonu, a to podání informace o dalších úkonech, které zadavatel provede v šetřeném zadávacím řízení v průběhu správního řízení a zaslání příslušné dokumentace o zadávacím řízení pořízené v souvislosti s provedenými úkony.

24.         Dne 8. 6. 2023 obdržel Úřad dokumentaci o zadávacím řízení, a to spolu s vyjádřením zadavatele k návrhu ze dne 7. 6. 2023 (dále jen „vyjádření zadavatele k návrhu"). Téhož dne obdržel Úřad dokumentaci o zadávacím řízení na technickém nosiči dat.

Vyjádření zadavatele k návrhu

25.         Zadavatel k námitce navrhovatele týkající se toho, že v zadávací dokumentaci není uvedeno nic o popisu předmětu jednotlivých uzavíraných dílčích smluv včetně termínů plnění, uvedl, že navrhovatel nepochopil, co je předmětem tohoto zadávacího řízení. Zadavatel upřesňuje, že proces uzavírání dílčích smluv (objednávek) je v zadávací dokumentaci přesně popsán, přičemž konkrétní náplň jejich předmětu a termíny plnění nejsou předmětem tohoto zadávacího řízení, kterým je uzavření toliko rámcové dohody. Zadavatel uvedl, že podstatou rámcových smluv je vymezení rámce navazujících smluv, kde již bude najisto vymezen předmět plnění včetně termínů atp. K uvedené kalkulaci navrhovatele ohledně předpokládaného počtu potřebných člověkodnů zadavatel uvedl, že uvedený počet 2 – 2,5 člověka denně je průměrný počet člověkodnů za celou dobu trvání rámcové dohody. Tato informace má v zadávací dokumentaci pouze informativní charakter. Toto nepochopení navrhovatelem však zadavatel dle svého vyjádření nezpůsobil, protože zadavatel zadávací podmínky stanovil dostatečně jasně a určitě.

26.         K části návrhu směřující proti předmětu plnění ve vztahu k webovému klientu eDovoz zadavatel uvedl, že se „v současné době připravuje modernizace tohoto webového klientu a v následujících letech bude realizována. V první fázi se budou implementovat funkčnosti na základě aktuálního stavu technické specifikace ke dni zahájení implementace – uzavření dílčí smlouvy (objednávky). V rámci dalších dílčích smluv (objednávek) budou řešeny změny, které budou vycházet z aktuální národní a evropské technické specifikace a změn legislativy, které budou schvalovány zejména na úrovni Evropské unie. Obecné principy výměny zpráv se nebudou lišit od stávajícího stavu, který je popsán v technické specifikaci.“ Zadavatel uvedl, že právě tato skutečnost je jedním z důvodů, proč zvolil zadávací řízení na uzavření rámcové dohody, na jejímž základě budou uzavírány konkrétní smlouvy obsahující informace a specifikace, které v době uzavření rámcové dohody ještě nemohou být zadavateli známé.

27.         K editovatelnosti dokumentů funkčních požadavků zadavatel uvedl, že dokumentace je vydávána pro účely výrobců softwaru, ve formátu xlsl. je totiž mohou automaticky implementovat do svých softwarových řešení, přičemž pro účely tohoto zadávacího řízení z hlediska přípravy nabídky jsou tyto informace pro účastníky zadávacího řízení je zcela irelevantní. Pro plnění dílčích smluv bude rozhodná až konkrétní specifikace plnění v nich uvedená.

28.         K namítané neurčitosti pravidel hodnocení z důvodu nedostatečně určitě specifikovaného požadavku na kybernetickou bezpečnost zadavatel konstatuje, že taková námitka je zcela irelevantní, neboť tento požadavek na kybernetickou bezpečnost použitého programové a technického vybavení dle zadávací dokumentace představuje toliko požadavek na vybraného dodavatele, nikoli na hodnocený návrh řešení. Zadavatel dále dodal, že ze zadávacích podmínek ani nevyplývá, že by byla úroveň kybernetické bezpečnosti jakkoli hodnocena.

29.         Části návrhu směřující proti vymezení požadavku na technickou kvalifikaci podle § 79 odst. 2 písm. b) zákona zadavatel oponoval tím, že je stanovený požadavek na napojení na NIA a ISDS „relevantní ve vztahu k předmětu plnění zadávacího řízení. Zadavatel, jakožto organizační složka státu, potřebuje zajistit nejvyšší kvalitu poskytovaných služeb. Pro zadavatele je zásadní, zda má dodavatel zkušenost s vývojem řešení umožňující napojení na NIA a ISDS, neboť toto bude vyžadovat i při realizaci předmětu tohoto zadávacího řízení. Skutečnost, že existuje omezený počet webových řešení, která umožňují napojení na NIA a ISDS, neznamená, že zadavatel stanovil zadávací podmínky diskriminačně. Znamená to pouze to, že kvalifikaci nesplní dodavatel, který tuto zásadní zkušenost nemá. Požadavek přitom není nedůvodný, ale je v přímém vztahu k předmětu plnění zadávacího řízení.“

30.         K bodům návrhu směřujícím proti minimální hodnotě požadovaných referenčních služeb a požadavku na zkušenosti projektového manažera na realizaci jedné z těchto významných služeb zadavatel uvedl, že „[v]e vztahu k předpokládané hodnotě zadávacího řízení, která činí 40.546.500,- Kč bez DPH, tak požadavek na reference činí přibližně pouhých 10 % [hodnota významné služby bez DPH činí 4 132 231,40 Kč - pozn. Úřadu]. Tento požadavek tak zcela určitě nelze požadovat za nepřiměřený.“

31.         K námitce proti požadavku na mezinárodní certifikaci OMG Certified UML Professional 2 (OCUP 2) u člena realizačního týmu „Analytik informačních systémů“ zadavatel uvedl, že se jedná o naprosto běžnou certifikaci, kterou disponuje mnoho dodavatelů. Zadavatel poukazuje na to, že požadavek na tuto certifikaci není ve veřejných zakázkách ničím nestandardním a s ohledem na požadovaný předmětem plnění a činnost analytika informačních systému při realizaci předmětu zadávacího řízení je nezbytné, aby dotčený člen realizačního týmu touto certifikací a odpovídajícími znalostmi disponoval.

32.         K bodu návrhu směřujícímu proti nekonkrétnosti požadavku na certifikaci členů týmu vývojových pracovníků zadavatel uvedl, že nekonkrétností požadavku byla dodavatelům „dána volnost v tom, jaký konkrétní mezinárodní certifikát v oblasti portálového řešení předloží (například MS SQL, JAVA).“

33.         Zadavatel k námitce směřující proti lhůtě pro podání nabídek (ta byla dle navrhovatele příliš krátká) uvedl, že lhůta pro podání nabídek byla stanovena v souladu se zákonem. Zadavatel konstatoval, že požadavky na zpracování nabídky nebyly nestandardní, přičemž se ve své obhajobě odkazuje na to, že obdržel dvě nabídky od relevantních dodavatelů, což má nasvědčovat tomu, že lhůta pro podání nabídek byla stanovena přiměřeně.

Další průběh správního řízení

34.         Usnesením, č. j. ÚOHS-26601/2023/536 ze dne 13. 7. 2023 vyzval Úřad zadavatele mimo jiné ke sdělení konkrétních důvodů, proč bylo nezbytné omezit ověření zkušeností dodavatelů pouze na reference spočívající ve zkušenosti s vývojem webových řešení, která umožňovala identifikaci uživatele napojením právě jen konkrétně na NIA a ISDS. Dále o sdělení technického mechanismu napojení webového řešení požadovaného v rámci předmětné rámcové dohody na NIA a ISDS a zdali je tento dle zadavatele odlišný oproti mechanismům napojení na podobná jiná rozhraní (slovy navrhovatele „standardní API“, kdy „toto řešení využívá standardního rozhraní, které je přístupné každému vývojáři libovolného SW a veškerá důležitá výkonnostní činnost je realizovaná na straně systému NIA nebo ISDS, do kterého tento systém nevstupuje“), či nikoliv, a to včetně podrobného technického odůvodnění, v čem případně ona odlišnost spočívá a proč představuje překážku pro to, aby bylo možné zkušenost s napojením na tato případná podobná rozhraní akceptovat v rámci kvalifikačních podmínek předmětného zadávacího řízení.

35.         Úřad také vyzval zadavatele k poskytnutí podrobného vysvětlení, jak zadavatel vykládá stanovený požadavek „mezinárodní certifikace v oblasti portálového řešení“ a zde užitý pojem „portálové řešení“, tedy zejména jaké konkrétní certifikace by k jeho prokázání připustil a jaká je vazba předmětu plnění rámcové dohody na použitý pojem „oblast portálového řešení“ (proč je pro zadavatele důležité u těchto členů týmu ověřit znalosti „v oblasti portálového řešení“, k jaké části předmětu plnění a zde vykonávaným činnostem se tento požadavek vztahuje). Zároveň, vzhledem k odkazu zadavatele na pojmy „MS SQL“ a „JAVA“, Úřad žádal zadavatele o podrobné vysvětlení, jaké konkrétní certifikáty v „oblasti portálového řešení“ měl zadavatel na mysli uvedením příkladů MS SQL a JAVA, případně jakou mají tyto pojmy spojitost s certifikací v „oblasti portálového řešení“.

Vyjádření zadavatele ze dne 20. 7. 2023

36.         Dne 20. 7. 2023 obdržel Úřad vyjádření zadavatele k žádosti o stanovisko, ve kterém zadavatel k dotazu na identifikaci uživatele napojením právě jen konkrétně na NIA a ISDS konstatoval, že „při plnění předmětu plnění potřebuje zajistit nejvyšší kvalitu poskytovaných služeb. Pro zadavatele je zásadní, zda má dodavatel zkušenost s vývojem řešení umožňující napojení na NIA a ISDS, neboť toto bude vyžadovat i při realizaci předmětu tohoto zadávacího řízení. Zadavatel uvádí, že při vývoji webového klienta musí být dodrženy zadavatelem definované integrační požadavky, jedním z nich je mj. požadavek pro ověření uživatele bude řešení využívat modul cPortál/CAS, který zajistí jednoznačnou identifikaci subjektu vůči Národní identitní autoritě (NIA) a Informačnímu systému datových schránek (ISDS). Uživatelé se budou moci do webového klienta přihlásit pomocí ISDS nebo pomocí své datové schránky (…).

37.         V rámci svého vyjádření dále zadavatel uvedl, že „v rámci zadávací dokumentace nebylo blíže vymezeno technické řešení napojení na NIA a ISDS, jelikož se jedná o unifikované řešení a technické parametry a požadavky jsou vydávány Ministerstvem vnitra v technické specifikaci pro NIA a ISDS. Rozhraní NIA a ISDS reprezentuje API, při nichž se autentizuje uživatel. Toto API oproti standardním API obsahuje bezpečnostní prvek, který zajišťuje autentizaci konkrétního uživatele. Mechanismus napojení na NIA a ISDS je popsán v dokumentaci k portálu národního bodu vydávané Digitální a informační agenturou (…).

38.         Zadavatel dále vyjádřil svůj nesouhlas s tvrzením, že se jedná o standardní API. Jelikož webový klient pro NCTS, AES a eDovoz dle zadavatele klade velký důraz na uživatelskou bezpečnost a bezpečnost přenosu dat, zadavatel trvá na tom, že požadavek na zkušenost alespoň s dodáním dvou řešení stejného typu je oprávněný.

39.         K požadavku Úřadu na osvětlení pojmu „mezinárodní certifikace v oblasti portálového řešení“ zadavatel uvedl, že se tímto pojmem rozumí „certifikace v oblasti prostředí AZURE[4], jelikož webový klient pro NCTS, AES a eDovoz bude provozován v cloudu v prostředí AZURE.“ K tomu zadavatel odkazuje na článek 2.8 přílohy č. 1 zadávací dokumentace – technická specifikace, kde je uvedeno, že aplikace bude provozována právě v prostředí Azure (veřejný cloud) nebo Azure stack (privátní cloud). Nadto je celé řešení cPortálu[5] umístěno v Microsoft Azure cloudu, který je provozovaný Státní pokladnou Centrem sdílených služeb. Zadavatel ve vyjádření také specifikoval, že, „[p]ředmětem zadávacího řízení je vytvoření webového klienta, respektive webového rozhraní. „Portálové řešení“ v zásadě znamená „webové řešení“. Zadavatel potřebuje získat plnění, v němž bude vytvořeno portálové (webové) řešení pro NCTS, AES a eDovoz. Webový klient bude dostupný uživatelům pomocí internetového prohlížeče, kde budou její jednotlivé části vystaveny na příslušných stránkách cPortálu (viz čl. 2.10 technické specifikace). Návaznost požadavku na certifikaci v oblasti portálového řešení tedy spočívá v tom, že vytvoření portálového řešení je hlavním účelem plnění zadávacího řízení.“ K požadavku na sdělení informací ohledně souvislostí „portálového řešení“ s pojmy MS SQL a JAVA zadavatel Úřad odkázal na přehled certifikací na stránkách Microsoft Certifications (Microsoft Learn)[6] a JAVA Certifications (Oracle University)[7], přičemž dle zadavatele je možné k prokázání této certifikace předložit pod těmito odkazy uvedenou certifikaci MS SQL nebo JAVA, „nebo jinou obdobnou certifikaci, která bude prokazovat, že má příslušný člen realizačního týmu certifikaci v oblasti portálového řešení“. Zadavatel doplnil, že předmětem plnění je „vytvoření portálového řešení (webového klienta), které je podrobně popsáno v technické specifikaci, což vedlo zadavatele k nezbytnosti tohoto kvalifikačního požadavku.“

Další průběh správního řízení

40.         Usnesením č. j. ÚOHS-26635/2023/536 ze dne 14. 7. 2023 vyzval Úřad navrhovatele ke sdělení informací, a to zejména ve vztahu k jeho tvrzení, že „funkcionalita (identifikace uživatele napojením na Národní Identitní Autoritu (NIA) a Informační systém datových schránek (ISDS)) v zadávací dokumentaci je zcela běžná, neboť tato rozhraní jsou standardní API […] tento požadavek sice souvisí s předmětem plnění zadávacího řízení, ale vůbec nic nevypovídá o kvalitách dodavatelů, neboť toto řešení využívá standardního rozhraní, které je přístupné každému vývojáři libovolného SW a veškerá důležitá výkonnostní činnost je realizovaná na straně systému NIA nebo ISDS, do kterého tento systém nevstupuje.“ V souvislosti s touto argumentací požádal Úřad navrhovatele o podání podrobného vysvětlení uvedených tvrzení a doložení těchto tvrzení konkrétními skutečnostmi, tedy zejména o podrobný popis a konkretizaci, na základě jakých skutečností navrhovatel tvrdí, že předmětná funkcionalita identifikace uživatele napojením na NIA a ISDS je zcela běžná, neboť tato rozhraní jsou standardní API, dále jak navrhovatel vykládá jím užitý pojem „standardní API“, jaká další realizovaná webová řešení jsou podle navrhovatele „standardními API“ a též o podrobný popis jejich prvků a funkcionalit, na jejichž základě lze dle navrhovatele zkušenost s jejich napojením považovat za srovnatelnou se zadavatelem požadovanou zkušeností s napojením na NIA a ISDS.

41.         V rámci zmiňovaného usnesení žádal Úřad navrhovatele též o podání podrobného stanoviska k tvrzení zadavatele uvedeném v rozhodnutí o námitkách ze dne 18. 5. 2023, že „dodavatelům byla dána volnost v tom, jaký konkrétní mezinárodní certifikát v oblasti portálového řešení předloží (například MS SQL, JAVA).“ Tedy zejména o sdělení, zda je uvedené vysvětlení zadavatele (odkazované pojmy MS SQL a JAVA) dle názoru navrhovatele relevantní k danému požadavku na „mezinárodní certifikaci v oblasti portálového řešení“, případně z jakého důvodu nelze dle názoru navrhovatele považovat uvedené vysvětlení za dostatečně objasňující daný požadavek zadavatele.

Vyjádření navrhovatele ze dne 14. 8. 2023

42.         Dne 14. 8. 2023 obdržel Úřad vyjádření navrhovatele z téhož dne k citovanému usnesení. K dotazu Úřadu ohledně API uvedl navrhovatel, že „API neboli Application Programing Interface (dále jen ‚API‘) je po softwarové (dále jen ‚SW‘) stránce velmi detailní popis, jakým způsobem vzájemně komunikují dva systémy mezi sebou. Pokud je API známé a tzv. dobře dokumentované / specifikované, není pro jakoukoli SW společnost problém takové napojení realizovat. V případě Národní Identitní Autority (dále jen ‚NIA‘) a Informačního systému datových schránek (dále jen ‚ISDS) je napojení taktéž velmi dobře dokumentované a specifikované, z čehož navrhovatel vyvozuje, že je funkcionalita (identifikace uživatele napojením na NIA a ISDS) v zadávací dokumentaci zcela běžná, neboť tato rozhraní jsou z tohoto důvodu standardními API.“ Navrhovatel dodal, že dle jeho názoru dokáže kterákoliv společnost, která v minulosti realizovala napojení jiných API než NIA a ISDS, realizovat napojení na kterékoliv dobře dokumentované a specifikované API, tedy i NIA a ISDS. Navrhovatel se vyjádřil, že pokud společnost získá zkušenosti s napojením jiných API, jsou tyto využitelné i v případě napojení na NIA a ISDS, jinými slovy, že jsou tyto zkušenosti srovnatelné.

43.         K dotazu Úřadu týkajícího se stanoviska navrhovatele k bližšímu vysvětlení zadavatele ohledně požadavku na „mezinárodní certifikaci v oblasti portálového řešení“, navrhovatel uvedl, že zadavatelem užitá specifikace odkazující na certifikaci MS SQL a JAVA je dle jeho názoru stále příliš obecná, a tedy nedostačující. Navrhovatel dodal, že mu navíc ani není jasné, jakým způsobem může MS SQL souviset s portálovým řešením.

Další průběh správního řízení

44.         Dne 19. 7. 2023 vydal Úřad rozhodnutí o předběžném opatření č. j. ÚOHS-27191/2023/510, kterým zadavateli uložil zákaz uzavřít rámcovou dohodu.

45.         Usnesením ze dne 18. 8. 2023 vyzval Úřad navrhovatele k podání stanoviska k vyjádření zadavatele ze dne 20. 7. 2023, a to zejména k tomu, zda je podle mínění navrhovatele bezpečnostní prvek, který je dle zadavatele zásadním rozdílem mezi požadovaným plněním a standardním API, dostatečný pro to, aby ospravedlnil zpochybňované kvalifikační požadavky na reference dodavatele, případně z jakého důvodu nelze dle názoru navrhovatele považovat uvedené vysvětlení za dostatečně objasňující daný požadavek zadavatele. Úřad také požádal navrhovatele o vyjádření k tvrzení zadavatele, že certifikací v oblasti portálového řešení je míněna certifikace v prostředí Microsoft Azure, a dále k jím odkazovanému přehledu certifikací vydávaných společností Microsoft v případě MS SQL a vydávaných společností ORACLE v případě jazyku JAVA.

Vyjádření navrhovatele ze dne 5. 9. 2023

46.         Úřad obdržel dne 5. 9. 2023 vyjádření navrhovatele z téhož dne. Ve vztahu k požadavku na referenční služby s implementovanou identifikací uživatele napojením na NIA a ISDS navrhovatel sdělil, že souhrnně považuje zdůvodnění zadavatele učiněné v jeho vyjádření ze dne 20. 7. 2023 za nepřesvědčivé. Navrhovatel k vyjádření zadavatele ohledně bezpečnostního prvku jako hlavního rozdílu mezi požadovaným plněním a standardním API uvedl, že „postup samotného přihlášení zajišťují NIA a ISDS přes tzv. Indentity Providery (dále jen ‚IDP‘). Ztotožnění a jednoznačná identifikace subjektu není tak předmětem plnění. Aplikace bezpečnostního prvku ze strany dodavatele pak spočívá v rámci řešení v použití IDP NIA a ISDS a tzv. jej implementovat.“ Navrhovatel dodal, že veškerá „práce“ spojená s bezpečnostním řešením u NIA a ISDS je naopak velmi standardizována a dobře popsána. „Standardní proces je takový, že IDP, v tomto případě ve vztahu k NIA a ISDS (dále např. i Google nebo Facebook), provádí bezpečnostní práci a přihlášení. IDP však může provádět bezpečnostní práci a přihlášení. Aplikace, respektive poskytovatel služeb – Service Provider (SeP), používá IDP pouze v rámci přihlášení a od IDP si dále přebírá již ověřeného uživatele ve formě SAML tokenu, který tato aplikace dále používá.“ Coby podporu svého argumentu, že jde o standardizovaná řešení, připojil navrhovatel odkaz na dokumentaci pro kvalifikovaného poskytovatele služeb[8], a též připojil odkaz na seznam připojených online služeb, ze kterého je dle navrhovatele patrné, že připojení mohou provádět vývojáři s běžnou znalostí API. „Příkladem napojených systémů v daném ohledu mohou být: eRecept – pacientská aplikace, Portál pacienta Moravskoslezského kraje, Vitakarta, Portál obcana Datron, AK Vych & Partners, Základní umělecká škola Velké Meziříčí, příspěvková organizace, Masarykova univerzita, Naevia Estate s.r.o., Scio, VŠE Praha – studijní systém, IS VUT – ePřihláška a další.“ Závěrem tohoto bodu vyjádření navrhovatel konstatoval, že pokud kterákoliv softwarová společnost realizovala napojení jiných API (ne tedy konkrétně NIA a ISDS), je dle něj zřejmé, že dokáže realizovat i napojení tak dobře zdokumentovaného a specifikovaného API, jako jsou právě NIA a ISDS.

47.         K argumentaci zadavatele ohledně podmínky „mezinárodní certifikace v oblasti portálového řešení“ uvedené v jeho vyjádření ze dne 20. 7. 2023 navrhovatel uvedl, že vysvětlení zadavatele, že „[p]ojmem ‘mezinárodní certifikace v oblasti portálového řešení‘ se rozumí certifikace v oblasti prostředí AZURE“, nepovažuje za srozumitelné. Nadto navrhovatel uvedl, že požadavek na uvedenou certifikaci zadavatel velmi zmatečným způsobem uvedl již v zadávací dokumentaci, což zadavatel svým vyjádřením nenapravil. Navrhovatel dodal, že tento požadavek považuje za účelově vytvořený se záměrem eliminovat dodavatele v rámci zadávacího řízení. K zadavatelem odkazovanému přehledu certifikací na stránkách Microsoft Certifications (Microsoft Learn) navrhovatel shledává, že na této stránce je uvedeno mnoho certifikací (celkem 84 certifikací), a dále dodává, že „[p]okud by navrhovatel postupoval při závěrech ve smyslu vyjádření zadavatele ze dne 20.7. 2023, došel by k takovému závěru, že zadavatel má za prokázané požadované znalosti pro webové portálové řešení na základě označení ‚Azure‘, tj. certifikátu, jehož název obsahuje ‚Azure‘,“ přičemž pod tímto označením jsou zde uvedeny i certifikáty, které se zabývají technologiemi, které nebudou v průběhu zpracování zakázky využity (navrhovatel pro příklad odkazuje na „Microsoft Certified: Azure Cosmos DB Developer Specialty“, „Microsoft Certified: Azure AI Fundamentals“ či „Microsoft Certified: Azure for SAP Workloads Specialty“). Navrhovateli z vyjádření zadavatele tak vyplývá, že splnění podmínek shledává v názvu a označení dané certifikace bez ohledu na technologii.

Další průběh správního řízení

48.         Dne 30. 8. 2023 požádal Úřad Digitální a informační agenturu (dále jen „DIA“) – jakožto ústřední správní úřad pro elektronickou identifikaci a služby vytvářející důvěru a pro informační systémy veřejné správy dle § 2a odst. 2 zákona č. 12/2020 Sb., o právu na digitální služby a o změně některých zákonů, ve znění pozdějších předpisů, a vzhledem k působnosti DIA dle odst. 3 téhož ustanovení tohoto zákona – o poskytnutí odborného stanoviska k řešeným otázkám, a to zejména o sdělení, zda DIA považuje skutečnosti tvrzené zadavatelem týkající se všech rozporných bodů, jež byly předmětem šetření Úřadu, za pravdivé a důvodné, a případně z jakých konkrétních důvodů nikoliv.

49.         Úřad požádal DIA o popis mechanismu napojení na NIA a ISDS, a to včetně popisu řešení využívající modul cPortál/CAS, kterým má být dle zadavatele (resp. technické specifikace) zajištěna jednoznačná identifikace uživatele. DIA měla také poskytnout Úřadu sdělení, zda je dle jejího názoru důvodné a nezbytné, aby vzhledem k uvedenému bezpečnostnímu prvku (zajištění autentizace konkrétního uživatele pomocí modulu cPortál/CAS), který je dle zadavatele zásadním rozdílem mezi požadovaným plněním a standardním API, byl za kvalifikovaného dodavatele považován výhradně ten, který již disponuje zkušenostmi s realizací právě a jen takového řešení, které zahrnovalo napojení na NIA a ISDS, a zda je tedy zmíněný bezpečnostní prvek natolik specifickou komponentou těchto programových rozhraní, že není možné akceptovat jako srovnatelně kvalifikované dodavatele se zkušenostmi s realizací řešení s využitím jiných API.

50.         Úřad požádal DIA také o sdělení, zda DIA považuje požadavek zadavatele na „mezinárodní certifikaci v oblasti portálového řešení“ v zadávací dokumentaci za jednoznačný, tj. zda je zřejmé, co zadavatel po potenciálních dodavatelích požadoval, a zda uvedenému požadavku odpovídá zadavatelem předložený výklad, že tímto se rozumí certifikace v oblasti prostředí AZURE. Úřad také požádal o sdělení podrobností ohledně certifikace MS SQL nebo JAVA, které lze dle zadavatele předložit k prokázání, že má příslušný člen realizačního týmu certifikaci v oblasti portálového řešení.

Stanovisko Digitální a informační agentury ze dne 18. 9. 2023

51.         Dne 19. 9. 2023 obdržel Úřad stanovisko DIA ze dne 18. 9. 2023. Ve vztahu k požadavku na referenční služby s implementovanou identifikací uživatele napojením na NIA a ISDS a tím související argumentací zadavatele uvedla DIA následující. DIA uvedla, že popis napojení portálového řešení kvalifikovaného poskytovatele k NIA je popsán ve veřejně přístupné dokumentaci, dle níž je pro toto připojení možné využít standard WS-Federation nebo eIDAS SAML 2.0 standard. Ve vztahu k navrhovatelem použitému pojmu „standardní API“ DIA dále sdělila, že v případě NIA skutečně jde o standardizované protokoly s veřejně přístupnou dokumentací, avšak DIA konstatuje, že „[v]zhledem k nárokům na bezpečnost a přesnost implementace však nejsou běžně využívány. Tyto nároky mají původ v nutnosti důvěryhodnosti celého procesu dle nařízení eIDAS. Dodavatel portálového řešení s využitím těchto protokolů by tedy měl mít zkušenosti s jejich využitím. Dle našich zkušeností není pravdou, že implementace výše uvedených pravidel a protokolů je bezproblémová a u mnoha kvalifikovaných poskytovatelů ve veřejné správě byla tato implementace zdrojem potíží, které měly za následek minimálně časové problémy v harmonogramu a zátěže na spolupráce s technickým správcem NIA pro odhalení chyb v implementaci. Považujeme tedy za správné a obezřetné ze strany zadavatele požadovat zkušenosti s výše uvedenými protokoly, nicméně tyto zkušenosti nemusejí být omezeny na využití těchto protokolů pro integraci identifikace a autentizace s NIA.“

52.         Podobně se DIA vyjádřila také k požadavku na identifikaci uživatele napojením na ISDS. DIA konstatovala, že též aplikační rozhraní (API) ISDS je veřejně dostupné. „Z pohledu složitosti implementace považujeme aplikační rozhraní ISDS za středně složité. Ze zkušenosti víme, že ne všichni vývojáři jsou dostatečně obeznámeni s metodami autentizace pomocí systémových certifikátů. Méně zkušení často potřebují pomoc či radu ze strany smluvního provozovatele informačního systému datových schránek. Nelze však říci, že by s vynaložením přiměřené pracnosti kvalifikovaný programátor integraci na API ISDS nezvládl. Proto nepokládáme za důvodné omezovat prokázání kvalifikace uchazeče výhradně na integraci na API ISDS.“ DIA k tomuto závěru upřesnila: „S ohledem na požadavek na dodržení projektového harmonogramu a efektivní výkonové spotřeby lidských kapacit dodavatele, bychom považovali za oprávněné prokázání zkušenosti s integrací obdobného autentizačního API s využitím serverové komunikace založené na TLS/SSL protokolu a autentizace serverovým certifikátem. Nezkušenost dodavatele s touto oblastí by mohla způsobit zpoždění dodávky či zvýšené implementační náklady a chápeme, že se zadavatel chce těmto rizikům vyhnout.“

53.         Společně ve vztahu k požadavku napojení na NIA a ISDS závěrem k tomuto bodu DIA shrnula, že  „[p]okud jde o sdělení, zda je dle názoru DIA důvodné a nezbytné, aby vzhledem k uvedenému bezpečnostnímu prvku (zajištění autentizace konkrétního uživatele pomocí modulu cPortál/CAS), který je dle zadavatele zásadním rozdílem mezi požadovaným plněním a standardním API, byl za kvalifikovaného dodavatele považován výhradně ten, který již disponuje zkušenostmi s realizací právě a jen takového řešení, které zahrnovalo napojení na NIA a ISDS, a zda je tedy zmíněný bezpečnostní prvek natolik specifickou komponentou těchto programových rozhraní, že není možné akceptovat jako srovnatelně kvalifikované dodavatele se zkušenostmi s realizací jiných API, platí, jak již bylo uvedeno výše, že toto vyjádření je nepřesné. Pokládáme za oprávněné požadovat zkušenost s využitím výše uvedených standardů z důvodu mitigace rizik projektu. Nepokládáme za oprávněné omezení na zkušenosti pouze s napojením na NIA a ISDS. Stejně validní může být zkušenost s napojením na jiné poskytovatele federačních služeb, kteří používají výše uvedené protokoly ve stejném rozsahu (viz dokumentace pro kvalifikované poskytovatele a uživatele ISDS).“

54.         K požadavku zadavatele na mezinárodní certifikaci v oblasti portálového řešení uvedla DIA, že „[v]zhledem k uvedené textaci požadavku dle našeho názoru není možné jednoznačně definovat, jaké ‚mezinárodní certifikace v oblasti portálového řešení‘ budou zadavatelem akceptovány.“ K dotazu, zda DIA považuje požadavek zadavatele na mezinárodní certifikaci v oblasti portálového řešení uvedený v zadávací dokumentaci za jednoznačný, tj. zda je zřejmé, co zadavatel po potenciálních dodavatelích požadoval, a zda uvedenému požadavku odpovídá zadavatelem předložený výklad, že tímto se rozumí certifikace v oblasti prostředí AZURE, DIA konstatovala, že tento požadavek nepovažuje za jednoznačný sám o sobě, z čehož důvodu nemůže posoudit, zda je či není možné odvodit souvislost k prostředí AZURE. DIA též dodala, že pokud jde o podrobnosti ohledně certifikace MS SQL nebo JAVA, které lze dle zadavatele předložit k prokázání tohoto požadavku, platí, že ani tento aspekt nemůže posoudit, a to vzhledem k přechodu od obecného vyjádření (portálové řešení) ke konkrétnímu (certifikace MS SQL nebo JAVA). Konkrétní uvedené certifikace nejsou podmínkou schopností dodavatele dodat obecné portálové řešení. 

Další průběh správního řízení

55.         Usnesením č. j. ÚOHS-36829/2023/536 ze dne 26. 9. 2023 vyzval Úřad zadavatele a navrhovatele k provedení úkonu – podání vyjádření ke stanovisku Digitální a informační agentury ze dne 18. 9. 2023.

Vyjádření zadavatele ze dne 4. 10. 2023

56.         Dne 5. 10. 2023 obdržel Úřad v reakci na citované usnesení vyjádření zadavatele ze dne 4. 10. 2023. K názoru DIA na požadavek na významnou službu zahrnující identifikaci uživatele napojením na NIA a ISDS zadavatel uvedl, že se ztotožňuje s jejím vyjádřením, že v případě napojení na NIA a ISDS „nejde o triviální řešení, přestože je realizováno prostřednictvím veřejně dostupných API knihoven, a z důvodu mitigace rizik projektu lze považovat za oprávněné požadovat zkušenost s využitím uvedených standardů.“ Dle zadavatele DIA potvrzuje, že „požadavek zadavatele u významných služeb, aby řešení umožňovalo identifikace uživatele napojením na NIA a ISDS, je logický a oprávněný. Poptávané plnění není standardizované ani standardní, nelze se tedy spokojit se zkušeností se standardními protokoly API, ale je přiměřené předmětu plnění veřejné zakázky vyžadovat takového dodavatele, který má zkušenost s řešeními umožňujícími napojení na NIA a ISDS. Zadavatel proto i ve světle stanoviska Agentury považuje svůj postup za souladný se ZZVZ.“

57.         Závěrem zadavatel sdělil, že „zcela v souladu se ZZVZ (tedy zejména přiměřeně ve vztahu k předmětu plnění veřejné zakázky) požadoval, aby významné služby zahrnovaly možnost napojení se na NIA a ISDS a aby členové realizačního týmu disponovali předmětnými certifikacemi. Pokud by takovou zkušenost/takové certifikace zadavatel nepožadoval, vystavoval by se riziku, že plnění obdrží od dodavatele, který není dostatečně zkušený, což by ohrozilo kvalitu plnění a dodržení termínů plnění. Dlužno podotknout, že zadavatel prostřednictvím veřejné zakázky bude plnit své povinnosti stanovené mu na úrovni Evropské unie a musí tak předejít všem rizikům, která by mohla jakkoli ohrozit řádnost a včasnost poskytovaného plnění. Zadavatel proto byl nucen kvalifikační kritéria nastavit tak, aby neměl pochyb o tom, že dodavatel vybraný k plnění veřejné zakázky je skutečně již ze svých předchozích zkušeností dostatečně kvalifikovaný a disponuje plně kvalifikovaným realizačním týmem. Nutnost maximální eliminace nebo alespoň minimalizace rizik tak byla na straně zadavatele naprosto nezbytná.“

58.         Co se týče vyjádření DIA k požadavku na certifikaci v oblasti „portálových řešení“ zadavatel souhlasí s formulací DIA, že požadavek není konkrétní do té míry, aby bylo možné odvodit konkrétní požadovaný certifikát. Zadavatel na tomto místě odkazuje na technickou specifikaci (příloha č. 1 zadávací dokumentace), z níž vyplývá, že realizace je požadována pro cloudové prostředí MS AZURE v kombinaci s MS SQL, dle zadavatele tedy lze „doložit některý z certifikátů od firmy Microsoft pro práci s uvedenými technologiemi. Agentura v této věci konstatuje, že naopak prokázání certifikací specialistů dodavatele pro dodávku portálového řešení v prostředí AZURE považuje za relevantní.“ Zadavatel konstatoval, že má za to, že jeho požadavek na mezinárodní certifikaci v oblasti portálového řešení je (zejména i s ohledem na technickou specifikaci poptávaného plnění) logický a oprávněný a má přímou souvislost s předmětem plnění rámcové dohody.

Vyjádření navrhovatele ze dne 9. 10. 2023

59.         Dne 9. 10. 2023 obdržel Úřad vyjádření navrhovatele z téhož dne. Navrhovatel mimo jiné souhlasí s vyjádřením DIA, že DIA považuje za „správné a obezřetné ze strany zadavatele požadovat zkušenosti s výše uvedenými protokoly, nicméně tyto zkušenosti nemusejí být omezeny na využití těchto protokolů pro integraci identifikace a autentizace s NIA.“ K tomuto vyjádření DIA navrhovatel uvedl, že „má tak i nadále za to, že v případě, kdy SW společnost již realizovala napojení jiných (srovnatelných) API, je na místě takovou zkušenost považovat za srovnatelnou se zkušeností s napojením na NIA a ISDS. Dovednosti a zkušenosti, které SW společnost získá napojením jiných (srovnatelných) API, využije stejně tak pro napojení na NIA (a ISDS). Pokud je tedy SW společnost schopna napojit jiná (srovnatelná) API, je schopná napojit i NIA (a ISDS). Zadavatel tak nepostupoval v souladu se zákonem, když požadované zkušenosti dodavatele takto úzce vymezil.“

60.         K vyjádření DIA, že tato nepokládá za důvodné omezovat prokázání kvalifikace uchazeče výhradně na integraci na API ISDS a že pro NIA i pro ISDS se jedná o použití standardizovaných a dokumentovaných protokolů, jejichž znalost a zkušenost může být pro případného dodavatele výhodou, ale že DIA nicméně není známa žádná formální forma prokázání uvedené znalosti, navrhovatel uvedl, že dle něj z vyjádření DIA plyne, že „zadavatel určil v zadávací dokumentaci podmínku, kterou nejsou uchazeči schopni splnit, a tedy prokázat uvedené znalosti. Pokud není ani DIA známa žádná formální možnost prokázání uvedené znalosti, nelze takové prokázání znalosti od uchazeče vyžadovat. Zadavatel tak zásadním způsobem nerespektoval zásady zadávacího řízení a současně stanovil podmínky pro uchazeče objektivně nesplnitelné. S takovým postupem zadavatele nemůže navrhovatel souhlasit.“

61.         V souvislosti s vyjádřením DIA k certifikaci v oblasti portálového řešení, podle kterého se DIA domnívá, že není možné jednoznačně definovat, jaké „mezinárodní certifikace v oblasti portálového řešení“ budou zadavatelem akceptovány, navrhovatel uvedl, že „vysvětlení zadavatele dostatečně neobjasňuje uvedený požadavek zadavatele. Specifikace pro certifikace na portálová řešení jsou v tomto případě nadále obecné. Tvrzení navrhovatele tak potvrzuje i stanovisko DIA v této části. Ze strany zadavatele nedošlo k jednoznačné definici akceptovaných mezinárodních certifikací v oblasti portálového řešení´.“

62.         K vyjádření DIA ohledně termínu „mezinárodní certifikace v oblasti portálového řešení“, resp. jeho specifikace zadavatelem jako „certifikace v prostředí Microsoft Azure“, přičemž DIA nepovažuje požadavek za jednoznačný sám o sobě a nemůžeme tak posoudit, zda je či není možné odvodit souvislost k prostředí AZURE, vedl navrhovatel, že „[z] uvedeného závěru DIA plyne, že je požadavek zadavatele obecný a nepřesný. Navrhovatel tak trvá na svých závěrech ohledně skutečnosti, že nelze vysvětlení zadavatele ohledně mezinárodní certifikace v oblasti portálového řešení považovat za dostatečné.“

63.         V rámci svého vyjádření navrhovatel také konstatuje, že „trvá na svém vyjádření, že zadavatel uvedl pouze obecné certifikace pro portálové řešení (MS SQL, JAVA). V daném ohledu si navrhovatel není ani nadále vědom toho, jak souvisí MS SQL s portálovou certifikací. Vysvětlení zadavatele tak s ohledem na shora uvedené nelze považovat za dostatečně objasňující, což potvrzuje i stanovisko DIA. DIA nepovažuje tyto uvedené certifikace za podmínku schopnosti dodavatele dodat obecné portálové řešení, a naopak považuje za relevantní prokázat certifikaci dodavatele pro dodávku portálového řešení v prostředí AZURE. Z těchto závěrů lze vyvodit, že zadavatel nesplnil požadavky na něj kladené při zpracování zadávací dokumentace a současně zadavatel neobstál se svými tvrzeními v tomto řízení.“

Další průběh správního řízení

64.         Usnesením č. j. ÚOHS-41558/2023/536 ze dne 24. 10. 2023 určil Úřad účastníkům řízení lhůtu, ve které se mohli vyjádřit k podkladům rozhodnutí. Zadavatel se ve stanovené lhůtě, ani později, k podkladům rozhodnutí nevyjádřil.

65.         Dne 6. 11. 2023 obdržel Úřad vyjádření navrhovatele k podkladům rozhodnutí z téhož dne. Nad rámec již dříve opakovaných replik ohledně tvrzené nezákonnosti postupu zadavatele navrhovatel v tom vyjádření komentuje jednotlivé skutečnosti uvedené ve stanovisku DIA, případně zároveň polemizuje s tvrzeními zadavatele ve vyjádření ze dne 4. 10. 2023, neboť po seznámení s jeho obsahem, dle jeho názoru předmětné vyjádření nekoresponduje se stanoviskem DIA a pouze poukazuje na části vytržené z kontextu stanoviska DIA.

IV.          ZÁVĚRY ÚŘADU

66.         Úřad přezkoumal na základě § 248 a následujících ustanovení zákona případ ve všech vzájemných souvislostech a po zhodnocení všech podkladů, zejména relevantních částí dokumentace o zadávacím řízení, vyjádření předložených účastníky řízení a na základě vlastních zjištění rozhodl o zrušení zadávacího řízení. Ke svému rozhodnutí Úřad uvádí následující rozhodné skutečnosti.

Relevantní ustanovení zákona

67.         Dle § 6 odst. 1 zákona zadavatel musí při postupu podle tohoto zákona dodržovat zásady transparentnosti a přiměřenosti.

68.         Dle § 6 odst. 2 zákona musí zadavatel ve vztahu k dodavatelům dodržovat zásadu rovného zacházení a zásadu zákazu diskriminace.

69.         Podle § 28 odst. 1 písm. b) zákona se pro účely zákona zadávací dokumentací rozumí veškeré písemné dokumenty obsahující zadávací podmínky, sdělované nebo zpřístupňované účastníkům zadávacího řízení při zahájení zadávacího řízení, včetně formulářů podle § 212 zákona a výzev uvedených v příloze č. 6 k tomuto zákonu.

70.         Podle § 36 odst. 1 platí, že zadávací podmínky nesmí být stanoveny tak, aby určitým dodavatelům bezdůvodně přímo nebo nepřímo zaručovaly konkurenční výhodu nebo vytvářely bezdůvodné překážky hospodářské soutěže.

71.         Podle § 36 odst. 3 zákona zadavatel zadávací podmínky stanoví a poskytne dodavatelům v podrobnostech nezbytných pro účast dodavatele v zadávacím řízení. Zadavatel nesmí přenášet odpovědnost za správnost a úplnost zadávacích podmínek na dodavatele.

72.         Ustanovení § 73 odst. 6 zákona stanoví, že pokud zadavatel požaduje prokázání ekonomické nebo technické kvalifikace, musí v zadávací dokumentaci přiměřeně vzhledem ke složitosti a rozsahu předmětu veřejné zakázky stanovit,

a)             která kritéria ekonomické nebo technické kvalifikace požaduje a

b)             minimální úroveň pro jejich splnění.

73.         Podle § 79 odst. 2 písm. b) zákona může zadavatel k prokázání kritérií technické kvalifikace požadovat seznam významných dodávek nebo významných služeb poskytnutých za poslední 3 roky před zahájením zadávacího řízení včetně uvedení ceny a doby jejich poskytnutí a identifikace objednatele; zadavatel může stanovit, že budou zohledněny doklady i za dobu delší než poslední 3 roky před zahájením zadávacího řízení, pokud je to nezbytné pro zajištění přiměřené úrovně hospodářské soutěže.

74.         Podle § 79 odst. 2 písm. c) zákona může zadavatel k prokázání kritérií technické kvalifikace požadovat seznam techniků nebo technických útvarů, které se budou podílet na plnění veřejné zakázky, a to zejména těch, které zajišťují kontrolu kvality nebo budou provádět stavební práce, bez ohledu na to, zda jde o zaměstnance dodavatele nebo osoby v jiném vztahu k dodavateli.

75.         Podle § 79 odst. 2 písm. d) zákona může zadavatel k prokázání kritérií technické kvalifikace požadovat osvědčení o vzdělání a odborné kvalifikaci vztahující se k požadovaným dodávkám, službám nebo stavebním pracem, a to jak ve vztahu k fyzickým osobám, které mohou dodávky, služby nebo stavební práce poskytovat, tak ve vztahu k jejich vedoucím pracovníkům.

76.         Podle § 263 odst. 3 zákona platí, že stanoví-li zadavatel zadávací podmínky v rozporu se zákonem, Úřad uloží nápravné opatření spočívající ve zrušení zadávacího řízení.

K výroku I. tohoto rozhodnutí

77.         Zadavatel v rámci zadávací dokumentace vymezil požadavek na prokázání technické kvalifikace prostřednictvím předložení seznamu významných služeb, ze kterého mimo jiné musí vyplývat, že dodavatel poskytl „nejméně 2 (dvě) významné služby, jejichž předmětem byl vývoj webového řešení (zahrnující analýzu, návrh řešení, realizaci, testování, uvedení do provozu) pro elektronická podání, včetně tvorby xml zpráv, přičemž řešení muselo umožnit identifikaci uživatele napojením na Národní Identitní Autoritu (NIA) a Informační systém datových schránek (ISDS).“ Významná služba zároveň musí splňovat to, že byla poskytnuta dodavatelem za posledních 6 let před zahájením zadávacího řízení a dosahovala alespoň hodnoty 5 000 000 Kč vč. DPH.

78.         Z návrhu vyplývá, že je takto stanovená zadávací podmínka, resp. její část, která omezuje prokazované zkušenosti dodavatele s realizací referenční významné služby pouze na řešení umožňující identifikaci uživatele napojením na NIA a ISDS, dle navrhovatele diskriminační a ovlivňující hospodářskou soutěž. Toto tvrzení navrhovatel podkládá argumentem, že v České republice existuje pouze omezený počet takovýchto realizovaných řešení, která zahrnovala identifikaci uživatele prostřednictvím těchto dvou programových technologií, tedy řešení umožňujících napojení jen na NIA a ISDS, zároveň je ale požadovaná funkcionalita, resp. práce s těmito dvěma zadavatelem vybranými technologiemi ve své podstatě zcela běžná a nikterak specifická, protože, dle navrhovatele, představuje standardní API, jejíž implementace spadá do běžných zkušeností a znalostí možných dodavatelů. Navrhovatel nadto namítá, že skutečnost, že nerealizoval zakázku se zmíněnými rozhraními, neznamená, že není schopen plnit předmět plnění rámcové dohody, naopak se označuje za v tomto ohledu způsobilého. Takto specifikovaný požadavek dle navrhovatele nic nevypovídá o kvalifikaci a kvalitě dodavatelů, přičemž je takto stanovený požadavek příliš specifický.

79.         Zadavatel k těmto argumentům navrhovatele v rozhodnutí o námitkách a ve vyjádření k návrhu mimo jiné uvedl, že je požadavek na napojení na NIA a ISDS „relevantní ve vztahu k předmětu plnění zadávacího řízení. Zadavatel, jakožto organizační složka státu, potřebuje zajistit nejvyšší kvalitu poskytovaných služeb. Pro zadavatele je zásadní, zda má dodavatel zkušenost s vývojem řešení umožňující napojení na NIA a ISDS, neboť toto bude vyžadovat i při realizaci předmětu tohoto zadávacího řízení. Skutečnost, že existuje omezený počet webových řešení, která umožňují napojení na NIA a ISDS, neznamená, že zadavatel stanovil zadávací podmínky diskriminačně. Znamená to pouze to, že kvalifikaci nesplní dodavatel, který tuto zásadní zkušenost nemá. Požadavek přitom není nedůvodný, ale je v přímém vztahu k předmětu plnění zadávacího řízení.“

80.         V rámci šetření obdržel Úřad také vyjádření zadavatele ze dne 20. 7. 2023, kde zadavatel uvedl, že je pro něj zásadní, zda má dodavatel zkušenost s vývojem řešení umožňujícího napojení na NIA a ISDS, protože právě to bude zadavatel vyžadovat při realizaci předmětu této rámcové dohody. Ve svém vyjádření zadavatel také uvedl, že při vývoji webového klienta, jenž bude předmětem zde zadávaného plnění, musí být dodrženy zadavatelem definované integrační požadavky, jedním z nich je mj. požadavek, že pro ověření uživatele bude řešení využívat modul cPortál/CAS, který zajistí jednoznačnou identifikaci subjektu vůči Národní identitní autoritě (NIA) a Informačnímu systému datových schránek (ISDS). Dle zadavatele platí, že „[r]ozhraní NIA a ISDS reprezentuje API, při nichž se autentizuje uživatel. Toto API oproti standardním API obsahuje bezpečnostní prvek, který zajišťuje autentizaci konkrétního uživatele.“ Zadavatel tak vyjádřil svůj nesouhlas s tvrzením navrhovatele, že se v šetřeném případě jedná o standardní API, protože toto API oproti standardním API dle názoru zadavatele obsahuje specifický bezpečnostní prvek. Dle přesvědčení zadavatele je požadavek u významných služeb, aby řešení umožňovalo identifikace uživatele napojením na NIA a ISDS, logický a oprávněný. Dle zadavatele „[p]optávané plnění není standardizované ani standardní, nelze se tedy spokojit se zkušeností se standardními protokoly API, ale je přiměřené předmětu plnění veřejné zakázky vyžadovat takového dodavatele, který má zkušenost s řešeními umožňujícími napojení na NIA a ISDS.“ Zadavatel též popsal, že uvedený požadavek stanovil za účelem snahy o eliminaci rizik, neboť byl nucen kvalifikační kritéria nastavit tak, „aby neměl pochyb o tom, že dodavatel vybraný k plnění veřejné zakázky je skutečně již ze svých předchozích zkušeností dostatečně kvalifikovaný a disponuje plně kvalifikovaným realizačním týmem. Nutnost maximální eliminace nebo alespoň minimalizace rizik tak byla na straně zadavatele naprosto nezbytná.“

81.         Úřad uvádí, že s ohledem na obsah návrhu je tedy úkolem Úřadu ve správním řízení posoudit, zda je takové omezení předmětného kritéria technické kvalifikace toliko na významné služby odpovídající požadavku, že se tyto týkaly řešení, která umožňovala identifikaci uživatele napojením na Národní Identitní Autoritu (NIA) a Informační systém datových schránek (ISDS),důvodné, tj. zda na straně zadavatele existují takové skutečnosti, které představují objektivní a legitimní důvod pro zmíněné omezení. Úřad na tomto místě musí zdůraznit, že je to právě zadavatel, kdo musí znát důvody, které jej ke stanovení konkrétního požadavku na kvalifikaci vedly.

82.         Úřad tedy přistoupil k prověření, zda je takto stanovený požadavek přiměřený, a tedy v souladu se zákonem a zdali je v přímé souvislosti s plněním rámcové dohody a zdali opravdu není možné takto stanovený požadavek na zkušenost dodavatelů rozšířit a umožnit tak účast v zadávacím řízení i jinak způsobilým dodavatelům, kteří mají zkušenosti s jinými, případně podobnými programovými rozhraními.

83.         Úřad nejprve v obecné rovině uvádí, že účelem stanovení požadavků na prokázání kvalifikace je zajištění realizace předmětu plnění veřejné zakázky pouze takovými dodavateli, kteří jsou ve skutečnosti schopni veřejnou zakázku (rámcovou dohodu)[9], v případě jejich úspěchu v zadávacím řízení, řádně, včas a v odpovídající kvalitě realizovat a poskytují o tom zadavateli záruky. Tím je minimalizováno zadavatelovo riziko, že dojde ke zmaření plnění předmětu veřejné zakázky. Konkrétně technická kvalifikace slouží k prokázání lidských či technických zdrojů a odborných schopností a zkušeností nezbytných pro plnění veřejné zakázky v odpovídající kvalitě. Adekvátně nastavená kritéria technické kvalifikace jsou „sítem“, které má zamezit účasti subjektů neschopných danou veřejnou zakázku řádně, včas a v odpovídající kvalitě plnit. Jakýkoliv požadavek zadavatele na prokázání technické kvalifikace tudíž s ohledem na svůj účel relativně omezuje hospodářskou soutěž, neboť některým dodavatelům znemožňuje přístup k plnění veřejné zakázky. Vzhledem k tomu, že zadavatel může nastavením kvalifikačních kritérií okruh potenciálních dodavatelů výrazně ovlivnit, je třeba, aby byla stanovena v souladu se zákonem objektivním, přiměřeným, transparentním a nediskriminačním způsobem a nevytvářela bezdůvodně překážky hospodářské soutěže.

84.         Co se týče zásady přiměřenosti, ta vychází ze skutečnosti, že zákon ponechává zadavatelům značnou míru diskrece ohledně volby konkrétního postupu v zadávacím řízení. Jedná se tak o zásadu, kterou by se měl zadavatel řídit ve všech fázích zadávacího řízení. Úřad uvádí, že tato zásada se nejvíce uplatňuje při stanovení podmínek účasti v zadávacím řízení, typicky u podmínek kvalifikace, které přímo determinují okruh potenciálních dodavatelů, kteří by se mohli zúčastnit zadávacího řízení. Postup v souladu se zásadou přiměřenosti tedy primárně (nikoli však výlučně) spočívá v tom, že na jedné straně zadavateli poskytuje dostatečné záruky výběru dodavatele, který skutečně bude schopen veřejnou zakázku kvalitně a v požadovaných termínech realizovat, na druhou stranu se bude jednat o postup, který nad rámec garance výše uvedeného cíle nebude dále nedůvodně omezovat hospodářskou soutěž.

85.         Úřad v rámci obecných východisek dále uvádí, že se zásadou přiměřenosti je úzce spjata zásada zákazu diskriminace, neboť v případě, kdy zadavatel stanoví např. nepřiměřené podmínky kvalifikace, má tento postup zadavatele negativní dopad do okruhu potenciálních dodavatelů (zužuje jej), a tedy dochází k diskriminaci dodavatelů, kteří by byli, pakliže by zadavatel vymezil své požadavky v souladu se zásadou přiměřenosti, způsobilí ucházet se o veřejnou zakázku a následně veřejnou zakázku plnit, jelikož by jim byla dána (přiměřeným nastavením požadavků zadavatele) možnost se zadávacího řízení účastnit, resp. podat nabídku. Toto je patrné i z konstrukce ustanovení § 36 odst. 1 zákona, kde je stanoveno, že zadávací podmínky nesmí být stanoveny tak, aby určitým dodavatelům bezdůvodně přímo či nepřímo zaručovaly konkurenční výhodu, nebo vytvářely bezdůvodné překážky hospodářské soutěže. K tomu Úřad doplňuje, že zadavatel spolu se stanovením veškerých podmínek a parametrů nese i odpovědnost za to, že veškeré požadavky vymezené v zadávacích podmínkách jsou ve vztahu k předmětu veřejné zakázky objektivní a přiměřené, přičemž čím náročněji (tj. pro dodavatele více omezujícím způsobem) budou zadávací podmínky specifikovány, tím precizněji by je měl být zadavatel schopen odůvodnit. Z pohledu dodržení zásady přiměřenosti tak obstojí pouze takové zadávací podmínky, které je zadavatel schopen objektivně a patřičně odůvodnit, aniž by v souvislosti s jejich stanovením došlo k bezdůvodnému omezení hospodářské soutěže.

86.         Zásadu zákazu diskriminace nelze vztahovat jen na diskriminaci zjevnou (přímou), tedy případ, kdy zadavatel otevřeně postupuje jinak vůči jednotlivému dodavateli a jinak vůči dalším dodavatelům, ale též na diskriminaci skrytou (nepřímou). K tomu lze odkázat např. na rozsudek Krajského soudu v Brně, sp. zn. 62 Ca 29/2009 ze dne 16. 3. 2011, v němž citovaný soud mj. uvedl, že: „K porušení zásady zákazu diskriminace může dojít např. tehdy, pokud zadavatel stanoví zcela nepřiměřené požadavky na prokázání splnění kvalifikace, v důsledku čehož účelově a v rozporu se zákonem omezí účast určité skupiny dodavatelů. Zadavatel je oprávněn využít prostor daný zákonem a prostřednictvím stanovení úrovně ekonomických a finančních kvalifikačních předpokladů nebo technických kvalifikačních předpokladů znevýhodnit některé dodavatele, to však pouze za předpokladu, že je to odůvodněno objektivními okolnostmi a požadavky zadavatele nejsou nepřiměřené." Pro úplnost Úřad dodává, že přestože se závěry soudu učiněné ve výše uvedeném rozsudku vztahují k zákonu č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů (dále jen „ZVZ”), lze je aplikovat rovněž i ve vztahu k zákonu, neboť princip zásady zákazu diskriminace zůstal i v souvislosti s rozhodnou právní úpravou zachován, tedy nezměněn.

87.         Úřad tedy shrnuje, že účelem požadavků na prokázání kvalifikace je objektivním, přiměřeným, transparentním a nediskriminačním způsobem zajistit, aby zadavatel vybíral dodavatele veřejné zakázky pouze z okruhu subjektů, jež poskytují záruky své schopnosti veřejnou zakázku řádně, včas a v odpovídající kvalitě realizovat. Zadavatel však nemůže vymezením kvalifikačních kritérií, zejména stanovením nepřiměřeně přísných kritérií prokázání způsobilosti dodavatele, ovlivnit okruh dodavatelů tak, že se zadávacího řízení z důvodu nepřiměřeně a diskriminačně nastavených kritérií kvalifikace nebude moci účastnit dodavatel, který by jinak byl objektivně způsobilý veřejnou zakázku realizovat. Zadavatel by se tak měl zdržet stanovení zadávacích podmínek, které omezují hospodářskou soutěž bezdůvodným zvýhodňováním nebo znevýhodňováním určitých dodavatelů, nemá-li příslušná zadávací podmínka oporu v legitimních (odůvodněných) potřebách zadavatele. Na případnou bezdůvodnost omezování hospodářské soutěže je nutné pohlížet právě z pohledu předmětu veřejné zakázky a z něj vyplývajících oprávněných požadavků zadavatele.

88.         Předmětem posouzení Úřadu v šetřeném případě je, zda zadavatel vymezil minimální úroveň kritérií technické kvalifikace rámcové dohody v souladu se zásadou přiměřenosti zakotvenou v § 6 odst. 1 zákona a zásadou zákazu diskriminace zakotvenou v § 6 odst. 2 zákona [a na ni navazujícím ustanovením § 36 odst. 1) zákona] a v souladu s § 73 odst. 6 zákona, tzn. takovým způsobem, aby odpovídala rozsahu a složitosti předmětu zadávané rámcové dohody, tedy zda je požadavek na významnou službu spočívající v prokázání realizace nejméně 2 řešení umožňujících identifikaci uživatele napojením na Národní Identitní Autoritu (NIA) a Informační systém datových schránek (ISDS) ospravedlnitelný v kontextu předmětu rámcové dohody.

89.         Jak již Úřad uvedl výše (viz blíže např. body 79 a 80 odůvodnění tohoto rozhodnutí), dle zadavatele je takto specifikovaný požadavek přiměřený, a to proto, že je relevantní ve vztahu k předmětu plnění. Nadto zadavatel upozornil, že je organizační složkou státu, a na další okolnosti týkající se požadovaného předmětu plnění, z nichž dle jeho vyjádření plyne, že potřebuje zajistit nejvyšší kvalitu poskytovaných služeb, a v tomto kontextu je jím stanovený požadavek nezbytný. Zadavatel také poukázal na to, že pokud existuje omezený počet dodavatelů, kteří mají zkušenosti s předmětným napojením, neznamená to, že stanovil podmínky diskriminačně, ale že tito dodavatelé jednoduše nejsou schopni splnit kvalifikaci. Zadavatel uvedl, že při realizaci plnění bude potřeba dodržet jím definované integrační požadavky, jedním z nich je požadavek pro ověření uživatele bude řešení využívat modul cPortál/CAS, který zajistí jednoznačnou identifikaci subjektu vůči Národní identitní autoritě (NIA) a Informačnímu systému datových schránek (ISDS). Uvedené vede dle názoru zadavatele k tomu, že oproti standardním API zadavatelem poptávaný vývoj programových rozhraní (API) obsahuje specifický bezpečnostní prvek.

90.         Úřad uvádí, že za účelem zjištění relevantních skutečností pro posouzení této otázky vedl šetření, přičemž vedle stanovisek účastníků řízení a jejich vzájemných replik (viz výše co se týče popisu průběhu správního řízení) se Úřad obrátil za účelem získání odborného stanoviska k řešeným otázkám též na Digitální a informační agenturu (DIA), neboť se jedná o ústřední správní úřad pro elektronickou identifikaci a služby vytvářející důvěru a pro informační systémy veřejné správy dle § 2a odst. 2 zákona č. 12/2020 Sb., o právu na digitální služby a o změně některých zákonů, ve znění pozdějších předpisů, a též vzhledem k působnosti DIA dle odst. 3 téhož ustanovení tohoto zákona (viz bod 48 a násl. odůvodnění tohoto rozhodnutí).

91.         K zadavatelem stanovené a zde přezkoumávané zadávací podmínce, jakož i k výše předestřené argumentaci zadavatele, Úřad obdržel od DIA vyjádření, v němž DIA v souhrnu uvedla, že považuje za správné a obezřetné ze strany zadavatele požadovat po dodavateli jisté zkušenosti s realizací poptávaného plnění, neboť implementace aplikačních rozhraní NIA nemusí být bezproblémová, nicméně tyto zkušenosti nemusejí být omezeny toliko na využití protokolů pro integraci identifikace a autentizace s NIA. DIA ve stejném duchu též uvedla, že nelze říci, že by s vynaložením přiměřené pracnosti kvalifikovaný programátor integraci na API ISDS nezvládl. Proto DIA nepokládá za důvodné omezovat prokázání kvalifikace uchazeče výhradně na integraci na API ISDS. S ohledem na požadavek na dodržení projektového harmonogramu a efektivní výkonové spotřeby lidských kapacit dodavatele, by DIA považovala za oprávněné prokázání zkušenosti s „integrací obdobného autentizačního API s využitím serverové komunikace založené na TLS/SSL protokolu a autentizace serverovým certifikátem.“

92.         DIA označila tvrzení zadavatele o přítomnosti unikátního bezpečnostního prvku, který je dle zadavatele zásadním rozdílem mezi požadovaným plněním a standardním API, z čehož důvodu není možné akceptovat jako srovnatelně kvalifikované dodavatele se zkušenostmi s realizací jiných API, za „nepřesné“. DIA své závěry shrnula tak, že pokládá za oprávněné požadovat zkušenost s využitím výše uvedených standardů z důvodu mitigace rizik projektu. Nepokládá však za oprávněné omezení na zkušenosti pouze s napojením na NIA a ISDS. „Stejně validní může být zkušenost s napojením na jiné poskytovatele federačních služeb, kteří používají výše uvedené protokoly ve stejném rozsahu (viz dokumentace pro kvalifikované poskytovatele a uživatele ISDS).“

93.         Ve svém vyjádření k výše zmíněné argumentaci DIA souhlasil zadavatel s názorem DIA týkajícím se nutnosti stanovení takového požadavku z důvodu mitigace rizik projektu, a to zejména rizika časového a kvalitativního, tedy toho, že bude dodavatel schopen takto koncipovanou službu splnit včas a bez chyb. Naprostá eliminace, či jejich naprostá minimalizaci možných rizik je dle zadavatele nezbytností, což má zajistit právě tímto způsobem stanovená podmínka. Navíc není požadované řešení dle zadavatele standardní a takto stanovený požadavek je dle jeho vyjádření logický a oprávněný. Úřad k tomuto doplňuje, že zadavatel se však vůbec nevyjádřil ke skutečnosti, že DIA nepovažuje za oprávněné omezení referenčních služeb na zkušenosti pouze s napojením na NIA a ISDS, stejně tak nechal zadavatel bez povšimnutí a nezpochybnil další závěr DIA, dle kterého může být validní zkušenost s napojením na jiné poskytovatele federačních služeb, kteří používají výše uvedené protokoly ve stejném rozsahu.

94.         Úřad přistoupil k posouzení, zda jsou řešení s napojením na NIA a ISDS natolik specifická, že je nemožné zkušenost s nimi substituovat jinou, případně podobnou zkušeností.

95.         Úřad uvádí, že požadavek na významnou službu s řešením umožňujícím identifikaci uživatele napojením na NIA a ISDS nelze bez dalšího zdůvodnit pouze tím, že se bude plnění rámcové dohody dotýkat přímo této oblasti, a to zvlášť v případě, že by mohla existovat další řešení, resp. dodavatelé disponující zkušenostmi, která jsou s požadovaným způsobem řešení srovnatelná, byť bezesporu tento požadavek replikuje poptávaný předmět plnění.

96.         Úřad na tomto místě konstatuje, že dle DIA webové řešení s napojením na aplikační rozhraní NIA či ISDS představuje API s veřejně dostupnou, dobře a standardizovaně zaprotokolovanou dokumentací. DIA také uvedla, že pro toto připojení NIA je možné využít standard WS-Federation nebo standard eIDAS SAML 2.0, přičemž odkázala na dokumentaci k těmto protokolům. Dle DIA by tak bylo správné a obezřetné ze strany zadavatele požadovat zkušenosti s výše uvedenými protokoly, nicméně tyto zkušenosti nemusejí být omezeny na využití těchto protokolů pro integraci identifikace a autentizace s NIA. Dále DIA uvedla, že není pravdou, že by s vynaložením přiměřené pracnosti kvalifikovaný programátor integraci na aplikační rozhraní ISDS nezvládl, proto není důvodné omezovat prokázání kvalifikace uchazeče výhradně na integraci na aplikační rozhraní ISDS, ale zadavatel by měl umožnit i prokázání zkušenosti s integrací obdobného autentizačního API s využitím serverové komunikace založené na TLS/SSL protokolu a autentizace serverovým certifikátem. V souhrnu tak dle DIA není věcný důvod k tomu, že zadavatel omezuje prokazované zkušenosti pouze na napojení na NIA a ISDS, neboť stejně validní může být zkušenost s napojením na jiné poskytovatele federačních služeb, kteří používají výše uvedené protokoly ve stejném rozsahu.

97.         Vzhledem k působnosti a odborné kompetenci DIA v této oblasti Úřad na tomto místě konstatuje, že považuje právě uvedené skutečnosti za bez důvodných pochybností zjištěný skutkový stav, z čehož vyplývá, že předmětný požadavek zadavatele nelze považovat za důvodný, neboť bez objektivního důvodu svou nepřiměřenou přísnosti může omezovat okruh možných dodavatelů, kteří by jinak byli objektivně způsobilí poptávaný předmět plnění realizovat.

98.         Zadavatel navíc neuvedl žádný relevantní důvod, pro nějž by dodavatelé, kteří v minulosti realizovali zakázky s využitím výše zmíněných standardů (tedy ne výhradně v souvislosti s integrací na aplikační rozhodní pouze NIA či ISDS), neměli být způsobilí realizovat předmět rámcové dohody. Zadavatel tedy pochybil, když předmětný požadavek technické kvalifikace na referenční služby omezil toliko na řešení zahrnující napojení výhradně na NIA a ISDS, aniž by to byl schopen jakkoliv objektivně odůvodnit. Úřad dodává, že rozumí potřebě zadavatele ověřit si, že dodavatel disponuje zkušeností s napojením, jež je předmětem plnění rámcové dohody. Takto formulovaná podmínka je však bez objektivního důvodu příliš specifická, a tedy bezdůvodně omezující hospodářskou soutěž.

99.         S ohledem na výše uvedené Úřad konstatuje, že zadavatel přezkoumávané kritérium technické kvalifikace formuloval v rozporu se zásadou přiměřenosti a zákazu diskriminace, jakož i s ustanovením § 36 odst. 1 zákona, když jeho prostřednictvím bezdůvodně omezil hospodářskou soutěž.

100.     Úřad na tomto místě připomíná, že je zadavatel sice oprávněn stanovit kvalifikační podmínky dle svých potřeb, nicméně je zároveň nutné stanovit je v minimální možné úrovni, která je potřebná pro plnění veřejné zakázky, v šetřeném případě rámcové dohody. Jak ostatně stanovuje § 73 odst. 6 písm. b) zákona, pokud zadavatel požaduje prokázání ekonomické nebo technické kvalifikace, musí v zadávací dokumentaci přiměřeně vzhledem ke složitosti a rozsahu předmětu veřejné zakázky stanovit minimální úroveň pro jejich splnění.  S ohledem na výše uvedené Úřad konstatuje, že zadavatel přezkoumávané kritérium technické kvalifikace formuloval také v rozporu s výše citovaným ustanovením, když jeho prostřednictvím nestanovil v zadávací dokumentaci minimální úroveň tohoto kvalifikačního kritéria přiměřeně vzhledem ke složitosti a rozsahu předmětu plnění veřejné zakázky, resp. rámcové dohody.

101.     S ohledem na výše uvedené rozhodl Úřad tak, jak je uvedeno ve výroku I. tohoto rozhodnutí.

K výroku II. tohoto rozhodnutí

Skutečnosti vyplývající z dokumentace o zadávacím řízení

102.     Výzvou k písemnému objasnění či doplnění nabídky dle § 46 zákona ze dne 29. 5. 2023 (dále jen „výzva k objasnění nabídky“) vyzval zadavatel účastníka zadávacího řízení, dodavatele Atos IT Solutions and Services, s.r.o., IČO 44851391, se sídlem Doudlebská 1699/5, 140 00 Praha (dále jen „Atos IT“), k objasnění podané nabídky mimo jiné v následujícím ohledu:

„Účastník v nabídce pro účely prokázání technické kvalifikace dle § 79 odst. 2 písm. c) a d) ZZVZ spočívající ve splnění požadavku na doložení absolvování procesů mezinárodní certifikace v oblasti portálového řešení vybranými členy realizačního týmu na pozicích vývojových pracovníků pro portálové technologie předložil následující doklady, resp. odkazy:

• certifikát osvědčující, že lng. Radim Drtílek má ode dne 22. 12. 2017 certifikaci Microsoft Certified: Azure Developer Associate,
• certifikát osvědčující, že Ing. Radim Drtílek má ode dne 2. 6. 2022 certifikaci Microsoft Certified: Power Platform Developer Associate,
• odkaz na webovou stránku provozovanou společností Microsoft Corporation, ze které mát být patrné, že pan Michal Dub má ode dne 12. 7. 2022 certifikaci Microsoft Certified: Azure Developer Associate, a
• odkaz na webovou stránku provozovanou společností Microsoft Corporation, ze které má být patrné, že pan Michal Dub má ode dne 7. 2. 2022 certifikaci Microsoft Certified: Power Platform Fundamental.

V profesních životopisech jmenovaných vývojových pracovníků pro portálové řešení je k daným certifikacím uvedeno následující: ,Certifikace prokazují sadu dovedností v oblasti cloudových služeb a jejich poskytování pomocí technologií Azure, které jsou Základem návrhu webového klienta v této nabídce a jsou klíčové pro vývoj a správu webových portálů na této platformě.´ Z citovaného není zadavateli zcela zřejmé, zda se skutečně jedná o certifikaci, která osvědčuje významné dovednosti v oblasti portálových řešení, nebo s touto oblastí pouze okrajově souvisí.

 Zadavatel proto vyzývá účastníka k objasnění, co je konkrétní náplní uvedených procesů certifikace a jakým konkrétním způsobem jimi osvědčené dovednosti souvisí s portálovými řešeními.“

Právní posouzení

103.     Úřad nejprve v obecné rovině uvádí, že řádné stanovení zadávacích podmínek je jednou ze základních povinností zadavatele v rámci zadávacího řízení a má výrazný dopad na jeho další průběh, neboť potenciální dodavatelé se na základě zadávacích podmínek rozhodují, zda se budou o předmětnou rámcovou dohodu ucházet. Zadávací podmínky by tak měly představovat konkrétní vyjádření jednotlivých požadavků zadavatele, jež jsou formálně zachyceny v zadávací dokumentaci. Odpovědnost za nastavení zadávacích podmínek leží plně na zadavateli, přičemž tento nesmí odpovědnost za správnost a úplnost zadávacích podmínek přenášet na dodavatele, jak explicitně plyne z § 36 odst. 3 zákona. Nejvyšší správní soud v tomto kontextu v rozsudku č. j. 9 Afs 30/2010-182 ze dne 16. 11. 2010 uvedl, že „zadávací dokumentace je nejvýznamnějším dokumentem v rámci zadávacího řízení. Za jeho zpracování je plně odpovědný zadavatel a je povinen ho zpracovat dostatečně kvalitně a s patřičnou odborností tak, aby na jeho základě bylo možno podat odpovídající a především vzájemně porovnatelné nabídky.“[10] Požadavky zadavatele musí být proto v zadávací dokumentaci vymezeny způsobem, který bude vnímán a chápán všemi subjekty stejně a jednoznačně a který nesmí dávat žádný prostor pro pochybnosti či rozdílný výklad. Úřad v tomto smyslu odkazuje např. na rozsudek Krajského soudu v Brně č. j. 62 Af 40/2013-127 ze dne 18. 9. 2014, kde soud v odůvodnění uvedl, že „při zpracování nabídky musí být jednotlivým uchazečům mimo jiné zřejmé, jak má být nabídka zpracována, aby vyhověla požadavkům zadavatele (…) nemůže obstát taková zadávací dokumentace, z níž zadavatelovy požadavky na zpracování nabídky nevyplývají jasně, přesně, srozumitelně a jednoznačně, tj. která v těchto ohledech objektivně připouští rozdílný výklad.“

104.     Úřad v této souvislosti cituje také z rozsudku Krajského soudu v Brně č. j. 62 Ca 77/2008 ze dne 4. 11. 2010, který uvedl, že „(…) zadávací dokumentace musí být transparentní, dostatečně konkrétní a srozumitelná tak, aby na jejím základě mohla proběhnout všestranně korektní veřejná soutěž, v jejímž rámci bude vybrána ta nejlepší nabídka“. V citovaném rozsudku Krajský soud dále odkázal na rozsudek Nejvyššího správního soudu č. j. 2 Afs 86/2008-222 ze dne 25. 3. 2009, ve kterém Nejvyšší správní soud taktéž zdůraznil, že „[n]emůže tedy obstát taková zadávací dokumentace, z níž požadavky na zpracování nabídky a následně hodnotící kritéria nejsou zcela srozumitelná a jednoznačná, tj. pokud objektivně připouštějí rozdílný výklad a vzniká tak interpretační nejistota.“

105.     Požadavek jednoznačnosti, konkrétnosti a přesnosti zadávací dokumentace obecně plyne rovněž ze zásady transparentnosti zakotvené v ustanovení § 6 odst. 1 zákona. Zásada transparentnosti zadávání veřejných zakázek je totiž vedle mimo jiné zásady přiměřenosti, rovného zacházení a zákazu diskriminace jednou ze základních zásad, která musí být zadavatelem bezvýhradně dodržována v celém průběhu zadávacího řízení.

106.     Zásadou transparentnosti se ve své judikatorní činnosti rozsáhle a opakovaně zabývaly soudy a taktéž Úřad. Nejvyšší správní soud se k dané problematice vyjádřil např. ve svém rozsudku č. j. 1 Afs 45/2010-159 ze dne 15. 9. 2010, který potvrzuje výklad zásady transparentnosti Krajského soudu v Brně podaný v rozsudku č. j. 62 Ca 31/2008-114 ze dne 19. 1. 2010, a sice že požadavek transparentnosti není splněn tehdy, pokud jsou v postupu zadavatele shledány „takové prvky, jež by zadávací řízení činily nekontrolovatelným, hůře kontrolovatelným, nečitelným a nepřehledným nebo jež by vzbuzovaly pochybnosti o pravých důvodech jednotlivých kroků zadavatele“. V rozsudku Krajského soudu v Brně č. j. 62 Af 50/2011-72 ze dne 15. 2. 2012 pak bylo konstatováno, že „[ú]kolem zásady transparentnosti je zajištění toho, aby zadávání veřejných zakázek probíhalo průhledným, právně korektním a předvídatelným způsobem za předem jasně a srozumitelně stanovených podmínek. (…) Porušením této zásady pak je jakékoli jednání zadavatele, které způsobuje nečitelnost zadávacího řízení. Tak tomu může být např. i tehdy, pokud zadávací dokumentace neobsahuje jednoznačně a srozumitelně formulovaná pravidla. Pokud pak zadávací dokumentace, resp. v ní obsažené zadavatelovy požadavky na zpracování nabídky objektivně připouští rozdílný výklad, nemůže taková interpretační nejistota stíhat žádného z uchazečů, ale zadavatele samotného.“

107.     Obdobný názor je zastáván i konstantní rozhodovací praxí Úřadu, kdy je kladen důraz na to, aby požadavky zadavatele byly v zadávací dokumentaci vymezeny především objektivně, tj. takovým způsobem, který bude vnímán a chápán všemi dotčenými subjekty, jak zadavatelem, tak dodavateli, stejným způsobem. Požadavky zadavatele musí být rovněž stanoveny jednoznačně, tj. nesmí dávat žádný prostor pro pochybnosti či rozdílný výklad.

108.     K interpretační nejistotě plynoucí z případné možnosti rozdílného výkladu dále předseda Úřadu v rámci rozhodnutí č. j. ÚOHS-R0213/2017/VZ-03918/2018/322/KTr ze dne 8. 2. 2018 uvádí, že „[j]estliže zadávací dokumentace obsahuje podmínky, které nejsou jasně a srozumitelně formulovány, vzniká interpretační nejistota na straně dodavatelů. Ti si nemohou být jisti, zda nebude jejich nabídka z důvodu nesplnění předmětné podmínky vyloučena. Nejasnost zadávací podmínky může též učinit netransparentní rozhodování hodnotící komise, která má splnění kvalifikace posuzovat podle zadavatelem stanovených zadávacích podmínek, přičemž při stanoveném neurčitém pojmu se může hodnotící komise přiklonit k různým výkladům. Lze tedy shrnout, že existuje právní zájem nejen na zajištění co nejširší hospodářské soutěže, ale i na zajištění transparentnosti zadávacího řízení, která zajišťuje mimo jiné objektivní hodnocení nabídek a možnost objektivního přezkumu toho, zda zadavatel hodnotil nabídky takovým způsobem, jakým podle zadávací dokumentace měl, a vybral tak dodavatele s ekonomicky nejvýhodnější nabídkou.“

109.     V citovaném rozhodnutí se předseda Úřadu dále krátce věnoval i možnému vlivu na výběr dodavatele, přestože možnost ovlivnění výběru dodavatele již není na rozdíl od předchozí právní úpravy nutné zkoumat: „Netransparentní způsob stanovení technického kvalifikačního předpokladu mohl zapříčinit, že někteří dodavatelé si mohli daný požadavek zadavatele vyložit jiným způsobem než zadavatel a dospět k závěru, že předmětný technický kvalifikační předpoklad nesplňují a nabídku do zadávacího řízení proto nepodali, přičemž nelze vyloučit, že mohli zadavateli nabídnout výhodnější plnění. Dodavatelé též mohli být od podání nabídky odrazeni z důvodu netransparentního kvalifikačního předpokladu, jelikož si nemohli být jisti, jaký výklad dané zadávací podmínky ,zvolí' zadavatel či hodnotící komise, přičemž nechtěli vynakládat prostředky na vytvoření nabídky, když neměli jistotu, zda nebudou ze zadávacího řízení vyloučeni.“

110.     V šetřeném případě je mezi účastníky správního řízení sporu o tom, zda zadávací podmínka spočívající v požadavku zadavatele, aby členové týmu dodavatele „vývojoví pracovníci pro portálové technologie“ byli držiteli „mezinárodní certifikace v oblasti portálového řešení“, byla stanovena v souladu se zákonem, tedy zda zadavatel vymezil předmětný požadavek na předložení certifikace výše uvedených osob v podrobnostech nezbytných pro účast dodavatele v předmětném zadávacím řízení. Navrhovatel v tomto ohledu tvrdí, že z takto formulované podmínky neví, jakou konkrétní certifikaci by měl ve své nabídce předložit.

111.     Úřad zjistil, že v kapitole VI. „Podmínky kvalifikace“ části (1) odst. D) „Technické kvalifikace podle § 79 odst. 2 písm. c) ZZVZ“ písmene c)  „2 vývojoví pracovníci pro portálové technologie“ zadávací dokumentace zadavatel stanovil, že oba vývojoví pracovníci musí být držiteli „mezinárodní certifikace v oblasti portálového řešení“. Přičemž takto formulovaný požadavek zadavatel nikde dále v zadávací dokumentaci nerozvedl ani nevysvětlil.

112.     V této souvislosti Úřad uvádí, že vymezení kvalifikačních podmínek závisí pouze na zadavateli, jeho potřebách a preferencích. Není vyžadováno ani určení kvalifikace dodavatelů do všech myslitelných podrobností, neboť zadavatel je oprávněn počítat i s přiměřenou odbornou zdatností a informovaností relevantních dodavatelů. Avšak zároveň je třeba vzít v úvahu to, že právo zadavatele vymezit kvalifikační kritéria není bezbřehé a zadavatel musí nastavit zadávací podmínky nejen tak, aby reflektovaly jeho potřeby, ale zároveň tak, aby odpovídaly požadavkům zákona, tedy aby byly dostatečně přesné a určité a umožňovaly podat vzájemně porovnatelné nabídky korespondující s účelem využití požadovaného plnění. V některých případech může být pro zadavatele technicky komplikované s ohledem na jemu dostupné informace nebo nadbytečné z pohledu požadovaného plnění vymezit požadavek na kvalifikaci dodavatelů zcela detailně. Ani za těchto okolností však nemůže zadavatel na dostatečně určité stanovení zadávacích podmínek rezignovat a musí pro definování svých kvalifikačních požadavků na potenciální dodavatele vyvinout maximální úsilí tak, aby jednak potenciálním dodavatelům poskytl, pokud ne zcela podrobné, pak alespoň dostatečně jasné informace o tom, co bude v rámci hodnocení kvalifikačních kritérií zadavatelem považováno za přijatelné, a rovněž tak, aby bylo objektivně vyloučeno to, že některý z dodavatelů by mohl být v důsledku nekonkrétnosti zadávacích podmínek znevýhodněn.

113.     Zadavatel ve svých vyjádřeních uvedl, že se pojmem „mezinárodní certifikace v oblasti portálového řešení“ rozumí certifikace v oblasti prostředí AZURE, jelikož webový klient pro NCTS, AES a eDovoz bude provozován v cloudu v prostředí AZURE. Zadavatel zároveň odkazuje na čl. 2.8 technické specifikace, v němž je uvedeno, že tyto aplikace budou provozovány v prostředí Azure (veřejný cloud) nebo Azure stack (privátní cloud) (viz bod 39 odůvodnění tohoto rozhodnutí).

114.     Argumentace zadavatele spočívá v tom, že si má potenciální dodavatel dovodit, že pojem „mezinárodní certifikace v oblasti portálového řešení“ souvisí právě s obsahem čl. 2.8 technické specifikace, byť Úřad poukazuje na skutečnost, že ve stanoveném znění předmětné podmínky kvalifikace není žádný odkaz na tuto technickou specifikaci.  Úřad však uvádí, že ani v citovaném článku technické specifikace pak není žádným způsobem zmíněno nebo odkázáno na to, že by se v případě předmětného kvalifikačního požadavku mělo jednat o certifikaci v prostředí Microsoft AZURE.  

115.     V souvislosti s posuzovanou otázkou nejednoznačnosti daného požadavku si Úřad rovněž vyžádal odborné stanovisko DIA, která ve svém vyjádření ze dne 18. 9. 2023 uvedla, že „[v]zhledem k uvedené textaci požadavku dle našeho názoru není možné jednoznačně definovat, jaké ‚mezinárodní certifikace v oblasti portálového řešení‘ budou zadavatelem akceptovány.“ K argumentaci zadavatele, že se „mezinárodní certifikací v oblasti portálového řešení“ myslí certifikace v prostředí AZURE, DIA uvedla, že není možné posoudit, zda je či není možné jednoznačně a bez jakýchkoliv pochybností dovodit souvislost s certifikací v prostředí AZURE, přičemž zároveň uvedla, že sám o sobě takto specifikovaný požadavek nelze považovat za jednoznačný.

116.     Úřad vzhledem k výše uvedenému konstatuje, že na základě zjištěných skutečností dospěl k závěru, že je takto stanovené kvalifikační kritérium příliš vágní.  Použitý pojem „mezinárodní certifikace v oblasti portálového řešení“ je natolik široký a obecný, že nelze přesně vymezit jeho rozsah a skupina přiměřeně informovaných subjektů (dodavatelů) nemusí tento pojem vykládat stejným způsobem. Nelze jej tedy považovat za dostatečně jednoznačný či konkrétní, tj. nepřipouštějící různé výklady. Uchazečům o rámcovou dohodu tak nemohlo být dopředu zřejmé, jaké certifikace zadavatel požaduje, a jaké naopak již bude považovat za nedostatečné.

117.     Zadavatel svou argumentací zároveň de facto potvrzuje, že postupoval v rozporu s § 36 odst. 3 zákona, dle kterého zadavatel nesmí přenášet odpovědnost za správnost a úplnost zadávacích podmínek na dodavatele. Zadavatel totiž zjevně předpokládal, že si dodavatelé sami dovodí, že jím použitý termín „mezinárodní certifikace v oblasti portálového řešení“ je nad všechny pochybnosti propojitelný s (nevyřčeným) požadavkem zadavatele na certifikaci v prostředí AZURE.

118.     Navíc v souvislosti s touto argumentací zadavatele lze na tomto místě poukázat na výzvu k objasnění nabídky dodavatele Atos IT ze dne 29. 5. 2023 (viz bod 102 odůvodnění tohoto rozhodnutí), v níž zadavatel žádá tohoto dalšího účastníka zadávacího řízení k doložení právě té skutečnosti, neboť mu není zřejmá, jakým způsobem dovednosti osvědčené mimo jiné certifikátem Microsoft Certified: Azure Developer Associate, souvisí s portálovými řešeními. Z uvedeného je zřejmé, že účastník zadávacího řízení doložil zadavateli certifikaci v prostředí Azure (Microsoft Certified: Azure Developer Associate). Zadavatel nicméně i tak požádal účastníka řízení o doložení souvislosti dané certifikace s pojmem portálového řešení. Úřad si z uvedeného dovozuje, že si ani sám zadavatel při přípravě zadávacích podmínek nebyl jistý, jaké certifikáty jsou s to prokázat kvalifikaci dodavatelů takovým způsobem, jakým ji stanovil v zadávacích podmínkách. Uvedené navíc znevažuje věrohodnost pozdější argumentace zadavatele uplatněné ve správním řízení, kde pojem „certifikace v oblasti portálových řešení“ zadavatel konkretizuje právě již na certifikaci v prostředí Microsoft AZURE. Je tedy zřejmé, že minimálně v době, kdy zadavatel vyhotovoval uvedenou výzvu k objasnění nabídky dodavatele Atos IT, zadavatel nevěděl, že certifikace v prostředí Microsoft AZURE odpovídá jím požadované certifikaci. Ve chvíli, kdy si sám zadavatel není jistý, co v zadávacích podmínkách vlastně požaduje, je nemožné očekávat od dodavatelů, že takto stanovenou podmínku pochopí. Úřad nadto připomíná a souhlasí vyjádřením navrhovatele, v němž navrhovatel poukázal na to, že odkaz na certifikace v prostředí AZURE je značně široký a na zadavatelem odkazovaných stránkách Microsoft Certifications (Microsoft Learn) je možné najít desítky certifikací obsahujících pojem AZURE, přičemž mnohé z nich již dle svého názvu vůbec nesouvisí s oblastí poptávaného plnění (pro příklad „Microsoft Certified: Azure Cosmos DB Developer Specialty“). S tímto vyjádřením Úřad souzní a poukazuje na to, že ani v průběhu správního řízení nebyl zadavatel schopen konkretizovat ani obhájit svůj požadavek uvedený v zadávacích podmínkách.

119.     Ze shora uvedeného je tak zřejmé, že zadavatel v zadávací dokumentaci předmětný požadavek na kvalifikaci nedefinoval dostatečně konkrétně, neboť jím použitý pojem „mezinárodní certifikace v oblasti portálového řešení“ je natolik široký a obecný, že nelze přesně vymezit jeho hranice. Informace, jež se dostaly potenciálním uchazečům prostřednictvím zadávací dokumentace, nejsou dostatečně konkrétní a jednoznačné, aby si dodavatelé mohli udělat přesnou představu, jakým konkrétním certifikátem by měli členové realizačního týmu disponovat, aby prokázali splnění daného požadavku zadavatele na kvalifikaci.

120.     S ohledem na výše uvedené skutečnosti tak Úřad uzavírá, že stanovením předmětné zadávací podmínky zadavatel postupoval v rozporu s § 36 odst. 3 zákona ve spojení se zásadou transparentnosti zakotvenou v § 6 odst. 1 zákona.

121.     Úřad proto rozhodl tak, jak je uvedeno ve výroku II. tohoto rozhodnutí.

K dalším navrhovatelem namítaným skutečnostem

122.     Pro úplnost Úřad dodává, že se v šetřeném případě již nezabýval dalšími námitkami, jež navrhovatel ve svém návrhu zmiňuje ve vztahu k zadávacím podmínkám, jelikož má Úřad za to, že šetření dalších skutečností uvedených v návrhu by nemohlo mít vliv na výsledek správního řízení za situace, když již bylo dovozeno, že zadavatel stanovil zadávací podmínky v rozporu se zákonem. Úřad tak postupuje v souladu s ustálenou rozhodovací praxí, z níž lze vyvodit, že zkoumání dalších důvodů pro uložení nápravného opatření je nadbytečné, existuje-li alespoň jeden oprávněný důvod. Takový postup v rámci přezkumu je nejen v souladu s rozhodovací praxí Úřadu a správních soudů, ale je též v souladu se zásadou procesní ekonomie. Je neúčelné, aby se Úřad věcně zabýval všemi důvody pro uložení nápravného opatření a k prokázání či vyvrácení jejich existence prováděl rozsáhlé dokazování, jež neúměrně zatíží účastníky řízení i Úřad a případně též nedůvodně pozdrží průběh správního řízení. Pokud tedy Úřad dospěje k závěru, že alespoň jeden důvod pro uložení nápravného opatření existoval, je zkoumání existence dalších důvodů nadbytečné. I kdyby totiž existence ostatních důvodů pro uložení nápravného opatření byla vyvrácena, popř. potvrzena, nemohla by tato skutečnost nic změnit na tom, že zadavatel stanovil zadávací podmínky v rozporu se zákonem a je tudíž nezbytné uložit nápravné opatření spočívající ve zrušení zadávacího řízení.

K návrhu na provedení a doplnění důkazů

123.     K návrhu navrhovatele na provedení a doplnění důkazů (viz bod 18 odůvodnění tohoto rozhodnutí) Úřad uvádí, že za současné skutkové situace nepovažuje za nutné provedení jakýchkoliv dalších důkazů, neboť relevantní okolnosti týkající se postupu zadavatele byly ve správním řízení dostatečným způsobem doloženy. Úřad, jak již bylo uvedeno výše, nemá pochybnosti o tom, že zadavatel v průběhu zadávacího řízení nepostupoval v souladu se zákonem, konkrétně pak zadavatel v rozporu se zákonem stanovil zadávací podmínky, přičemž jako nápravné opatření takového postupu je možné uložit jedině zrušení zadávacího řízení jako takového, Úřad tak nepovažuje za účelné zabývat se dalšími návrhy navrhovatele na provedení a doplnění důkazů.

K výroku III. tohoto rozhodnutí – uložení nápravného opatření

124.     Podle § 263 odst. 3 zákona stanoví-li zadavatel zadávací podmínky v rozporu s tímto zákonem, Úřad uloží nápravné opatření spočívající ve zrušení zadávacího řízení.

125.     Úřad výroky I. a II. tohoto rozhodnutí rozhodl o tom, že zadavatel stanovil zadávací podmínky v rozporu se zákonem.

126.     Úřad proto s ohledem na výše uvedené rozhodl o zrušení zadávacího řízení, jak je uvedeno ve výroku III. tohoto rozhodnutí.

K výroku IV. tohoto rozhodnutí – zákaz uzavřít smlouvu v zadávacím řízení

127.     Podle § 263 odst. 8 zákona ukládá-li Úřad nápravné opatření s výjimkou zákazu plnění smlouvy, zakáže zároveň zadavateli až do pravomocného skončení řízení uzavřít v zadávacím řízení smlouvu; rozklad proti tomuto výroku nemá odkladný účinek.

128.     Výše citované ustanovení formuluje jako obligatorní součást rozhodnutí Úřadu o uložení nápravného opatření (s výjimkou zákazu plnění smlouvy) rovněž výrok o tom, že zadavatel až do pravomocného skončení správního řízení nesmí uzavřít smlouvu v zadávacím řízení, přičemž tento výrok je účinný dnem vydání rozhodnutí, a tedy je účinný i u nepravomocného rozhodnutí. Tento zákaz uzavřít smlouvu se ukládá z důvodu, aby se zadavatel nemohl vyhnout splnění uloženého nápravného opatření uzavřením smlouvy ještě před nabytím právní moci rozhodnutí.

129.     Vzhledem k tomu, že Úřad tímto rozhodnutím ve výroku III. uložil nápravné opatření spočívající ve zrušení zadávacího řízení, zakázal zároveň ve výroku IV. tohoto rozhodnutí zadavateli až do pravomocného skončení tohoto správního řízení uzavřít v zadávacím řízení smlouvu.

K výroku V. tohoto rozhodnutí – povinnost uhradit náklady řízení

130.     Podle § 266 odst. 1 zákona je součástí rozhodnutí Úřadu, kterým se ukládá nápravné opatření nebo zákaz plnění smlouvy, též rozhodnutí o povinnosti zadavatele uhradit náklady správního řízení. Náklady řízení se platí paušální částkou, kterou stanoví Ministerstvo pro místní rozvoj vyhláškou. Příslušná vyhláška č. 170/2016 Sb., o stanovení paušální částky nákladů řízení o přezkoumání úkonů zadavatele při zadávání veřejných zakázek (dále jen „vyhláška“), stanoví v § 1, že paušální částka nákladů řízení o přezkoumání úkonů zadavatele, kterou je povinen zadavatel zaplatit v případě, že Úřad rozhodl o uložení nápravného opatření nebo zákazu plnění smlouvy, činí 30 000 Kč.

131.     Vzhledem k tomu, že Úřad tímto rozhodnutím ve výroku III. uložil nápravné opatření spočívající ve zrušení zadávacího řízení zahájeného za účelem uzavření rámcové dohody, rozhodl Úřad o uložení povinnosti uhradit náklady řízení, jak je uvedeno ve výroku V. tohoto rozhodnutí.

132.     Náklady řízení jsou splatné do dvou měsíců od nabytí právní moci tohoto rozhodnutí na účet Úřadu pro ochranu hospodářské soutěže zřízený u pobočky České národní banky v Brně číslo 19-24825621/0710, variabilní symbol - 2023000312.

K výroku VI. tohoto rozhodnutí – zastavení části správního řízení

133.     Úřad uvádí, že žádost navrhovatele ve věci uložení povinnosti zadavateli nahradit navrhovateli náklady řízení, které mu vznikly v souvislosti s jeho zastoupení advokátem, obdržel dne 29. 5. 2023 jakožto součást návrhu.

134.     Ustanovení § 1 odst. 2 správního řádu zakotvuje obecné procesní pravidlo, podle kterého se správní řád nebo jeho jednotlivá ustanovení použijí, pokud zvláštní zákon nestanoví jiný postup.

135.     Pokud jde o správní řízení vedená Úřadem ve věci dozoru nad dodržováním pravidel stanovených zákonem, je zvláštním zákonem ve smyslu ustanovení § 1 odst. 2 správního řádu zákon o zadávání veřejných zakázek. Vlastní procesní postup ohledně náhrady nákladů řízení, jež by vznikly účastníkům správního řízení, však tento zákon neobsahuje. Zákon v souvislosti s náklady řízení upravuje pouze povinnost Úřadu učinit součástí rozhodnutí Úřadu, kterým se ukládá nápravné opatření nebo zákaz plnění smlouvy, též rozhodnutí o povinnosti zadavatele uhradit náklady správního řízení (ust. § 266 odst. 1 zákona). Tyto náklady řízení se pak platí paušální částkou stanovenou vyhláškou (tj. ve výši 30 000 Kč v souladu s § 1 vyhlášky), přičemž se jedná o paušální náhradu nákladů, které vznikly správnímu orgánu. V případě posuzování obsahu žádosti navrhovatele ze dne 29. 5. 2023 je tedy Úřad povinen se řídit obecnou právní úpravou obsaženou ve správním řádu, jelikož právní úprava zvláštní nikterak neupravuje otázku uložení povinnosti nahradit náklady řízení vzniklé některému z jeho účastníků.

136.     V souladu s ustanovením § 79 odst. 3 správního řádu pak platí, že si správní orgán (nebo dotčený orgán) a účastník nesou své náklady, nestanoví-li zákon jinak. Na daný případ nedopadá žádný zákon, resp. žádná právní norma, která by stanovila, že účastník správního řízení nenese své náklady. Ve správním řízení o přezkoumání úkonů zadavatele tak platí, že jeho účastníci si své náklady nesou vždy sami.

137.     Úřad konstatuje, že žádost lze považovat za zjevně právně nepřípustnou zejména tehdy, jestliže právní úprava neumožňuje, aby takové žádosti mohl správní orgán vyhovět. Vzhledem k tomu, že navrhovatel v rámci podaného návrhu podal k Úřadu žádost, ve které se domáhal, aby bylo rozhodnuto o uložení povinnosti zadavatele nahradit navrhovateli náklady řízení, které mu vznikly v souvislosti s jeho zastoupení advokátem, je zřejmé, že stávající právní úprava neumožňuje, aby Úřad žádosti navrhovatele vyhověl. Úřad tedy i bez dalšího dokazování již ze samotné žádosti seznal, že jí vyhovět nelze, pročež nezbývá než uzavřít, že se v posuzovaném případě jedná o žádost zjevně právně nepřípustnou ve smyslu ustanovení § 66 odst. 1 písm. b) správního řádu.

138.     Vzhledem k výše uvedeným skutečnostem Úřad rozhodl tak, jak je uvedeno ve výroku VI. tohoto rozhodnutí.

Poučení

Proti tomuto rozhodnutí lze do 15 dnů ode dne jeho doručení podat rozklad k předsedovi Úřadu pro ochranu hospodářské soutěže, a to prostřednictvím Úřadu pro ochranu hospodářské soutěže – Sekce veřejných zakázek, třída Kpt. Jaroše 1926/7, Černá Pole, 604 55 Brno. Včas podaný rozklad proti výrokům I., II. III. a V. tohoto rozhodnutí má odkladný účinek. Rozklad proti výroku IV. tohoto rozhodnutí nemá podle § 263 odst. 8 zákona odkladný účinek. Rozklad podaný proti výroku VI. tohoto rozhodnutí nemá podle § 76 odst. 5 správního řádu odkladný účinek. Rozklad a další podání účastníků učiněná v řízení o rozkladu se podle § 261 odst. 1 písm. b) zákona činí výhradně prostřednictvím datové schránky nebo jako datová zpráva podepsaná uznávaným elektronickým podpisem.

otisk úředního razítka

Mgr. Markéta Dlouhá

místopředsedkyně

Obdrží

1.      Česká republika - Generální ředitelství cel, Budějovická 1387/7, 140 00 Praha 4

2.      JUDr. Jan Boltnar, Ph.D., advokát, Růžová 972/1, 110 00 Praha 1

2.

Vypraveno dne

viz otisk razítka na poštovní obálce nebo časový údaj na obálce datové zprávy

---

[1] Pozn. Úřadu - API (zkratka pro Application Programming Interface) označuje v informatice rozhraní pro programování aplikací.

[2] Pozn. Úřadu – Jedná se o certifikát prokazující znalost modelovacího jazyka UML poskytovaný konsorciem pro standardy počítačového průmyslu Object Management Group (OMG), viz https://www.omg.org/about/index.htm.

[3] Pozn. Úřadu – UML, nebo-li The Unified Modeling Language je grafický jazyk pro specifikaci, vizualizaci, konstrukci a dokumentaci softwarových systémů nebo businessové modelování.

[4] Azure je veřejná cloudová platforma společnosti Microsoft – pozn. Úřadu; zdroj: https://learn.microsoft.com/cs-cz/azure/cloud-adoption-framework/get-started/what-is-azure.

[5] Je portál celní správy České republiky sloužící k elektronické komunikaci občanů a firem s Celní správou ČR – pozn. Úřadu.

[6] Dostupné na https://learn.microsoft.com/cs-cz/certifications/?WT.mc_id=certposter_poster-wwl.

[7] Dostupné na https://education.oracle.com/oracle-certification-path/pfamily_48.

[8] Dostupné na https://www.identitaobcana.cz/Home/Ovm.

[9] Úřad pro zjednodušení dále v textu užívá na mnoha místech pojem veřejná zakázka, byť si je vědom, že zde přezkoumávaný postup zadavatele se týká uzavření rámcové dohody.

[10] Ačkoliv byl citovaný rozsudek Nejvyššího správního soudu vydán za účinnosti ZVZ, jsou jeho závěry aplikovatelné i za účinnosti zákona, což paušálně platí i o ostatní judikatuře k ZVZ, kterou je v tomto rozhodnutí argumentováno - pozn. Úřadu.