číslo jednací: 38840/2021/500/AIv
spisová značka: S0084/2021/VZ

• Instance: I.
• Věc: Smlouva o poskytování Integračních zdrojů v rámci IS VZP ČR
• Účastníci:
  1. Všeobecná zdravotní pojišťovna České republiky
  2. SlovShore, s.r.o.
• Typ správního řízení: Veřejná zakázka
• Výrok: § 265 písm. a) zákona č. 134/2016 Sb.
• Rok: 2021
• Datum nabytí právní moci: 7. 2. 2022
• Související rozhodnutí: 38840/2021/500/AIv; 03822/2022/162; 19475/2024/162

Spisová značka:  ÚOHS-S0084/2021/VZ Číslo jednací:      ÚOHS-38840/2021/500/AIv

Brno 16. 11. 2021

Úř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 2. 3. 2021 na návrh z téhož dne, jehož účastníky jsou

• zadavatel – Všeobecná zdravotní pojišťovna České republiky, IČO 41197518, se sídlem Orlická 2020/4, 130 00 Praha 3,
• navrhovatel – SlovShore, s.r.o., IČO 35953713, se sídlem Ventúrská 3, 811 01 Bratislava, Slovenská republika, ve správním řízení zastoupena na základě plné moci ze dne 2. 3. 2021 JUDr. Janem Lukešem, Ph.D., advokátem, IČO 66253462, se sídlem Hybernská 1007/20, 110 00 Praha 1,

ve věci přezkoumání úkonů zadavatele učiněných při zadávání veřejné zakázky „Smlouva o poskytování Integračních zdrojů v rámci IS VZP ČR“ v otevřeném řízení, jehož oznámení bylo odesláno k uveřejnění dne 20. 11. 2020 a uveřejněno ve Věstníku veřejných zakázek dne 23. 11. 2020 pod ev. č. Z2020-041457, ve znění oprav uveřejněných dne 28. 12. 2020, dne 11. 1. 2021 a dne 1. 2. 2021 a v Úředním věstníku Evropské unie uveřejněno dne 25. 11. 2020 pod ev. č. 2020/S 230-567140, ve znění dodatečných informací uveřejněných dne 28. 12. 2020, dne 12. 1. 2021 a dne 1. 2. 2021,

rozhodl takto: 

Návrh navrhovatele – SlovShore, s.r.o., IČO 35953713, se sídlem Ventúrská 3, 811 01 Bratislava, Slovenská republika – ze dne 2. 3. 2021 na zahájení správního řízení o přezkoumání úkonů zadavatele – Všeobecná zdravotní pojišťovna České republiky, IČO 41197518, se sídlem Orlická 2020/4, 130 00 Praha 3 – učiněných při zadávání veřejné zakázky „Smlouva o poskytování Integračních zdrojů v rámci IS VZP ČR“ v otevřeném řízení, jehož oznámení bylo odesláno k uveřejnění dne 20. 11. 2020 a uveřejněno ve Věstníku veřejných zakázek dne 23. 11. 2020 pod ev. č. Z2020-041457, ve znění oprav uveřejněných dne 28. 12. 2020, dne 11. 1. 2021 a dne 1. 2. 2021 a v Úředním věstníku Evropské unie uveřejněno dne 25. 11. 2020 pod ev. č. 2020/S 230-567140, ve znění dodatečných informací uveřejněných dne 28. 12. 2020, dne 12. 1. 2021 a dne 1. 2. 2021, se podle ustanovení § 265 písm. a) zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, zamítá, neboť nebyly zjištěny důvody pro uložení nápravného opatření.

Odůvodnění

I.               ZADÁVACÍ ŘÍZENÍ

1.             Odesláním oznámení o zahájení zadávacího řízení do Věstníku veřejných zakázek zadavatel – Všeobecná zdravotní pojišťovna České republiky, IČO 41197518, se sídlem Orlická 2020/4, 130 00 Praha 3 (dále jen „zadavatel“) zahájil jako veřejný zadavatel dle § 4 odst. 1 písm. e) zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „zákon“) dne 20. 11. 2020 otevřené řízení za účelem zadání veřejné zakázky „Smlouva o poskytování Integračních zdrojů v rámci IS VZP ČR“ zadávané v otevřeném řízení, jehož oznámení bylo uveřejněno ve Věstníku veřejných zakázek dne 23. 11. 2020 pod ev. č. Z2020-041457, ve znění oprav uveřejněných dne 28. 12. 2020, dne 11. 1. 2021 a dne 1. 2. 2021 a v Úředním věstníku Evropské unie uveřejněno dne 25. 11. 2020 pod ev. č. 2020/S 230-567140, ve znění dodatečných informací uveřejněných dne 28. 12. 2020, dne 12. 1. 2021 a dne 1. 2. 2021 (dále jen „veřejná zakázka“).

2.             Podle bodu II.1.4) Oznámení o zahájení zadávacího řízení je předmětem veřejné zakázky „poskytování služeb z níže uvedených oblastí.

1. Služby ve formě odborných konzultací v oblasti integrací, zpracování studií, procesů, analytické a zadávací dokumentace pro vývoj zahrnují:

- nastavení modelu a procesu spolupráce mezi VZP ČR a dodavatelem v prostředí Azure DevOps při poskytování služeb dle smlouvy,

- integrační služby,

- sestavy, reporty a dashboardy o provozu IPF a integračních služeb v centrálním úložišti logů,

- nové integrační komponenty pro IS VZP ČR,

- nové aplikační komponenty pro IS VZP ČR,

- podporu interního integračního týmu VZP ČR.

2. Vývojářské služby zahrnují vývoj a řešení incidentů z testování, nasazování a provozu, které nejsou důsledkem vadného plnění dodavatele:

- integračních služeb,

- statistických sestav, reportů a dashboardů o provozu integračních služeb v centrálním úložišti logů,

- integračních komponent,

- aplikačních komponent,

- integrace a konfigurace agentů a nástrojů Azure DevOps s Oracle.“.

3.             Zadavatel stanovil v bodu II.1.5) Oznámení o zahájení zadávacího řízení předpokládanou hodnotu veřejné zakázky ve výši 30 000 000 Kč bez DPH.

4.             Dne 5. 2. 2021 podal navrhovatel – SlovShore, s.r.o., IČO 35953713, se sídlem Ventúrská 3, 811 01 Bratislava, Slovenská republika, ve správním řízení zastoupena na základě plné moci ze dne 2. 3. 2021 JUDr. Janem Lukešem, Ph.D., advokátem, IČO 66253462, se sídlem Hybernská 1007/20, 110 00 Praha 1 (dále jen „navrhovatel“) – námitky proti zadávacím podmínkám veřejné zakázky. Námitky byly zadavateli doručeny dne 5. 2. 2021.

5.             Zadavatel rozhodnutím ze dne 22. 2. 2021, které bylo navrhovateli doručeno téhož dne, námitky navrhovatele odmítl. Vzhledem k tomu, že navrhovatel považoval uvedené rozhodnutí zadavatele za učiněné v rozporu se zákonem, podal k Úřadu pro ochranu hospodářské soutěže (dále jen „Úřad“) návrh na zahájení správního řízení o přezkoumání úkonů zadavatele (dále jen „návrh“). Návrh ze dne 2. 3. 2021 Úřad obdržel téhož dne. Stejnopis návrhu zadavatel obdržel rovněž dne 2. 3. 2021.

II.             OBSAH NÁVRHU

6.             Navrhovatel uvádí, že zadavatel neodeslal rozhodnutí o námitkách v zákonné lhůtě, neboť na podané námitky reagoval až dne 22. 2. 2021 a dále v návrhu napadá zákonnost zadávacích podmínek na veřejnou zakázku.

7.             Za nezákonnou považuje navrhovatel podmínku uvedenou v čl. 14.1 zadávací dokumentace, podle níž každá hodnocená nabídka musí povinně obsahovat prototyp aplikace „Cestovní příkazy“. Navrhovatel uvádí, že takový požadavek nelze stanovit v případě, pokud předmětný prototyp nemá být využit pro plnění veřejné zakázky. Podotýká, že se prototyp nevztahuje k předmětu veřejné zakázky, ani k žádné životní fázi veřejné zakázky, neboť tento prototyp má být dodavatelem vytvořen pouze a výlučně pro potřeby hodnocení dodavatelů. Navrhovatel v této souvislosti odkazuje na komentářovou literaturu, podle níž je souvislost s předmětem zadávané veřejné zakázky základní podmínkou pro využitelnost konkrétního kritéria pro účely hodnocení nabídek. Vysokou závažnost dané skutečnosti spatřuje navrhovatel v tom, že příslušné hodnotící kritérium A1 má stanovenou váhu 40 %, což bude mít podle jeho názoru zásadní význam při hodnocení nabídek.

8.             K názoru zadavatele, podle něhož požadavek na prototyp je důvodný proto, že součástí plnění budou procesy a postupy, jejichž znalost prokáže dodavatel na požadovaném prototypu aplikace „Cestovní příkazy“, navrhovatel uvádí, že uvedený předpoklad zadavatele není ničím podložen. Doplňuje, že procesy a postupy, které mají být v prototypu demonstrovány, nemají být součástí nabídky vlastního plnění veřejné zakázky. Tvrzení zadavatele, že prototyp má vztah k plnění veřejné zakázky proto, že na něm „dodavatelé prokáží kvalitativní hlediska spojená s předmětem veřejné zakázky“ proto považuje navrhovatel za liché a dodává, že závaznost „kvality prototypu“ pro budoucí plnění veřejné zakázky není v zadávací dokumentaci požadována. Navrhovatel dále odmítá tvrzení zadavatele, že prototyp představuje vzorek v návaznosti na § 37 odst. 2 a § 103 odst. 1 zákona. Navrhovatel k uvedenému zastává názor, že dosah ustanovení § 37 odst. 2 zákona nelze vnímat izolovaně, bez přihlédnutí k podmínkám podle § 37 odst. 1 zákona, a že předmětné ustanovení zákona neupravuje možnost či nemožnost zadavatele požadovat v rámci nabídky vytvoření nějakého produktu, který nemá být využit pro účely plnění veřejné zakázky. Stejně tak, pokud nemůže být předmětný prototyp kritériem kvality, nemůže být zadavatelem požadován ani dle ustanovení § 103 odst. 1 zákona.

9.             Podle názoru navrhovatele zadavatel porušil § 116 odst. 1, 3 a 5 zákona, z nichž vyplývá, že stanovená kritéria kvality musí být spojena s předmětem veřejné zakázky, a za související s předmětem veřejné zakázky se považují v případě, že se vztahují k jakékoliv fázi životního cyklu veřejné zakázky, což v daném případě není dle navrhovatele splněno.

10.         Navrhovatel dále brojí proti vymezení funkcionalit prototypu v čl. 14.1 zadávací dokumentace. Domnívá se, že zadavatel vymezil funkcionality prototypu velmi vágně, což nutně musí vést buď k vytvoření velmi odlišných prototypů aplikací, nebo k využití již existujících aplikací, které mají dodavatelé k dispozici. Podle navrhovatele tak dojde k situaci, že jednotlivé prototypy předložené dodavateli budou neporovnatelné, což znemožní transparentnost hodnocení nabídek, případně budou zvýhodněni dodavatelé, kteří již odpovídající aplikací disponují, mohou předložit prověřený a zákaznicky nasazovaný produkt a nemusí vynakládat náklady na vývoj prototypu. Navrhovatel současně upozorňuje, že zadavatel již obdobnou aplikací disponuje. Navrhovatel tak pojímá podezření, že se zadávacího řízení může rovněž zúčastnit dodavatel, který zadavateli dodal předmětnou aplikaci a bude tímto zvýhodněn. Navrhovatel odmítá úvahu zadavatele o tom, že pracnost vytvoření prototypu odpovídá 5 MD (Manday = člověkoden; pozn. Úřadu), neboť podle jeho názoru je reálná pracnost s vytvořením prototypu 100 MD, což odpovídá nákladům v řádu stovek tisíc korun českých. Navrhovatel podotýká, že dodavatele, který má již vytvořenou aplikaci pro zpracování agendy cestovních příkazů, nelze vnímat jako lépe kvalifikovaného pro plnění veřejné zakázky, ale pouze jako dodavatele, který má výhodu v rámci hodnocení nabídek. Navrhovatel je přesvědčen, že zadavatel výše uvedeným postupem porušil § 36 odst. 1 zákona a nedodržel zásadu zákazu diskriminace, neboť určitá část dodavatelů (kteří budou prototyp pro účely nabídky vytvářet) bude znevýhodněna oproti dodavatelům, kteří již příslušnou aplikací disponují.

11.         Dále navrhovatel namítá, že vymezení způsobu přidělování bodů k jednotlivým požadavkům na prototyp je stanoveno velmi obecně a není zřejmé, co bude v rámci každého jednotlivého požadavku preferováno či naopak bude posuzováno jako nedostatek. Navrhovatel v zadávací dokumentaci postrádá uvedení parametrů a hledisek, které budou v rámci jednotlivých požadavků na prototyp předmětem hodnocení a jak bude postupováno při posuzování míry jejich naplnění. Současně navrhovatel upozorňuje na obsah vysvětlení zadávací dokumentace č. 6, z něhož vyplývá, že členové odborné komise budou hodnotit na základě svých zkušeností a vnitřního pocitu. Podle jeho názoru bude tímto objektivnost posuzování míry naplnění jednotlivých požadavků na prototyp narušena, neboť způsob hodnocení prototypu je stanoven neurčitě, dovoluje široký prostor pro volnou subjektivní úvahu hodnotitele a současně nedovoluje následně ověřit míru naplnění požadavku vyjádřenou v hodnocení. S ohledem na uvedené navrhovatel dovozuje, že zadavatel porušil § 116 odst. 3 zákona a nedodržel zásadu transparentnosti, neboť kritérium kvality nevymezil tak, aby podle něj mohly být nabídky porovnatelné a naplnění kritérií ověřitelné.

12.         Navrhovatel rovněž nesouhlasí se stanovením způsobu hodnocení dílčího kritéria A2 – Certifikace členů realizačního týmu, když zadavatel stanovil celkem 13 certifikátů, za něž lze získat body. Podle navrhovatele je stanovený počet certifikátů v čl. 14.2 zadávací dokumentace nepřiměřený a nedovoluje provést řádné hodnocení nabídek účastníků zadávacího řízení tak, aby se rozsah certifikací mohl relevantně odrazit v hodnocení úrovně kvalifikace účastníka pro plnění veřejné zakázky. Má za to, že potenciální přínos pro posouzení úrovně kvalifikace dodavatele nestoupá s počtem dalších certifikátů lineárně. Uvedenou zadávací podmínkou zadavatel podle názoru navrhovatele diskriminuje tu část dodavatelů, kteří nedisponují počtem 13 certifikátů, avšak jinak mají stejně kvalifikované členy realizačního týmu. Současně se domnívá, že ve vztahu k uvedenému kritériu nelze provést transparentní hodnocení nabídek, neboť výsledky hodnocení nebudou odrážet skutečnou míru kvalifikace dodavatelů pro plnění dané veřejné zakázky.

13.         Dále navrhovatel namítá, že rozvržení počtu bodů pro jednotlivé certifikáty pro účely hodnocení není odůvodněné s tím, že není jasné, na základě čeho byl zadavatelem stanoven počet bodů k jednotlivým certifikátům. Bodové rozvržení pro jednotlivé certifikáty podle jeho názoru neodráží a nemůže odrážet míru kvalifikace dodavatele pro danou veřejnou zakázku. Podle jeho názoru zadavatel porušil § 36 odst. 1 zákona a zásadu zákazu diskriminace, neboť v návaznosti na uvedený způsob hodnocení budou zvýhodněni dodavatelé, kteří disponují nejlépe hodnocenými certifikáty, ačkoliv taková skutečnost neosvědčuje jejich vyšší kvalifikaci pro plnění veřejné zakázky.

14.         Navrhovatel směřuje své námitky také proti podmínkám kvalifikace uvedeným v čl. 6, bodu 1. a 2. přílohy č. 2 zadávací dokumentace, kde zadavatel požaduje prokázání zkušeností členů realizačního týmu s opensource technologiemi. Má za to, že kombinace požadovaných znalostí a certifikací pro splnění technické kvalifikace je nepřiměřeně rozsáhlá a neodpovídá složitosti a rozsahu předmětu veřejné zakázky. Navrhovateli zejména není zřejmé, z jakého důvodu zadavatel požaduje prokázat znalost technologie Alfresco a příslušné certifikace, neboť dle popisu současného stavu informačního systému tato technologie dosud nebyla použita. Požadavky na prokázání zkušeností s konkrétními opensource technologiemi bez možnosti nahrazení těchto konkrétních odkazů jinými opensource technologiemi v rámci prokazování technické kvalifikace považuje navrhovatel za diskriminační.

15.         Navrhovatel dále brojí proti požadavku zadavatele (v rámci podmínek kvalifikace) na certifikace vydávané přímo společností Elasticsearch s vyloučením možnosti doložit ekvivalentní jiný certifikát. Upřesňuje, že zadavatel bez relevantního důvodu odmítá uznat ekvivalentní certifikát Elastic Google Cloud Infrastructure: Scaling and Automation, což navrhovatel považuje za diskriminační.

16.         Navrhovatel má za to, že zadavatel stanovil výše uvedené podmínky technické kvalifikace jak jednotlivě, tak ve svém souhrnu, nepřiměřeně, čímž porušil § 73 odst. 6 zákona a nedodržel zásadu přiměřenosti a zásadu zákazu diskriminace.

17.         Navrhovatel se domáhá, aby Úřad zadávací řízení na předmětnou veřejnou zakázku zrušil.

III.           Průběh správního řízení

18.         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“), bylo zahájeno správní řízení o přezkoumání úkonů zadavatele dne 2. 3. 2021, kdy Úřad obdržel návrh navrhovatele.

19.         Účastníky správního řízení podle § 256 zákona jsou:

• zadavatel,
• navrhovatel.

20.         Zahájení správního řízení oznámil Úřad jeho účastníkům dopisem č. j. ÚOHS-08033/2021/533/HKu ze dne 4. 3. 2021.

21.         Usnesením č. j. ÚOHS-09215/2021/533/HKu ze dne 15. 3. 2021 určil Úřad zadavateli lhůtu k provedení úkonu – podání informace Úřadu o dalších úkonech, které zadavatel v šetřeném zadávacím řízení v průběhu správního řízení provede a zaslání příslušné dokumentace o zadávacím řízení pořízené v souvislosti s provedenými úkony.

22.         Usnesením č. j. ÚOHS-10650/2021/533/HKu ze dne 26. 3. 2021 určil Úřad účastníkům řízení lhůtu, ve které se mohli vyjádřit k podkladům rozhodnutí.

Vyjádření zadavatele k návrhu

23.         Zadavatel se k návrhu navrhovatele vyjádřil přípisem signovaným dne 11. 3. 2021, který byl Úřadu doručen téhož dne. Úvodem zadavatel reaguje na námitku navrhovatele ohledně pozdního odeslání rozhodnutí o námitkách, s názorem navrhovatele nesouhlasí a uvádí, že vychází z § 607 zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „NOZ“), podle něhož se poslední den lhůty posouvá na nejblíže následující pracovní den, což v daném případě s ohledem na skutečnost, že poslední den lhůty pro odeslání rozhodnutí o námitkách připadl na sobotu 20. 2. 2021, zcela odpovídá datu odeslání předmětného rozhodnutí (pondělí 22. 2. 2021).

24.         Zadavatel prohlašuje, že veškeré požadavky v rámci zadávacích podmínek na veřejnou zakázku stanovil pouze za účelem získat plnění odpovídající jeho objektivním potřebám, nikoli za účelem diskriminace některých dodavatelů či omezení hospodářské soutěže.

25.         K požadavku na prototyp aplikace „Cestovní příkazy“ zadavatel uvedl, že kritérium hodnocení A1 uvedené v bodě 14.1 zadávací dokumentace, resp. jednotlivé konkrétní požadavky na kvalitu, které bude zadavatel na prototypu hodnotit, odráží potřeby zadavatele a vztahují se k plnění, které bude dále poskytováno na základě smlouvy, a že v rámci uvedeného kritéria hodnocení posoudí znalost odborných a kvalitativních požadavků, které bude v průběhu plnění vyžadovat. Podle zadavatele má požadovaný prototyp souvislost s předmětem plnění veřejné zakázky, neboť dodavatelé na něm mají demonstrovat, že požadavky zadavatele na architekturu, technologie, procesy aj. (procesy a postupy) budou schopni plnit v rámci následného poskytování služeb, které tvoří předmět plnění veřejné zakázky.

26.         K vymezení funkcionalit požadovaného prototypu zadavatel uvádí, že prototyp aplikace „Cestovní příkazy“ vybral proto, že problematika cestovních příkazů a náhrad je implementována v každé firmě nebo společnosti a vychází z předepsané legislativy. Z toho zadavatel dovozuje, že tato problematika je všeobecně známá, a že všechna její řešení jsou si funkčně velmi podobná. Má za to, že požadavky na funkčnost formuloval tak, aby dodavatel mohl vytvořit co nejjednodušší prototyp s minimální pracností. Zadavatel předpokládá, že pro kvalifikovaného dodavatele bude snadné vytvořit takový prototyp aplikace, nikoli finální a k užívání připravenou aplikaci (což nepožaduje). Zadavatel trvá na tom, že mu není známa žádná již existující aplikace zpracovávající agendu cestovních příkazů, která by naplnila požadavky v rámci kritéria hodnocení A1 a dodává, že aplikace „Cestovní příkazy“ provozovaná zadavatelem nesplňuje drtivou většinu hodnotících kritérií (A01 – D05) dle bodu 14.1 zadávací dokumentace. K navrhovatelem doloženému počtu odpracovaných hodin na projektu „Demo aplikace Cestovní příkazy“ zadavatel uvádí, že se navrhovatel snažil využít veškerý dostupný čas na zdokonalování prototypu až na úroveň funkční demo aplikace, což zadavatel dle zadávacích podmínek nepožadoval. Zadavatel dodává, že pokud požadoval prototyp složený z integračních služeb, sestav, reportů, dashboardů, integračních komponent a jednotné grafické nadstavby k informačnímu systému zadavatele, pracnost takového prototypu by představovala cca 300 člověkodnů, a proto zvolil prototyp ve všech společnostech běžně užívané aplikace a prezentace řešení, na níž lze splnění kritérií hodnocení prokázat při výrazně nižší pracnosti.

27.         Ke stanovení způsobu hodnocení prototypu zadavatel uvádí, že postup přidělování jednotlivých bodů v rámci hodnotícího kritéria A1 stanovil jasně a transparentně, přičemž velká část požadavků bude posuzována způsobem „splněno/nesplněno“ nebo uvedenou hodnotou bodů při splnění požadavku. Dodává, že samotné odstupňování přidělených bodů je uvedeno v tabulce v bodě 14.1. zadávací dokumentace. Podle zadavatele není účelem hodnocení a přidělování bodů preferovat konkrétní řešení nebo představy členů odborné komise, ale posoudit, zda prototyp splnil definované hodnotící kritérium a dodavatel prokázal příslušnou odbornou kvalifikaci. Zadavatel podotýká, že u některých požadavků byl jejich obsah blíže vysvětlen v rámci vysvětlení zadávací dokumentace. Domnívá se, že jednotlivé požadavky jsou stanoveny v detailech potřebných pro vypracování vzájemně porovnatelných nabídek.

28.         Co se týče hodnotícího kritéria A2 – „Certifikace členů realizačního týmu“ zadavatel uvádí, že 13 certifikátů stanovil tak, aby měly svůj význam v předmětu plnění veřejné zakázky, a dodává, že „Nový informační systém“ („NIS“) se v průběhu realizace stále upřesňuje a doplňuje o nové požadavky a cíle. K jednotlivým certifikátům pak zadavatel předkládá bližší odůvodnění jejich výběru. Co se týče stanovení povinných minimálních požadavků na jednotlivé členy týmu v rámci technické kvalifikace, zadavatel uvádí, že se jedná o základní certifikaci, přičemž certifikáty, které budou hodnoceny v rámci hodnotícího kritéria, zvolil za účelem získat pro plnění co největší odborníky. Každý z certifikátů, který mohou dodavatelé v rámci hodnotícího kritéria předložit, má podle jeho názoru souvislost s prostředím zadavatele, přičemž zásadní význam vnímá u certifikátů hodnocených 5 či 6 body.

29.         Ve vztahu k podmínkám kvalifikace zadavatel uvádí, že požadavky na technické znalosti pro všechny požadované členy týmu jsou v souladu s technologiemi a nástroji, které zadavatel používá a jsou tak nutné k jeho dalšímu rozvoji a odpovídají složitosti a rozsahu předmětu veřejné zakázky. Stejně tak požadavky na certifikaci členů týmu odpovídají produktům a technologiím zadavatele a rovněž složitosti a rozsahu veřejné zakázky. Ani požadavky na délku praxe jednotlivých členů realizačního týmu zadavatel nepovažuje za neobvyklé či extenzivní. Ve vztahu k odůvodnění jednotlivých požadavků zadavatel odkazuje na obsah rozhodnutí o námitkách.

30.         Zadavatel neshledal, že by obsahem některé z částí certifikátu a kurzu Elastic Google Cloud Infrastructure:Scaling and Automation byla analýza a vizualizace dat v produktu ElasticSearch. Podle zadavatele slovo „Elastic“ v názvu certifikátu Elastic Google Cloud Infrastructure:Scaling and Automation neodkazuje na použití produktu ElasticSearch v Google cloudu, ale na přizpůsobitelnost infrastruktury Google cloudu na libovolnou zátěž a požadavky. Na základě uvedeného zadavatel shledává, že předmětný certifikát není ekvivalentní s požadovaným.

31.         Závěrem zadavatel vyjádřil přesvědčení, že při stanovení zadávacích podmínek na veřejnou zakázku postupoval v souladu se zákonem.

Vyjádření navrhovatele ze dne 1. 4. 2021

32.         Úvodem se navrhovatel obecně vyjadřuje k významu stanovení kritérií kvalifikace, přičemž zastává názor, že při nastavení kritérií kvalifikace často převažuje tendence zadavatelů nikoliv eliminovat nezpůsobilé dodavatele, ale vybrat pouze úzký segment z jinak způsobilých dodavatelů, což se podle jeho názoru stalo i v nyní prověřovaném případě.

33.         Navrhovatel nesouhlasí s argumentací zadavatele, podle níž je zákonná podmínka spojení kritéria kvality s jakoukoliv fází životního cyklu veřejné zakázky splněna u požadavku na vytvoření prototypu tím, že procesy a postupy pro vytvoření prototypu budou následně součástí plnění veřejné zakázky. Na základě skutečnosti, že prototyp nemá být využit pro plnění veřejné zakázky, dovozuje, že ani postupy či procesy týkající se jeho vytvoření součástí plnění veřejné zakázky nebudou. Podle jeho názoru zadavatel vágním vymezením funkčních požadavků na prototyp zvýšil pravděpodobnost, že někteří dodavatelé předloží zadavateli aplikaci cestovní příkazy, kterou mají již pro komerční účely vytvořenou a odladěnou, čímž budou zvýhodněni oproti dodavatelům, kteří museli prototyp vytvořit pro účely tohoto zadávacího řízení. Navrhovatel zdůrazňuje, že z obsahu zadávací dokumentace nevyplývá, jaké řešení bude zadavatel u většiny jednotlivých kritérií (požadavků na prototyp) preferovat, a že subjektivní hodnocení vede k narušení zásady transparentnosti.

34.         Ve vztahu k požadavkům na certifikaci členů realizačního týmu v rámci hodnotícího kritéria A2 navrhovatel uvádí, že zdůvodnění počtu bodů pro jednotlivé certifikáty je ze strany zadavatele zcela subjektivní a trvá na tom, že bodové rozvržení pro jednotlivé certifikáty neodráží míru kvalifikace pro předmětnou veřejnou zakázku.

35.         Navrhovatel zastává názor, že seznam produktů, jazyků a nástrojů nedokládá, že požadavky na prokázání znalostí a certifikací mají vztah k předmětu veřejné zakázky, a že rozsah požadovaných znalostí a certifikací je přiměřený povaze, rozsahu a předmětu veřejné zakázky. K certifikátu Elastic google Cloud Infrastructure: Scaling and Automation uvádí, že nedílnou součástí této expertní certifikace je také modul 4 Managed Services, který zahrnuje mimo jiné možnosti práce s Elasticsearch nad GCP (instalace, konfigurace, indexování, administrace, vizualizace dat apod.) obdobně, jako je tomu u expertní certifikace Elastic Certified Engineer resp. Elastic Certified Analyst, přičemž komplexní funkcionalitu Elasticserach nad GCP lze dokumentovat rovněž na základě technické prezentace společností Elastic a Google. Podle názoru navrhovatele zadavatel opomíjí, že navrhovatel odkázal na konkrétní zdroje informací, které dokládají, že analýza a vizualizace dat je součástí této certifikace.

Vyjádření zadavatele ze dne 7. 4. 2021

36.         Dne 7. 4. 2021 doručil zadavatel Úřadu vyjádření k podkladům pro vydání rozhodnutí, v němž uvedl, že plně odkazuje na svá předchozí vyjádření a dokumentaci zaslanou Úřadu.

Rozhodnutí Úřadu ze dne 14. 4. 2021

37.         Dne 14. 4. 2021 vydal Úřad rozhodnutí č. j. ÚOHS -12653/2021/500/AIv z téhož dne (dále jen „rozhodnutí ze dne 14. 4. 2021“), v němž ve výroku I. rozhodl, že zadavatel stanovil zadávací podmínky na veřejnou zakázku v rozporu se zásadou přiměřenosti stanovenou v § 6 odst. 1 zákona, ve spojení se zásadou transparentnosti vyjádřenou rovněž v § 6 odst. 1 zákona, když jako podmínku účasti v zadávacím řízení v bodu 11 ve spojení s bodem 14. 1 zadávací dokumentace stanovil nejasným způsobem požadavek na předložení prototypu aplikace „Cestovní příkazy“, která nebude součástí předmětu plnění veřejné zakázky, čímž kladl neúměrné nároky na dodavatele při přípravě nabídky.

38.         Ve výroku II. rozhodnutí ze dne 14. 4. 2021 Úřad rozhodl, že zadavatel stanovil zadávací podmínky na veřejnou zakázku v rozporu s § 115 odst. 1 písm. b) zákona, ve spojení s § 36 odst. 3 zákona a se zásadou transparentnosti stanovenou v § 6 odst. 1 zákona, když v bodu 14. 1 zadávací dokumentace nespecifikoval dostatečně konkrétně pravidla pro hodnocení nabídek ve vztahu k dílčímu kritériu hodnocení A1 - „Splnění požadavků na prototyp aplikace, prostředí aplikace, procesy, postupy vzájemné spolupráce“, jelikož zejména u požadavků hodnocených bodovou škálou neuvedl, jaké hodnoty (řešení/procesy) v rámci předloženého prototypu aplikace „Cestovní příkazy“ považuje za vhodnější a vyspělejší, a které tedy následně budou hodnoceny vyšším bodovým ohodnocením, čímž neposkytl dodavatelům zadávací podmínky v podrobnostech nezbytných pro účast v zadávacím řízení.

39.         Ve výroku III. rozhodnutí ze dne 14. 4. 2021 Úřad jako opatření k nápravě nezákonného postupu zadavatele zrušil zadávací řízení na veřejnou zakázku.

40.         Ve výroku IV. rozhodnutí ze dne 14. 4. 2021 Úřad uložil zadavateli zákaz uzavřít smlouvu na veřejnou zakázku.

41.         Ve výroku V. rozhodnutí ze dne 14. 4. 2021Úřad zadavateli stanovil povinnost uhradit náklady řízení ve výši 30 000 Kč se splatností dvou měsíců ode dne nabytí právní moci rozhodnutí.

IV.          Řízení o rozkladu

42.         Proti rozhodnutí ze dne 14. 4. 2021 podal zadavatel dne 27. 4. 2021 rozklad, o němž předseda Úřadu o rozkladu zadavatele rozhodl rozhodnutím č. j. ÚOHS-21830/2021/162/BVa ze dne 1. 7. 2021 (dále jen „druhostupňové rozhodnutí“), v jehož I. výroku zrušil rozhodnutí ze dne 14. 4. 2021 a věc vrátil Úřadu k novému projednání. Ve výroku II. druhostupňového rozhodnutí předseda Úřadu nařídil předběžné opatření, kterým zadavateli uložil zákaz uzavřít smlouvu na veřejnou zakázku.

43.         Své rozhodnutí předseda Úřadu odůvodnil tím, že rozhodnutí ze dne 14. 4. 2021 trpí nepřezkoumatelností pro nedostatek důvodů ve vztahu k závěrům, na nichž stojí výrok I. předmětného rozhodnutí, a že ve výroku II. je rozhodnutí ze dne 14. 4. 2021 nezákonné. Vzhledem ke skutečnosti, že jsou výroky III., IV. a V. napadeného rozhodnutí ze dne 14. 4. 2021 závislé na výrocích I. a II., bylo předmětné rozhodnutí zrušeno ve všech výrocích.

44.         Ve vztahu k výroku I. rozhodnutí ze dne 14. 4. 2021 předseda Úřadu uvedl, že Úřad zatížil své rozhodnutí nepřezkoumatelností tím, že s tvrzením navrhovatele obsaženým v návrhu (ohledně pracnosti vytvoření prototypu) a se zaslaným dokumentem naložil jako se zjištěným a prokázaným skutkovým stavem, aniž by bylo z rozhodnutí ze dne 14. 4. 2021 zřejmé, z jakého důvodu takto učinil. Podle názoru předsedy Úřadu se měl Úřad vypořádat s tím, zda dokument předložený navrhovatelem skutečně prokazuje jeho tvrzení a takovou úvahu srozumitelně vyložit. Dále předseda Úřadu shledal, že odůvodnění rozhodnutí ze dne 14. 4. 2021 neobsahuje žádné závěry, které by Úřad vztáhl k zásadě transparentnosti, což podle jeho názoru zatížilo předmětné rozhodnutí nepřezkoumatelností. Předseda Úřadu konstatoval, že závěr Úřadu o nepřiměřenosti požadavku zadavatele je nesprávný a nezákonný a upozornil, že přiměřenost požadavku na předložení vzorku je nutné zkoumat ve vztahu k charakteru nebo předmětu veřejné zakázky, a nikoliv ve vztahu k představám účastníků zadávacího řízení. Podle předsedy Úřadu měl Úřad nejprve jasným a srozumitelným způsobem vymezit, co je skutečně předmětem veřejné zakázky a teprve následně mohl poměřovat požadavek na předložení prototypu s takto jasně vymezeným předmětem veřejné zakázky.

45.         Ve vztahu k výroku II. rozhodnutí ze dne 14. 4. 2021 předseda Úřadu konstatoval, že ačkoliv lze obecně souhlasit s názorem Úřadu, že metoda přiřazení bodů popsaná zadavatelem je spíše obecnější a nemusí dodavatelům poskytovat naprosto jednoznačné informace o tom, za co dostanou kolik bodů, nelze i přesto takto zvolený způsob hodnocení považovat za rozporný s § 115 odst. 1 písm. b) zákona. Podle názoru předsedy Úřadu zadavatel tomuto zákonnému ustanovení dostál, „neboť v rámci jednotlivých kritérií i podkritérií hodnocení podrobně popsal, co bude hodnotit, a vymezil, jaké vlastnosti budou mít vliv na hodnocení. Současně pak popsal i metodu přidělení bodového hodnocení. Současně ovšem možný prvek nejistoty je zadávacími podmínkami natolik omezen, že hodnoticí komisi při hodnocení nabídek ponechává toliko aprobovaný prostor pro uvážení, aniž by vzbuzoval pochybnosti o možnosti svévole při hodnocení. Zadavatel tak vyvinul dostatečné úsilí k tomu, aby svá hodnotící kritéria objektivizoval. Tam, kde mohl, snažil se o co nejpodrobnější popis nastavených hodnotících kritérií. Tam, kde to z podstaty věci možné není, uvedl alespoň východiska, ze kterých bude při hodnocení vycházet. Je proto třeba uzavřít, že zadavatel nastavil hodnotící kritéria napadaná navrhovatelem v souladu se zákonem.“. Dále předseda Úřad konstatoval: „Pokud tedy Úřad ve vztahu k výroku II spatřuje pochybení zadavatele v tom, že nedostatečně přesně stanovil metodu hodnocení tak, aby dodavatelé přesně věděli, jak jejich nabídka bude hodnocena ve vztahu ke všem aspektům, pak takový závěr Úřadu nelze považovat za správný, neboť jde proti smyslu a účelu zadávání veřejných zakázek, kterým je to, aby zadavatel získal ekonomicky nejvýhodnější nabídku.“.

46.         Podle závěrů druhostupňového rozhodnutí je v dalším řízení Úřad vázán závaznými právními závěry vyslovenými v druhostupňovém rozhodnutí. V návaznosti na závěry předsedy Úřadu by se Úřad měl opětovně zabývat otázkou, zda postup zadavatele je či není v souladu se zákonem a v případě, že po opětovném posouzení znovu shledá v zadavatelově postupu porušení základních zásad přiměřenosti a transparentnosti, bude povinen své úvahy přezkoumatelným způsobem zdůvodnit. Úvahy Úřadu by pak měly vycházet ze základního vymezení otázky, zda zadavatel mohl požadovat předložení vzorku tak, jak jej požadoval v zadávací dokumentaci, přičemž však byl povinen svůj požadavek lépe definovat v souladu se zásadou transparentnosti, anebo nebyl oprávněn předložení vzorku požadovat, neboť je takový požadavek nepřiměřený, přičemž nelze primárně vyloučit to, aby zadavatel svým postupem porušil současně více zásad dle § 6 zákona. Předseda Úřadu zdůraznil, že pokud Úřad takové porušení shledá, je nutné, aby konkrétní prvky postupu zadavatele právně kvalifikoval ve vztahu k jednotlivým zásadám, jejichž porušení zadavateli vytýká. Úřad by se měl podle závěrů druhostupňového rozhodnutí rovněž zabývat tím, zda postup zadavatele odpovídá zákonným požadavkům stanoveným v § 36 odst. 1 zákona, tedy zda tento neklade bezdůvodné překážky hospodářské soutěži.

47.         V novém rozhodnutí ve věci je Úřad podle druhostupňového rozhodnutí povinen uvést přezkoumatelné úvahy o tom, co skutečně tvoří předmět veřejné zakázky a teprve po takovém posouzení může Úřad s tímto předmětem porovnat požadavek zadavatele na předložení vzorku, a to z hlediska jeho souvislosti a přiměřenosti. V případě, že by Úřad po novém přezkoumání věci dospěl k závěru, že požadavek zadavatele je v souladu se zákonem, bude nutné, aby se zabýval zbývajícím obsahem návrhu navrhovatele, který s odkazem na zásadu procesní ekonomie v napadeném rozhodnutí nevypořádal.

V.            Nové projednání věci Úřadem

48.         Oznámením č. j. 24245/2021/512/HKu ze dne 19. 7. 2021 Úřad seznámil účastníky správního řízení s tím, že se ve správním řízení vedeném pod sp. zn. ÚOHS-S0084/2021/VZ pokračuje.

49.         Usnesením č. j. ÚOHS-26238/2021/512/HČí ze dne 3. 8. 2021 určil Úřad zadavateli lhůtu k podání vyjádření k následujícím otázkám:

»1. Jaké konkrétní činnosti budou vykonávány vybraným dodavatelem při plnění veřejné zakázky? Uveďte podrobný popis.

2. Jak přesně souvisí činnosti vykonávané při tvorbě aplikace „Cestovní příkazy“, jejíž předložení zadavatel požadoval v zadávacích podmínkách, s předmětem plnění veřejné zakázky?

3. Jsou při tvorbě aplikace „Cestovní příkazy“ prováděny tytéž činnosti, které bude vybraný dodavatel realizovat v rámci plnění veřejné zakázky (pouze např. s tím rozdílem, že se bude jednat o jinou aplikaci, kterou bude sám tento vybraný dodavatel vytvářet)?

4. Bude předmětem veřejné zakázky vývoj a tvorba aplikací (obdobných jako aplikace „Cestovní příkazy“, jejíž předložení zadavatel stanovil jako zadávací podmínku) nebo mají služby vývoje v rámci plnění veřejné zakázky souviset jen s testováním aplikací vytvořených jinými subjekty? Upřesněte.«.

50.         Dopisem č. j. ÚOHS-31298/2021/512/HKu ze dne 14. 9. 2021 Úřad požádal společnost Google Czech Republic, s.r.o. o podání vyjádření k následujícím otázkám:

»1. Zahrnuje obsah kurzu pro získání certifikátu „Elastic Google Cloud Infrastructure: Scalling and Automation“ expertní používání produktu ElasticSearch pro analýzu a vizualizaci dat a vytváření dashboardů?

2. Lze považovat certifikát „Elastic Google Cloud Infrastructure: Scalling and Automation“ z pohledu rozsahu certifikovaných znalostí za rovnocenný k certifikátům „Elastic Certified Engineer“ nebo „Elastic Certified Analyst“? Vaši odpověď, prosím, odůvodněte.«.

Vyjádření navrhovatele ze dne 22. 7. 2021

51.         V reakci na oznámení o pokračování správního řízení navrhovatel doručil Úřadu své vyjádření ze dne 22. 7. 2021, v němž se vyjadřuje k obsahu druhostupňového rozhodnutí.

52.         Navrhovatel zastává názor, že stanovení požadavku na vytváření aplikace nevyužitelné pro plnění veřejné zakázky a samotným zadavatelem výslovně deklarované jako neurčené pro plnění veřejné zakázky je pro hodnocení nabídek nevhodné a nepřiměřené a zejména nepřípustné. Navrhovatel upozorňuje, že v žádné části zadávací dokumentace se nezmiňuje závaznost čehokoliv obsaženého v prototypu aplikace „Cestovní příkazy“ pro plnění veřejné zakázky a podotýká, že zadavatel závaznost nabídnutého prototypu, ani žádných v něm obsažených technologií, procesů, postupů či řešení, nestanovil, a tedy nemá žádný účinný nástroj, jak po vybraném dodavateli dodržení technologií, procesů, postupů či řešení užitých v prototypu vyžadovat. Příslušné prezentované postupy, procesy a technologie na přípravu prototypu tak podle názoru navrhovatele zůstávají pouze prostředkem hodnocení nabídek, bez vztahu k předmětu plnění veřejné zakázky. Navrhovatel dodává, že uvedená argumentace nebyla zohledněna ani v rozhodnutí ze dne 14. 4. 2021 ani v druhostupňovém rozhodnutí. Dále navrhovatel zastává názor, že požadovanou aplikaci cestovní příkazy nelze považovat za vzorek, neboť vzorkem může být pouze to, co bude pro plnění veřejné zakázky použito.

53.         Ve vztahu k argumentaci předsedy Úřadu ve druhostupňovém rozhodnutí, jež se týkala posuzování přiměřenosti požadavku na prototyp, navrhovatel zdůrazňuje, že při posuzování této otázky předseda Úřadu patrně přehlédl, že navrhovatel na rozdíl od zadavatele nevycházel z odhadu, ale ze skutečné pracnosti při vytvoření prototypu v rámci přípravy nabídky, kterou doložil přehledem skutečně odpracovaných časových jednotek jednotlivých rolí při přípravě prototypu. Navrhovatel proto nesouhlasí s kritikou předsedy Úřadu, podle níž Úřad s tvrzením navrhovatele a se zaslaným dokumentem naložil jako se zjištěným skutkovým stavem, neboť navrhovatel uvedl a doložil skutečnou časovou náročnost vytvoření prototypu. Dále navrhovatel zdůrazňuje, že zadavatel v zadávací dokumentaci nestanovil žádné efektivní limity, které by vedly k omezení pracnosti prototypu – např. podrobnější požadavky na prototyp, omezení rozsahu funkcionalit atd. Podle názoru navrhovatele by se podrobnější požadavky na prototyp projevily právě omezením pracnosti, neboť by vedly dodavatele k naplnění těchto požadavků, a nikoliv k volnému vytváření rozsáhlejší a propracovanější aplikace. Současně by se jednotlivé prototypy staly vzájemně porovnatelnými a využitelnými pro hodnocení.

54.         Co se týče předsedou Úřadu vytýkané nepřezkoumatelnosti ve vztahu k porušení zásad transparentnosti a přiměřenosti s tím, že v rozhodnutí ze dne 14. 4. 2021 chybí odůvodnění porušení zásady transparentnosti, navrhovatel je toho názoru, že v daném případě porušení obou zásad vzájemně souvisí. Podle názoru navrhovatele došlo ze strany zadavatele k porušení zásady transparentnosti nedostatečným vymezením požadavků na prototyp v zadávací dokumentaci, přičemž to zapříčinilo na jedné straně nejasnost toho, co konkrétně zadavatel požaduje vytvořit a na druhé straně nejasnost a nesrozumitelnost důvodů, proč zadavatel požaduje vytvořit takto zcela obecně popsaný prototyp. To současně přispělo k nepřiměřenosti požadavku na vytvoření prototypu, neboť nedostatečné vymezení požadavků na prototyp vedlo k nepřiměřenosti nezbytně z toho vyplývající pracnosti vytvoření prototypu.

55.         Navrhovatel dále uvádí, že i kdyby bylo možné přijmout závěr, že je zákonným požadavek na vytvoření prototypu, který nemá být využit pro plnění veřejné zakázky (což navrhovatel striktně odmítá), je podle navrhovatele nezbytné posoudit, zda zadavatelem tvrzené požadavky na architekturu, technologie, procesy, design a dokumentaci alespoň mohou být užity pro předmět plnění veřejné zakázky a případně, zda rozsah a způsob jejich užití pro plnění veřejné zakázky přiměřeně odpovídá náročnosti požadavku na přípravu prototypu aplikace. Navrhovatel upozorňuje, že zadávacími podmínkami není nijak zamezeno tomu, aby dodavatel vytvořil čistě jen pro hodnocení nabídek prototyp s určitou architekturou, technologiemi, procesy, designem a dokumentací, přičemž pro získání veřejné zakázky daným dodavatelem bude plnění veřejné zakázky založeno na zcela jiné architektuře, technologiích, procesech, designu i dokumentaci. Navrhovatel má za to, že prototyp slouží pouze pro účely hodnocení bez vztahu k budoucímu plnění veřejné zakázky, a nikoliv k posouzení kvality nabízeného plnění veřejné zakázky, a to i v případě, kdy by zadavatelem zmiňované souvislosti prototypu a předmětu veřejné zakázky existovaly.

56.         Ve vztahu k výroku II. rozhodnutí ze dne 14. 4. 2021 navrhovatel uvádí, že se nemůže ztotožnit se závěrem předsedy Úřadu, že zadávací podmínky stanoví hodnotící komisi pouze omezený aprobovaný prostor pro uvážení, který nevzbuzuje pochybnosti o možnosti svévole při hodnocení. Navrhovatel poznamenává, že ačkoliv zadavatel nějak odstupňoval míru naplnění jeho požadavků v tabulce k bodové škále, bez znalostí preferencí zadavatele nelze předem zjistit ani zpětně ověřit, na jakých preferencích zadavatele se toto odstupňování bude odehrávat.

Vyjádření zadavatele ze dne 10. 8. 2021

57.         V návaznosti na usnesení Úřadu č. j. ÚOHS-26238/2021/512/HČí ze dne 3. 8. 2021 zadavatel zodpověděl položené otázky následovně:

»Vyjádření Zadavatele k otázce č. 1:

Při plnění veřejné zakázky budou vybraným dodavatelem vykonávány činnosti uvedené v Příloze č. 1 Hlavního dokumentu zadávací dokumentace (…) kapitola 1.2 „Předmět plnění“. Toto plnění zahrnuje:

• Oblast vývoje:

o  vývoj a následné řešení provozních incidentů integračních služeb,

o  vývoj a následné řešení provozních incidentů aplikace statistických sestav, reportů a dashboardů o provozu integračních služeb v centrálním úložišti logů (Elastic),

o  vývoj a následné řešení provozních incidentů integračních komponent,

o  vývoj a následné řešení provozních incidentů aplikačních komponent,

o  integrace a konfigurace agentů a nástrojů Azure DevOps s Oracle a následné řešení případných provozních incidentů.

• Oblast odborných konzultací:

o  nastavení modelu a procesu spolupráce mezi VZP ČR a dodavatelem v prostředí Azure DevOps,

o  služby ve formě odborných konzultací v oblasti integrací, zpracování studií, procesů, analytické a zadávací dokumentace pro vývoj, na:

• integrační služby,
• sestavy, reporty a dashboardy o provozu IPF a integračních služeb v centrálním úložišti logů (Elastic). Tyto pohledy a měření nad logy v centrálním úložišti logů jsou dále nazývány jako Monitoring integračních služeb,
• nové integrační komponenty pro IS VZP ČR,
• nové aplikační komponenty pro IS VZP ČR,

o  podporu a spolupráci s interním integračním týmem VZP ČR.

(…)

Vyjádření Zadavatele k otázce č. 2:

Zadavatel požaduje, aby dodavatel prokázal svoje schopnosti, dovednosti, efektivitu a odbornou zdatnost v činnostech, které budou předmětem plnění veřejné zakázky. Toto má dodavatel prokázat vytvořením prototypu aplikační komponenty „Cestovní příkazy“ a prezentací řešení prototypu aplikační komponenty „Cestovní příkazy“. Při vlastní tvorbě prototypu bude dodavatel vykonávat činnosti:

• Pro oblast vývoje:

o  vývoj aplikační komponenty,

o  vývoj integračních služeb,

o  vývoj sestavy,

• Pro oblast odborných konzultací:

o  zpracování studie „přístup k vývoji aplikační komponenty Cestovní příkazy“,

o  přístup a ukázka vývojových postupů, dovedností a metodik dodavatele,

o  představení analytické dokumentace a zadávací dokumentace aplikační komponenty „Cestovní příkazy“.

(…)

Vyjádření Zadavatele k otázce č. 3:

při tvorbě prototypu aplikace „Cestovní příkazy“, jsou prováděny tytéž činnosti, které bude dodavatel realizovat v rámci plnění veřejné zakázky. Činnosti požadované pro plnění veřejné zakázky Zadavatel vyjmenoval v odpovědi na otázku č. 1 a činnosti pro vytvoření prototypu v odpovědi č. 2. Předmětem plnění veřejné zakázky budou jiné aplikace nebo aplikačních komponenty a prototyp aplikace „Cestovní příkazy“ nebude dokončen ve finální aplikaci. Při tvorbě prototypu aplikace „Cestovní příkazy“ nejsou po dodavateli požadovány žádné další činnosti, které by nebyly součástí plnění veřejné zakázky.

(…)

Vyjádření Zadavatele k otázce č. 4:

Předmětem veřejné zakázky bude vývoj a tvorba aplikací z oblasti integrací, které nejsou běžně dostupné na trhu a zadavatel bude vyžadovat jejich vytvoření na „míru“ svým potřebám. V porovnání s aplikací na „Cestovní příkazy“ se jedná o náročnější a rozsáhlejší aplikace. Jako odborné konzultace mohou být předmětem veřejné zakázky i práce na vytvoření podkladů (studie) a zadávací dokumentace pro jiné subjekty, jejichž realizaci by Zadavatel soutěžil v dalších veřejných zakázkách. Předmětem veřejné zakázky není testování a podpora aplikací vytvořených jinými subjekty (…).«.

Vyjádření společnosti Google Ireland Ltd. ze dne 4. 10. 2021

58.         V návaznosti na žádost Úřadu č. j. ÚOHS-31298/2021/512/HKu ze dne 14. 9. 2021 (viz bod 50. odůvodnění tohoto rozhodnutí) obdržel Úřad vyjádření společnosti Google Ireland Ltd., se sídlem Gordon House, Barrow Street, Dublin 4, Irsko (dále jen „Google Ireland Ltd.“), které byla předmětná žádost Úřadu předána společností Google Czech Republic, s.r.o., jež zodpověděla položené otázky následovně:

Na otázku „Zahrnuje obsah kurzu pro získání certifikátu „Elastic Google Cloud Infrastructure: Scalling and Automation“ expertní používání produktu ElasticSearch pro analýzu a vizualizaci dat a vytváření dashboardů?“ Úřad obdržel následující odpověď:

»Google poznamenává, že slovo „Elastic“ v názvu kurzu „Elastic Google Cloud Infrastructure: Scaling and Automation“ (česky: „Elastická cloudová infrastruktura Google: škálování a automatizace“) neodkazuje na produkty ElasticSearch B.V. Odkazuje pouze na elastickou (flexibilní, přizpůsobitelnou) povahu dané cloudové infrastruktury. Modul „Managed Services“ (česky: „Spravované služby“) kurzu „Elastic Google Cloud Infrastructure: Scaling and Automation“ pokrývá služby BigQuery, Cloud Dataflow, Cloud Dataprep a Cloud Dataproc. V materiálu kurzu není žádný odkaz na ElasticSearch. Společnost Google ani žádné přidružené společnosti neodpovídají za produkt ElasticSearch. Google tak nemůže posoudit užitečnost kurzu Google ve vztahu k používání ElasticSearch. Daný kurz Google však nemá za cíl poskytnout žádné specializované znalosti o produktech ElasticSearch. «.

Na otázku »Lze považovat certifikát „Elastic Google Cloud Infrastructure: Scalling and Automation“ z pohledu rozsahu certifikovaných znalostí za rovnocenný k certifikátům „Elastic Certified Engineer“ nebo „Elastic Certified Analyst“? Vaši odpověď, prosím, odůvodněte.« Úřad obdržel následující odpověď:

»Kurz „Elastic Google Cloud Infrastructure: Scaling and Automation“ zajišťuje online školicí partner společnosti Google Coursera. Coursera vydává certifikát Coursera Course, osvědčení udělené těm, kteří absolvují kurz na své platformě.1 Osnovu kurzu si můžete prohlédnout na této adrese: https://www.coursera.org/learn/gcp-infrastructure-scaling-automation#syllabus. Certifikáty „Elastic Certified Engineer“ a „Elastic Certified Analyst“ nejsou nabízeny společností Google a nevztahují se ke Google Cloud. Kurz „Elastic Google Cloud Infrastructure: Scaling and Automation“, ani jiné kurzy Google Cloud, dle názoru společnosti Google Ireland, nejsou srovnatelné s obsahem certifikátů „Elastic Certified Engineer“ a „Elastic Certified Analyst“, neboť nejsou zaměřeny na produkty ElasticSearch. Společnost ElasticSearch B.V. se zaměřuje na komerční vyhledávání, které představuje zcela odlišný obor podnikání, než jakému se věnují Google Cloud, resp. Google Ireland.«.

Vyjádření zadavatele k podkladům rozhodnutí

59.         Zadavatel ve svém vyjádření ze dne 20. 10. 2021 reaguje v prvé řadě na odpověď společnosti Google Ireland Ltd. ze dne 4. 10. 2021, k níž uvádí, že uvedená společnost zcela potvrdila tvrzení zadavatele, že certifikáty, které je možné získat v rámci kurzu „Elastic Google Cloud Infrestructure: Scalling and Automation“ nejsou obsahově srovnatelné s certifikáty „Elastic Certified Engineer“ a „Elastic Certified Analyst“, neboť výše uvedený kurz není zaměřen na produkty ElasticSearch. Zadavatel dodává, že jeho cílem nikdy nebylo jakkoli diskriminovat potencionální dodavatele, ale vědom si svých potřeb, hledá pro poptávané plnění zkušeného a dostatečně kvalifikovaného dodavatele se znalostmi potřebnými pro rozvoj informačního systému VZP ČR.

60.         Zadavatel nesouhlasí s tvrzením navrhovatele, podle něhož dodavatel není povinen při plnění veřejné zakázky využít postupů, technologií či procesů užitých pro vyhotovení prototypu aplikace cestovní příkazy, neboť ačkoliv nebude samotná aplikace zadavatelem dále rozvíjena, technologie, procesy či postupy, kterých dodavatelé při tvorbě předmětné aplikace využijí, budou nejen předmětem hodnocení v rámci hodnotícího kritéria A1, ale současně právě technologie, postupy a procesy, jejichž znalost dodavatelé při tvorbě prototypu a během prezentace prokáží, budou následně využity v průběhu plnění. Zadavatel podotýká, že právě tyto technologie, postupy a procesy lze uplatnit i při jiných službách souvisejících s vývojem, nejen při tvorbě aplikací pro agendu cestovních příkazů. Zadavatel upřesňuje, že vzájemná provázanost požadované aplikace cestovní příkazy a poptávaného plnění je postavena na obdobnosti prováděných postupů a procesů při vytváření aplikací, integračních služeb, integračních komponent a informačních systémů.

61.         Zadavatel rovněž nesouhlasí s tvrzením navrhovatele, podle něhož zadavatel nezamezil tomu, aby vybraný dodavatel založil plnění na zcela jiné architektuře, technologiích, procesech, postupech apod. K tomuto zadavatel uvádí, že smlouva na veřejnou zakázku bude uzavřena na 48 měsíců s tím, že předmět plnění nelze předem zcela konkrétně vymezit a specifikovat jednotlivá plnění, která bude vybraný dodavatel poskytovat. Jeho služby budou totiž poskytovány na základě jednotlivých objednávek, kdy detailní požadavky budou specifikovány zadavatelem po konzultaci s vybraným dodavatelem, a to včetně způsobu poskytování služeb, výstupů služeb, termínů předání výstupu služby a akceptačních kritérií. Současně se vybraný dodavatel zaváže poskytovat služby v požadované kvalitě. Zadavatel dále uvádí, že nastavení modelu a procesů spolupráce mezi zadavatelem a vybraným dodavatelem je vyhrazena celá jedna část v oblasti odborných konzultací. Plnění vybraného dodavatele tedy bude probíhat vždy po konzultaci se zadavatelem a na základě jeho požadavků. Za logické tedy zadavatel považuje skutečnost, že poté, co si zadavatel vybere pro plnění veřejné zakázky dodavatele, který k tvorbě prototypu aplikace cestovní příkazy využil technologie a řešení, která zadavatel považuje za nejvhodnější pro účel veřejné zakázky, bude následně od vybraného dodavatele vyžadovat právě tyto technologie a řešení.

62.         Dále zadavatel uvádí, že postup přidělování bodů v rámci hodnotícího kritéria A1 stanovil zcela jasně a transparentně, a že k provedení hodnocení ustanovil v době zahájení zadávacího řízení komisi složenou ze zaměstnanců Úseku informačních a komunikačních technologií VZP ČR. Podle názoru zadavatele bude tedy hodnocení provedeno zkušenými specialisty z oblasti informačních technologií.

63.         Zadavatel závěrem uvádí, že veškeré požadavky stanovené v rámci zadávací dokumentace uvedl pouze za účelem získat pro poptávané plnění kvalifikovaného dodavatele, který pro zadavatele zajistí kvalitní plnění, jež bude co nejvhodněji naplňovat potřeby zadavatele. Zadavatel žádá, aby Úřad rozhodl o zamítnutí návrhu.

Vyjádření navrhovatele k podkladům rozhodnutí

64.         Navrhovatel se ve svém vyjádření ze dne 20. 10. 2021 nejprve vyjadřuje k obsahu vyjádření zadavatele ze dne 10. 8. 2021. Podle názoru navrhovatele je z odpovědi zadavatele na dotaz č. 1 zřejmé, že předmětem plnění veřejné zakázky není jakékoliv plnění, které by se blížilo aplikaci cestovní příkazy. K odpovědím zadavatele na dotazy č. 2 a 3 navrhovatel uvedl, že předmětné odpovědi se věnují výlučně činnostem, nikoliv výstupu jako takovému, což navrhovatel nepovažuje za dostatečně relevantní pohled. Podle názoru navrhovatele se jedná o činnosti obecného charakteru, tj. o činnosti, které se vyskytují z podstaty věci na každé softwarové aplikaci a z výstupu, který je zadavateli předložen (prototyp aplikace cestovní příkazy) nelze podle názoru navrhovatele nic usuzovat pro výstupy, které budou předmětem plnění veřejné zakázky, neboť funkcionality prototypu jsou zcela odlišné od předmětu plnění veřejné zakázky.

65.         Navrhovatel nesouhlasí s tvrzením zadavatele, podle něhož »Při tvorbě prototypu aplikace „Cestovní příkazy“ nejsou po dodavateli požadovány žádné další činnosti, které by nebyly součástí plnění veřejné zakázky.«. Navrhovatel k tomuto uvádí, že pokud by všechny činnosti při tvorbě aplikace cestovní příkazy byly rovněž součástí plnění předmětu veřejné zakázky, pak by nutně muselo být předmětem veřejné zakázky něco obdobného jako je aplikace cestovní příkazy. Podle názoru navrhovatele je podstatné srovnání, do jaké míry se předmět plnění veřejné zakázky promítá do tvorby prototypu aplikace cestovní příkazy. Navrhovatel dodává, že prototyp aplikace cestovní příkazy nezahrnuje řešení provozních incidentů nebo integrace a konfigurace agentů a nástrojů Azure DevOps s Oracle či odborné konzultace. Navrhovatel podotýká, že jediným pojítkem je zde vývoj, ovšem odlišného výstupu, neboť aplikace cestovní příkazy nezahrnuje jakoukoliv funkcionalitu, která by mohla být předpokládanou funkcionalitou v rámci plnění předmětu veřejné zakázky. Navrhovatel má za to, že jediné, co je zadavatel schopen z prototypu aplikace cestovní příkazy relevantního pro předmět plnění veřejné zakázky zjistit, je skutečnost, zda je dodavatel schopen vývoje software. Dále je navrhovatel toho názoru, že požadované funkcionality prototypu aplikace cestovní příkazy byly v zadávací dokumentaci vymezeny velmi vágně, z čehož navrhovatel dovozuje, že každý z dodavatelů vyvinul tento prototyp jinak.

66.         K obsahu vyjádření společnosti Google Ireland Ltd. navrhovatel uvádí, že odpověď této společnosti nepostačuje k závěru, že certifikát „Elastic Google Cloud Infrastructure: Scaling and Automation“ není srovnatelný s certifikáty „Elastic Certified Engineer“ a „Elastic Certified Analyst“ a domnívá se, že odpověď na danou otázku by měla poskytnout rovněž společnost ElasticSearch B.V. Navrhovatel dále s ohledem na skutečnost, že platforma ElasticSearch je integrována do Google Cloud Platform, dovozuje, že expert na Google Cloud Infrastructure, ovládající po technologické stránce práci s nativním GCP by měl být schopen pracovat rovněž s částí ElasticSearch. Podle názoru navrhovatele je třeba, aby společnosti Google Ireland Ltd. a ElasticSearch B.V. odpověděly na doplňující dotaz, zda certifikovaný expert „Elastic Google Cloud Infrestructure: Scaling and Automation“ je či není schopen pracovat s platformou Elastic Search na GCP.

VI.          ZÁVĚRY ÚŘADU

67.         Úř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 dokumentace o zadávacím řízení, návrhu navrhovatele, stanovisek zadavatele a navrhovatele předložených ve správním řízení a na základě vlastního zjištění rozhodl o zamítnutí návrhu navrhovatele. Ke svému rozhodnutí Úřad uvádí následující rozhodné skutečnosti.

K požadavku zadavatele na předložení prototypu aplikace „Cestovní příkazy“

Relevantní ustanovení zákona

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

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

70.         Podle § 36 odst. 3 zákona zadávací podmínky zadavatel stanoví a poskytne dodavatelům v podrobnostech nezbytných pro účast dodavatele v zadávacím řízení.

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

71.         V bodu 6.2 „Předmět veřejné zakázky“ zadávací dokumentace je uvedeno:

„Předmětem veřejné zakázky je poskytování služeb z níže uvedených oblastí:

1. Oblast odborných konzultací

Služby ve formě odborných konzultací v oblasti integrací, zpracování studií, procesů, analytické a zadávací dokumentace pro vývoj, které zahrnují:

a.    nastavení modelu a procesu spolupráce mezi VZP ČR a dodavatelem v prostředí Azure DevOps při poskytování služeb dle smlouvy,

b.    integrační služby,

c.    sestavy, reporty a dashboardy o provozu IPF a integračních služeb v centrálním úložišti logů (Elastic),

d.    nové integrační komponenty pro IS VZP ČR,

e.    nové aplikační komponenty pro IS VZP ČR,

f.     podporu interního integračního týmu VZP ČR,

a to v předpokládaném celkovém rozsahu 1520 člověkodnů za období 48 měsíců.

2. Oblast vývoje

Vývojářské služby zahrnují vývoj a řešení incidentů zejména z testování, nasazování a provozu, které nejsou důsledkem vadného plnění dodavatele:

a.    integračních služeb,

b.    statistických sestav, reportů, a dashboardů o provozu integračních služeb v centrálním úložišti logů (Elastic),

c.    integračních komponent,

d.    aplikačních komponent,

e.    integrace a konfigurace agentů a nástrojů Azure DevOps s Oracle,

a to v předpokládaném celkovém rozsahu 1750 člověkodnů za období 48 měsíců. (…).“.

72.         V čl. II. „Účel a předmět Smlouvy“ přílohy č. 1 zadávací dokumentace (Obchodní podmínky) je uvedeno:

„Účelem této Smlouvy je v návaznosti na proces přípravy a realizace programu Nového Informačního Systému – „NIS“ ve VZP ČR (dále též jen „NIS“) a s tím souvisejícími požadavky na přípravu jednotlivých realizačních projektů, které mají naplnit potřeby a cíle VZP ČR, zajistit a garantovat personální kapacitu pro poskytování odborných konzultačních a vývojových služeb specialistů v rámci rolí specifikovaných v Příloze č. 3 této Smlouvy (…) v oblasti integračních úloh a projektů pro postupnou konsolidaci aplikační podpory a integraci procesů v IS VZP ČR a při implementaci řešení integračních komponent a vazeb zejména mezi nově budovanými aplikačními komponentami a stávajícími aplikačními komponentami s cílem zajištění efektivní a účelné přípravy a realizace programu NIS ve VZP ČR. (…) Objednatel si vyhrazuje právo objednávat předmětné služby dle svých potřeb. Tato Smlouva nezavazuje Objednatele k objednání plnění v jakémkoli minimálním množství a rozsahu (co do druhu plnění nebo jeho finančního objemu).“.

73.         V čl. III. „Předmět plnění“ přílohy č. 1 zadávací dokumentace (Obchodní podmínky) je uvedeno:

»Předmětem plnění je poskytování odborných konzultačních a vývojových služeb pro proces přípravy a realizace programu NIS ve VZP ČR uvedených v odstavci 2. tohoto článku (…).

2. Služby budou poskytovány v průběhu celé doby účinnosti této Smlouvy na základě jednotlivých objednávek, uzavíraných dle aktuálních potřeb a požadavků VZP ČR (…).

Služby v oblasti odborných konzultací budou poskytovány po celou dobu účinnosti Smlouvy na základě jednotlivých Objednávek uzavíraných dle aktuálních potřeb a požadavků VZP ČR, a to v předpokládaném celkovém rozsahu 1520 člověkodnů (dále též jen „MD“) na dobu 48 měsíců.

(…)

Služby v oblasti vývojových služeb budou poskytovány po celou dobu účinnosti Smlouvy na základě jednotlivých Objednávek uzavíraných dle aktuálních potřeb a požadavků VZP ČR, a to v předpokládaném celkovém rozsahu 1750 člověkodnů (MD) na dobu 48 měsíců.

(…)

3.2. Poskytování Služeb na základě každé jednotlivé Objednávky bude zpravidla rozděleno do čtrnáctidenních dílčích období (sprintů). Detailní požadavky na plnění budou specifikovány Objednatelem po konzultaci s Poskytovatelem pro každé dílčí období seznamem požadavků v Azure DevOps (dále jen „Požadavky“ / „Požadavek“) včetně způsobu poskytování Služeb, výstupů Služeb, termínů předání výstupu Služby a akceptačních kritérií.«.

74.         V bodu 1 „Obecná charakteristika“ přílohy č. 1 obchodních podmínek – technická kvalifikace je uvedeno: „Všeobecná zdravotní pojišťovna České republiky provádí inovaci svého informačního systému. Součástí této aktivity je postupná konsolidace aplikační podpory, integrace procesů správy zdravotního pojištění a také digitalizace interních procesů. VZP ČR plánuje během několika let postupně nahradit nebo transformovat významné části (komponenty) stávajícího informačního systému sadou nových nebo modernizovaných aplikačních komponent integrovaných do ucelených služeb na SOA principech. Významnou součástí inovace integrační platformy jsou nový monitoring, nové integrační komponenty, nové integrační vazby a nové integrační služby. Za tímto účelem poptává VZP ČR specializované služby v oblasti integračních úloh a projektů, monitoringu integračních služeb, integrace a konfigurace agentů a nástrojů Azure DevOps s Oracle.“.

75.         V bodu 11. „PŘEDLOŽENÍ VZORKŮ K TESTOVÁNÍ“ zadávací dokumentace zadavatel stanovil:

»Zadavatel bude v rámci hodnocení nabídek provádět hodnocení prototypu aplikace „Cestovní příkazy“ (viz bod 14.1 tohoto HDZD).

Zadavatel za účelem provedení hodnocení požaduje předložení prototypu aplikace „Cestovní příkazy“ (…) Prototyp aplikace „Cestovní příkazy“ bude předmětem hodnocení dle hodnotících kritérií, pročež jej nelze následně doplnit postupem dle § 46 odst. 1 ZZVZ. V případě nepředložení prototypu ve lhůtě pro podání nabídek, bude dodavatel vyloučen ze zadávacího řízení dle § 48 odst. 2 písm. a) ZZVZ (…).«.

76.         V bodu 14. „ZPŮSOB HODNOCENÍ NABÍDEK“ zadávací dokumentace[1] zadavatel stanovil následující podmínky:

„Zadavatel bude ekonomickou výhodnost nabídek hodnotit podle níže uvedených kritérií hodnocení (…):

Označení kritéria	Název kritéria hodnocení	Váha kritéria
A1	Splnění požadavků na prototyp aplikace, prostředí aplikace, procesy, postupy vzájemné spolupráce	40 %
A2	Certifikace členů realizačního týmu	30 %
B	Celková nabídková cena (v Kč bez DPH)	30 %

(…)

14.1 Kritérium hodnocení A1 – Prototyp aplikace Cestovní příkazy a prezentace řešení

V rámci tohoto kritéria hodnocení bude odborná komise hodnotit kvalitativní stránku prototypu aplikace „Cestovní příkazy“ jakož i procesy, postupy a řešení prezentované účastníkem zadávacího řízení. (…)

Za tímto účelem musí každá hodnocená nabídka povinně obsahovat prototyp aplikace „Cestovní příkazy“, který umožní:

• zadat žádanku na služební cestu,
• schválit žádanku služební cesty,
• zadat podrobnosti a náklady uskutečněné služební cesty,
• vypracovat vyúčtování služební cesty,
• schválit vyúčtování služební cesty,
• integrovat aplikaci „Cestovní příkazy“ na HR a účetní systém.

Dále musí hodnocená nabídka povinně obsahovat prezentaci nebo dokument, který bude jasnou a výstižnou ukázkou dokumentace o procesech, postupech, designu, analytické dokumentace, programátorské dokumentace, přístupu k testování, akceptaci a nasazování do jednotlivých typů prostředí, týkající se vývoje prototypu aplikace „Cestovní příkazy. Dokumentace musí obsahovat minimálně informace o:

• DevOps procesech a postupech,
• podpoře agilního vývoje,
• existenci a možnostech použití Development Platformy,
• existenci konceptu MVP (Minimum Viable Product),
• rozsahu a způsobu využití kontejnerů a cloudových služeb,
• využití Open-source řešení.

(…)

Nejlépe bude hodnocena nabídka toho účastníka zadávacího řízení, jehož prototyp aplikace „Cestovní příkazy“, prezentace a dokumentace účastníka nejlépe naplní následující požadavky zadavatele:

ID	Požadavek	Body
A	Architektura a procesy
A01	Podpora agilního vývoje (podpora agility ve vývojovém procesu)	0-5
A02	Kompletnost a vyspělost DevOps procesů	0-5
A03	Existence konceptu MVP (Minimum viable product) a jeho aplikace na prototyp aplikace „Cestovní příkazy“	0-5
A04	Existence a možnosti použité podpůrné Development Platformy	0/5
A05	Rozsah a způsob využití kontejnerů a cloudových služeb	0-5
A06	Využití Open-source řešení	0/5
F	Formuláře prototypované aplikace
F01	Interakce s uživateli prostřednictvím webového rozhraní a webových formulářů	0-5
F02	Podpora publikace el. formulářů v podobě samostatných aplikací/serverů, které umožňují aktivní práci s formulářem v aplikaci třetí strany. Např. možnost vyplnění jednotného formuláře na portálovém řešení i uvnitř BPM aplikace	0/5
F03	Řízení životního cyklu publikovaných business procesů a formulářů (evidence, publikace, verzování, změny, revokace, zálohování)	0-5
F04	Integrované uživatelské účty s možností synchronizace na běžné adresářové služby	0/3
F05	Autorizace (podpis, pečeť) publikovaných formulářů vydavatelem	0/1
F06	Integrovaný návrh formulářů s workflow agendy, tj. integrované grafické vývojové prostředí pro návrh datové struktury, její vizualizace a workflow	0-5
F07	Možnost návrhu jednotné grafické podoby aplikací a formulářů	0-5
F08	Aplikace a formuláře jsou interpretovány responzivně v HTML5 s podporou klíčových prohlížečů na platformách Windows, macOS, Android, iOS/iPadOS	0/3
F09	Zajištění podpory standardizovaných formátů pro práci s daty a aplikace autorizace prostřednictvím el. podpisu: -    vizualizace v podobě HTML5 (W3C) -    otevřený formát XML pro data (W3C) -    Elektronický podpis, pečeť a časové razítko dle norem ETSI (Nařízení elDAS)	0/3
F10	Možnost aplikace el. podpisu pro autorizaci procesních kroků včetně zabezpečení vyplněných dat uživatele	0/3
F11	Odeslání dat v rámci online komunikace zvolenou cestou (HTTP/HTTPS, SOAP/REST API, ISDS, E-mail)	0-3
F12	Odeslání vyplněného formuláře a XML dat s přílohami do datové schránky nebo na e-mail	0/1
F13	Převod vyplněných formulářů do vizualizace PDF formátu s aplikací el. podpisu podle standardů ETSI (Nařízení eIDAS) na všech klíčových platformách (Windows, macOS, Android, iOS/iPadOS)	0/1
F14	Podpora dynamických číselníků a skriptů pro zjednodušení předvyplnění nebo manuální výběru	0/3
F15	Ukládání dat z formuláře ve standardním formátu (např. XML), načtení dříve uložených a rozpracovaných dat do formuláře	0/1
F16	Datové kontroly a vlastnosti aplikací v min. rozsahu: -          povinná hodnota -          kontrola vstupních znaků (např. pouze číslice, datum apod.) -          automatické výpočty u definovaných formulářů -          souvislost mezi jednotlivými hodnotami -          logické kontroly pro zjednodušení procesu vyplňování -          definice vlastních ““hodnotových““ typů (kontrola syntaxe IČ, bankovního účtu, e-mailu apod.)“	0-3
F17	Automatické výpočty v rámci formuláře	0/1
P	Procesní zpracování
P01	Zajištění sledování koloběhu daného procesu od počátku až do konce, stavy procesů a jejich archivované výsledky je možné dohledat i zpětně pro případnou kontrolu.	0/3
P02	Integrovaný kvalifikovaný podpis (standard ETSI, Nařízení eIDAS) v rámci schvalovacího workflow agend	0/1
P03	Integrované spouštěcí události workflow (příjem formulářových dat, volání vystavené integrační služby, přijatý email ve sledovaných E-mailových účtech, přijatá datová zpráva, periodické události apod.)	0-3
P05	Základní prvky workflow: Definice cesty a úrovní schvalování v rámci workflow (skupiny/role, zodpovědnosti), definice akcí s vyplněním formuláře, definice akcí s rozhodovací bránou, definice notifikačních e-mailů, definice volání integrační služby	0-3
P05	Podpora paralelních procesních kroků v rámci workflow	0-3
P06	Informace o stavech procesů E-mailovou notifikací včetně odkazu na řešený proces	0/1
P07	Uživatelské rozhraní aplikace je implementováno responzivně v HTML5 s podporou klíčových prohlížečů na platformách Windows, macOS, Android, iOS/iPadOS	0/1
P08	Správa vlastních uživatelských účtů, práv uživatelů, skupin uživatelů a rolí v návaznosti na organizační strukturu a mapování na entity externí adresářové služby (LDAP, Active Directory)	0/3
P09	V době nepřítomnosti uživatelů bude umožněno pokračování procesu v rámci volitelné zastupitelnosti	0/1
P10	Integrované grafické vývojové prostředí pro návrh datové struktury, její vizualizace a workflow je dostupné pro libovolného uživatele podle oprávnění uděleným administrátorem	0/3
P11	Zajištění neporušenosti obsahu a věrohodnosti původu uzavřených agend, možnost vizualizace procesní historie provozované agendy	0/1
P12	SingleSignOn. Uveďte do poznámky, jaké implementace SSO platforma podporuje	0/1
P13	Dvoufázové ověření	0/1
P14	Business Continuity Management	0/1
P15	Podporuje platforma modelování integrací na REST a SOAP webové služby, nebo je třeba vyvinout konektor/adaptér (v případě, že není k dispozici konektor standardní)?	0/1
P16	Integrované přehledy	0/1
P17	Sériové a paralelní schvalování	0/1
P18	Přístupová práva pro agendy	0/1
D	Design aplikace
D01	Podporuje platforma modelování kompletně ve webovém prohlížeči, nebo je nutné na počítač „vývojáře“ nainstalovat vývojové prostředí?	0/5
D02	Bezkonfliktní spolupráce více modelářů na stejném modelu	0-5
D03	Verzování modelů a nasazování jednotlivých verzí na testovací a produkční prostředí	0-5
D04	Možnost vytvářet a testovat aplikace v testovacím prostředí (sandboxu) a následně ji publikovat ostatním modelářům (případně uživatelům)	0/5
D05	Prostředí pro sledování výkonu aplikací a business procesů	0-5

Pro požadavky, kde je hodnocení splněno/nesplněno, tj. 0 nebo číselná hodnota (šedá pole), přidělí odborná komise společně každé nabídce buď 0 bodů při nesplnění požadavku, nebo uvedenou bodovou hodnotu při splnění požadavku.

U požadavků, které jsou hodnoceny bodovou škálou (modrá pole), odborná komise společně zohlední u každé nabídky vhodnost a vyspělost nabízeného řešení/procesu ve vztahu k jednotlivým požadavkům zadavatele a dle toho nakolik odráží potřeby zadavatele, řešení přidělí body. Tzn., že žádná z nabídek nemusí získat maximální bodové ohodnocení u jednotlivých požadavků, pokud žádné z nabízených řešení nebude dostatečně odrážet potřeby zadavatele v rámci konkrétního požadavku.

Bodová škála 0-5 (lze získat 5, 3, 1 nebo 0 bodů)	Bodová škála 0-3 (lze získat 3, 2, 1 nebo 0 bodů)	Obecné zdůvodnění přidělených požadavků (při hodnocení bude vždy detailně písemně odůvodněno pro každý hodnocený požadavek)
5	3	Odráží vhodnost a vyspělost nabízeného řešení nebo procesu předmětné nabídky v rámci konkrétního požadavku s ohledem na plnou integraci požadavků do procesů, architektury, řešení (prototyp aplikace), vlastností použitého frameworku i dalších použitých nástrojů. Zadavatel nemá k nabízenému řešení připomínky.
3	2	Nabízení řešení je srovnatelné (kvalitativně) s požadavky zadavatele na vhodnost a vyspělost nabízeného řešení nebo procesu, ale zadavatel má k nabízenému řešení drobné připomínky. Nabídka naplňuje hodnocené požadavky částečně.
1	1	Nabízené řešení je s požadavky zadavatele na vhodnost a vyspělost nabízeného řešení nebo procesu srovnatelné (kvalitativně) pouze částečně, zadavatel má k nabízenému řešení podstatné připomínky. Nabídka naplňuje hodnocené požadavky velmi omezeně.
0	0	Nabízené řešení vůbec není srovnatelné (kvalitativně) s požadavky zadavatele na vhodnost a vyspělost nabízeného řešení nebo procesu, odborná komise zadavatele má k nabízenému řešení velké množství zásadních připomínek. Nabídka nevyhovuje hodnoceným požadavkům.

77.         V rámci „Vysvětlení zadávací dokumentace č. 2 ze dne 23. 12. 2020“ odpověděl zadavatel na dotaz č. 2: „V prototypu aplikace požadujete integrovat aplikaci „Cestovní příkazy“ na HR a účetní systém (…).“ následovně: „Prototyp aplikace „Cestovní příkazy“ je zadavatelem požadován pouze za účelem hodnocení nabídek dodavatelů. (…) Zadavatel nebude tento prototyp integrovat do žádného svého prostředí, a nebude tento prototyp využívat ke skutečnému zadávání cestovních příkazů. Prototyp nebude dokončen ve funkční aplikaci. Účelem prototypu je pouze prokázat splnění kritérií hodnocení A1 (…) Také nikdy v budoucnu nebude prototyp integrován na žádnou aplikaci nebo systém zadavatele. (…) Od prototypu se očekává, že předvede použití prototypové integrace na dva systémy, HR systém a účetní systém (…).“, dále na dotaz č. 3: „Bude požadovaný prototyp aplikace součástí předmětu dodávky?“ následovně: „Požadovaný prototyp aplikace nebude předmětem dodávky podle smlouvy uzavřené na základě této veřejné zakázky (…).“ a dále na dotaz č. 4: „V kapitole 14.1 V kritériu A05 hodnotíte rozsah a způsob využití kontajnerů a cloudových služeb. (…) Chápeme správně, že využití kontajnerů a public cloud služeb je preferované, tj. bude lépe hodnoceno? (…).“ následovně: „Zadavatel požaduje v rámci veřejné zakázky využití kontejnerů a cloudových služeb u prototypu aplikace „Cestovní příkazy“. Dodavatel může v rámci hodnocení dle rozsahu a způsobu využití kontejnerů a cloudových služeb u prototypu aplikace „Cestovní příkazy“ získat až 5 bodů. Rozsah a způsob využití kontejnerů a cloudových služeb musí dodavatel povinně uvést v požadované dokumentaci k prototypu aplikace, která bude tvořit součást nabídky. Využití těchto služeb bude následně ověřeno při samotné prezentaci prototypu dodavatelem a hodnocení prototypu zadavatelem (…).

78.         V rámci „Vysvětlení zadávací dokumentace č. 3 ze dne 23. 12. 2020“ odpověděl zadavatel na dotaz č. 1: »(…) Zadavatel požaduje pro účely hodnocení předložení prototypu funkční aplikace „Cestovní příkazy“ s přesně stanovenými požadavky na funkcionality. Tato aplikace přitom nemá souvislost se zadavatelem uvedeným předmětem veřejné zakázky (…) Požadavky, které chce zadavatel bodově hodnotit, mohou být hodnoceny i na vzorku aplikace s jinými funkcionalitami (…) Upraví zadavatel požadavky zakázky (…) na předložení vzorku tak, aby odpovídaly předmětu veřejné zakázky a nediskriminovaly bezdůvodně velkou část dodavatelů?« následovně: „(…) Zadavatel je názoru, že souvislost prototypu aplikace s předmětem zakázky je právě v požadavcích na architekturu, technologie, procesy, design, dokumentaci, které budou hodnoceny v rámci kritérií hodnocení A1 (…) Zadavatel připouští, že schopnost dodavatele poskytovat zadavatelem požadované služby by izolovaně mohla být prokázána i na jiné aplikaci (…) Zadavatel (…) přistoupil k jednotnému zadání (…) aby nabídky mohly být v rámci hodnocení vzájemně porovnatelné (…) Na vytvoření vlastního prototypu nikoli plně funkční aplikace odhaduje zadavatel pracnost do 5 MD. Na související dokumentaci a prezentaci architektury, technologií, procesů, designu, dokumentace a prezentaci řešení odhaduje zadavatel pracnost 10 až 15 MD. Dokumentace bude následně využita jako postupy a vzory při dodávání předmětu plnění zakázky a má tedy souvislost s předmětem plnění zakázky (…).“.

Posouzení věci

79.         Navrhovatel v podaném návrhu brojí mj. proti požadavku zadavatele, podle něhož musí každá nabídka povinně obsahovat prototyp aplikace „Cestovní příkazy“. Uvedený požadavek považuje navrhovatel za nezákonný z toho důvodu, že předmětná aplikace se podle jeho názoru nevztahuje k předmětu plnění veřejné zakázky a její funkcionality nejsou v zadávací dokumentaci popsány dostatečně podrobně tak, aby mohl zadavatel obdržet porovnatelné nabídky.

80.         Z bodu 6.2 zadávací dokumentace (viz bod 71. odůvodnění tohoto rozhodnutí) vyplývá, že předmětem plnění prověřované veřejné zakázky je poskytování služeb v oblastech odborných konzultací a vývoje. Služby odborných konzultací se mají týkat oblasti integrací, zpracování studií, procesů a analytické a zadávací dokumentace pro vývoj. Služby oblasti vývoje pak budou zahrnovat vývoj a řešení incidentů z testování, nasazování a provozu integračních služeb, statistických sestav, reportů a dashboardů o provozu integračních služeb v centrálním úložišti logů, integračních a aplikačních komponent, integrace a konfigurace agentů a nástrojů Azure DevOps s Oracle. V rámci prověřované veřejné zakázky tedy zadavatel poptává specializované služby (konzultační a vývojové) za účelem inovace integrační platformy svého stávajícího informačního systému. Z obsahu čl. II. a III. obchodních podmínek (viz body 72. a 73. odůvodnění tohoto rozhodnutí) mj. plyne, že uzavřením smlouvy nebude zadavatel zavázán k objednání plnění ve stanoveném minimálním množství a rozsahu, a že odborné konzultační a vývojové služby pro proces přípravy a realizace programu nového informačního systému zadavatele budou poskytovány v průběhu celé doby účinnosti smlouvy na základě jednotlivých objednávek, uzavíraných dle aktuálních potřeb a požadavků zadavatele, přičemž detailní požadavky na plnění budou specifikovány zadavatelem po konzultaci s vybraným dodavatelem (poskytovatelem). S ohledem na uvedenou specifikaci předmětu plnění lze konstatovat, že v zadávací dokumentaci není předmět plnění detailně (podrobnými požadavky) vymezen, neboť detaily plnění budou upřesňovány v rámci konzultací zadavatele a vybraného dodavatele. Uzavřením smlouvy na veřejnou zakázku tak zadavatel získá tým specialistů konzultačních a vývojových služeb, kteří v návaznosti na postupně předkládané požadavky zadavatele (dle jeho aktuálních potřeb) budou poskytovat příslušné konzultační a vývojové služby za účelem zajištění efektivní přípravy a realizace programu nového informačního systému ve VZP ČR.

81.         V bodu 11. zadávací dokumentace (viz bod 75. odůvodnění tohoto rozhodnutí) pak zadavatel stanovil požadavek na doložení prototypu aplikace „Cestovní příkazy“ (jakožto vzorek k testování) a dále zde upřesnil, že tento prototyp bude v rámci hodnocení nabídek (jakožto kritérium hodnocení) hodnotit. Ve „Vysvětlení zadávací dokumentace č. 2 ze dne 23. 12. 2020“ zadavatel k danému požadavku uvedl, že prototyp aplikace „Cestovní příkazy“ nebude součástí předmětu dodávky týkající se nyní zadávané veřejné zakázky, a že tento prototyp aplikace nebude nikdy integrovat do žádného svého prostředí, ani ho nebude využívat ke skutečnému zadávání cestovních příkazů. Dále specifikoval, že se od prototypu očekává, že předvede použití prototypové integrace na dva systémy. Souvislost prototypu aplikace s předmětem zakázky zadavatel dle „Vysvětlení zadávací dokumentace č. 3 ze dne 23. 12. 2020“ spatřuje v požadavcích na architekturu, technologie, procesy, design a dokumentaci, které budou v rámci kritérií hodnocení A1 hodnoceny a současně uvádí, že schopnost dodavatele poskytovat požadované služby by izolovaně mohla být prokázána i na jiné aplikaci (viz body 77. a 78. odůvodnění tohoto rozhodnutí). Z obsahu vyjádření zadavatele ze dne 10. 8. 2021 (viz bod 57. odůvodnění tohoto rozhodnutí) dále plyne, že při tvorbě prototypu aplikace „Cestovní příkazy“ musí být prováděny tytéž činnosti, které bude dodavatel realizovat v rámci plnění veřejné zakázky (tj. vývoj aplikačních komponent, vývoj integračních služeb, vývoj sestav, zpracování studie, analytické a zadávací dokumentace). Zadavatel v předmětném vyjádření upřesnil, že předmětem veřejné zakázky bude vývoj a tvorba aplikací z oblasti integrace, které nejsou běžně dostupné na trhu a zadavatel bude vyžadovat jejich vytvoření „na míru“ svým potřebám, přičemž v porovnání s aplikací „Cestovní příkazy“ se bude jednat o náročnější a rozsáhlejší aplikace.

82.         Z uvedeného vyplývá, že ačkoliv zadavatel neplánuje požadovaný prototyp aplikace nikdy využít v praxi (tedy ani v rámci předmětu plnění prověřované veřejné zakázky), spatřuje jeho souvislost s předmětem plnění v jednotlivých požadavcích stanovených na prototyp pro účely hodnocení (v požadavcích na architekturu, technologie, procesy, design a dokumentaci). Uvedenou skutečnost zadavatel potvrdil i ve vyjádření k návrhu, kde uvedl: „Dodavatelé na předloženém prototypu (…) mají demonstrovat, že požadavky Zadavatele na architekturu, technologie, procesy aj. budou schopni plnit v rámci následného poskytování služeb, které tvoří (…) předmět plnění této veřejné zakázky.“. Je tedy zřejmé, že zadavatel hodlá na prototypu aplikace sledovat přístup dodavatelů ke konkrétnímu zadání a při porovnání jednotlivých předložených řešení vyhodnotit, do jaké míry jsou dodavatelé schopni splnit jednotlivé požadavky, které dle jeho vyjádření budou rovněž promítnuty do předmětu plnění.

83.         Úřad v obecné rovině nevylučuje možnost ověřit si na vzorovém řešení schopnosti dodavatele a seznámit se tak se způsobem, stylem, vyspělostí či originalitou jeho práce. Zejména v případě, kdy se jedná o veřejnou zakázku na služby, které bude vybraný dodavatel realizovat až po podpisu smlouvy (a tudíž je z logiky věci nemá před podáním nabídky „na skladě“), je zřejmé, že reálnou představu o kvalitě a úrovni prováděných služeb lze získat na základě ukázky realizace prací demonstrujících plnění, jež zadavatel poptává. Typickým příkladem takového „ověření schopností budoucího dodavatele“ na „ukázce provedení služby, která již nebude využita“ je hodnocení úrovně nabízených právních služeb, kdy dodavatelé předkládají např. zpracovanou rešerši či žalobu, které však slouží pouze jako ukázka provedení poptávaného typu služby. Ve vztahu k prověřovanému případu Úřad připouští, že za účelem poskytování mj. vývojářských služeb týkajících se inovace informačního systému lze jejich kvalitu či úroveň ověřit na jejich ukázce v rámci zjednodušeného zadání pro vývoj aplikace a v případě, že zadavatel hodlá kvalitu služeb hodnotit prostřednictvím úrovně splnění jednotlivých procesů či postupů, jež jsou při vývoji aplikace realizovány, lze v uvedeném spatřovat jistou provázanost. Uvedenou skutečnost ostatně potvrzuje i sám navrhovatel, když připouští, že na základě předloženého prototypu lze zjistit, zda je příslušný dodavatel schopen vývoje software (viz bod 65. odůvodnění tohoto rozhodnutí). Ačkoliv tedy hodnocený prototyp aplikace „Cestovní příkazy“ nebude využit v rámci předmětu plnění, v případě, že jeho provázanost s předmětem plnění spočívá v obdobnosti postupů a procesů při jeho vývoji, lze předmětné hodnotící kritérium považovat za souladné se zákonem, neboť v takovém případě by se jednalo o „prototyp postupů dodavatele“, které budou uplatněny (nebo které bude možné uplatnit) při plnění veřejné zakázky a v takovém případě lze předmětný prototyp považovat za vzorek plnění ve smyslu § 103 odst. 1 písm. a) zákona.

84.         V prověřovaném případě tedy zadavatel směřoval k hodnocení nabídek z hlediska schopnosti dodavatele při zpracování aplikace „na míru“, která měla splňovat určité požadavky (zadat/schválit žádanku, zadat podrobnosti a náklady služební cesty, vypracovat a schválit vyúčtování služební cesty, integrovat aplikaci na HR a účetní systém). Současně zadavatel k předmětnému prototypu aplikace vyžadoval zpracování dokumentu (prezentace) obsahujícího informace o procesech, postupech, designu, analytickou a programátorskou dokumentaci, přístup k testování, akceptaci a nasazování do jednotlivých typů prostředí a další informace (viz bod 76. odůvodnění tohoto rozhodnutí). Při porovnání požadavků zadavatele na prototyp aplikace „Cestovní příkazy“ a předmětu plnění veřejné zakázky Úřad shledal, že na hodnoceném prototypu aplikace dodavatel předvede vývoj aplikační komponenty (program, který umožní zadat a schválit žádanku či schválit služební cestu), integraci aplikace s jiným systémem (integrační služby), vývoj sestavy (vyúčtování služební cesty) a rovněž zpracování příslušné analytické a programátorské dokumentace, přičemž v rámci předmětu plnění bude zadavatel požadovat vývoj a tvorbu aplikací z oblasti integrace „na míru“ dle jeho aktuálních potřeb, kdy součástí předmětu plnění bude rovněž mj. zpracování analytické dokumentace. Vývoj aplikace, integrační služby, zpracování sestav a analytické dokumentace jsou tak shodnými funkcionalitami či prvky hodnoceného prototypu a předmětu plnění veřejné zakázky, přičemž vhodnost a vyspělost jejich řešení (postupy, procesy a zvolené technologie) při hodnocení dle hodnotícího kritéria A1 (splnění požadavků na prototyp aplikace, prostředí aplikace, procesy, postupy vzájemné spolupráce) pomohou zadavateli vybrat vhodného kandidáta na realizaci požadovaného plnění. Úřad na tomto místě upozorňuje, že předmět plnění není (a s ohledem na specifika projednávané věci ani nemůže být) stanoven konkrétněji, neboť konkrétní části plnění budou realizovány až po konzultacích mezi zadavatelem a vybraným dodavatelem v návaznosti na požadavky předložené zadavatelem. Pokud navrhovatel namítá, že vybraný dodavatel nebude povinen při plnění veřejné zakázky využít postupů, technologií či procesů užitých při vyhotovení prototypu aplikace „Cestovní příkazy“, Úřad k tomuto uvádí, že pro posouzení skutečnosti, zda takto zvolené hodnotící kritérium souvisí s předmětem veřejné zakázky je zcela postačující fakt, že postupy, procesy či technologie využité při vývoji prototypové aplikace v rámci předmětu plnění mohou být využity, přičemž je pouze na zadavateli, jaké postupy, procesy a technologie budou v případě jednotlivých objednávek při plnění veřejné zakázky v návaznosti na provedené konzultace s vybraným dodavatelem nakonec použity. S ohledem na uvedené má Úřad za prokázané, že prototyp aplikace „Cestovní příkazy“ souvisí s předmětem veřejné zakázky, a proto jej lze posuzovat jako hodnotící kritérium stanovené v souladu se zákonem.

85.         Co se týče navrhovatelem namítané „vágnosti“ vymezení funkcionalit požadovaného prototypu, Úřad k tomuto uvádí, že požadavky, kterými zadavatel vymezil, co musí prototyp aplikace „Cestovní příkazy“ umět a co dále musí dodavatel na prezentaci prototypu předvést, jsou sice stručné, ale lze je považovat za srozumitelné (tj. na základě vymezení požadavků na povinné funkcionality prototypu nelze hovořit o možnosti „dvojího výkladu“). Zadavatel v popisu prototypu jednoznačně stanovil, jaké úkony (operace) musí předmětná ukázková aplikace umožnit (zadat/schválit žádanku, integrovat aplikaci na jiné systémy, vypracovat vyúčtování atd.) (viz bod 76. odůvodnění tohoto rozhodnutí) s tím, že ve vysvětlení zadávací dokumentace č. 3 ze dne 23. 12. 2020 zadavatel odhaduje pracnost na vytvoření prototypu do 5 MD a na související dokumentaci a prezentaci řešení 10 až 15 MD. I na základě uvedeného zadání lze dovodit, že zadavatel sám považuje za plně dostačující za účelem hodnocení předložení jednoduché aplikace, na níž dodavatel předvede několik úkonů včetně možnosti integrace na jiné systémy a současně doloží dokumentaci popisující zvolené řešení při jejím vývoji.

86.         K názoru navrhovatele, že na základě nedostatečného popisu funkcionalit prototypu může zadavatel obdržet neporovnatelné nabídky, což navrhovatel dovozuje na základě úvahy, že dojde k vytvoření funkčně odlišných prototypů nebo že někteří dodavatelé mohou zadavateli předložit již existující aplikace, Úřad uvádí následující. Možnost vytvoření funkčně odlišných prototypů Úřad nepovažuje v návaznosti na výše uvedené jednoznačné zadání na funkcionality prototypu za odůvodněnou, neboť pokud by v daném případě zadavatel obdržel funkčně odlišný prototyp aplikace, jednalo by se o nesplnění zadávacích podmínek, a tedy taková nabídka, která by obsahovala prototyp, který by se funkčně lišil od prototypu aplikace požadovaného zadavatelem (který by např. neschvaloval žádanky, ale generoval by různé sestavy týkající se služebních cest nebo osobních dat zaměstnanců), by nemohla být vůbec hodnocena. Co se týče druhé možnosti, kdy navrhovatel dovozuje možnou neporovnatelnost předloženého řešení v důsledku předložení již existující aplikace, Úřad uvádí, že stručné a jednoznačné vymezení požadavků na funkcionality prototypu nemůže být příčinou neporovnatelnosti nabídek ani v případě, kdy by zadavatel obdržel k hodnocení již existující aplikaci, která by umožňovala všechny zadavatelem požadované úkony a procesy. Pokud by totiž předložená již existující aplikace splňovala (krom jiného) všechny požadavky zadavatele (tj. obsahovala by povinné funkcionality), je zřejmé, že by i takovou aplikaci bylo možné porovnat s aplikací vytvořenou pouze pro účely hodnocení. Ačkoliv nelze vyloučit, že předložením již existující aplikace by takový dodavatel byl ve výhodě, neboť by nemusel věnovat za účelem zpracování nabídky čas a finance vytvoření zcela nové aplikace „od začátku“, nelze hovořit o neporovnatelnosti nabídek na základě jednoduchého vymezení požadavků na funkcionality aplikace. K tomu Úřad uvádí, že dle jeho názoru požadavky zadavatele ohledně prototypu představují rovné podmínky, což nutně nemusí znamenat, že je tím dosaženo stavu, kdy tyto „rovné“ podmínky dopadají na každého dodavatele „stejně“.

87.         Úřad nepřehlédl, že navrhovatel výše uvedenou argumentaci týkající se „vágnosti“ vymezení funkcionalit prototypu „aplikace“ (a následné neporovnatelnosti nabídek) opírá rovněž o skutečnost, že byl nucen pro účely nabídky předmětný prototyp vytvořit, přičemž reálná pracnost vytvoření prototypu činila v daném případě 100 MD (tzn. že pracnost při vytvoření zadavatelem požadované aplikace pro účely hodnocení několikanásobně převýšila odhad zadavatele). K uvedenému Úřad opakovaně poznamenává, že zadání zadavatele v podobě vymezení funkcionalit neshledal jako nejednoznačné, tj. takové, které by mohlo zapříčinit dvojí výklad a následnou neporovnatelnost nabídek. Jinými slovy i aplikace, která obsahuje více funkcionalit než zadavatel požaduje, případně aplikace, jejíž zpracování mohlo trvat déle než činil předpoklad časové rezervy ze strany zadavatele, nečiní příslušnou nabídku neporovnatelnou s nabídkami, které obsahují aplikace, na nichž jejich autor pracoval kratší dobu. Úřad připouští, že v rozhodnutí ze dne 14. 4. 2021 dovozoval v návaznosti na výše avizovanou vysokou pracnost vytvoření prototypu nepřiměřenost předmětné zadávací podmínky. Uvedená úvaha Úřadu však byla ze strany předsedy Úřadu shledána jako nesprávná, neboť podle závěrů předsedy Úřadu uvedených v druhostupňovém rozhodnutí nelze přiměřenost požadavku na předložení prototypu aplikace zkoumat ve vztahu k „představám účastníků zadávacího řízení, a to bez ohledu na to, jak konkrétně jsou vyjádřené.“. S ohledem na výše uvedené se proto Úřad argumentací navrhovatele týkající se pracnosti vytvoření prototypu dále podrobněji nezabýval, neboť závěr o souladu požadavku  na prototyp se zásadou přiměřenosti si Úřad dokázal učinit již výše (viz bod 83. a 84. odůvodnění tohoto rozhodnutí).

K vymezení pravidel pro hodnocení dílčího kritéria A1 - „Splnění požadavků na prototyp aplikace, prostředí aplikace, procesy, postupy vzájemné spolupráce“

88.         Ke stanovení způsobu hodnocení nabídek Úřad nejprve obecně uvádí, že základním dokumentem zadávacího řízení a nejvýznamnějším zdrojem informací, na jejichž základě zpracovávají dodavatelé své nabídky, je zadávací dokumentace veřejné zakázky. Zákon proto zadavateli ukládá povinnost stanovit a poskytnout zadávací podmínky dodavatelům v podrobnostech nezbytných pro účast dodavatele v zadávacím řízení. Vzhledem k tomu, že hodnocení nabídek je klíčovým prvkem v procesu výběru dodavatele, je na stanovení podmínek pro hodnocení nabídek i na samotný proces hodnocení kladen zvýšený důraz, a to jak ze strany dodržení formálního postupu, tak zejména co do maximální transparentnosti a objektivity celého procesu hodnocení.

89.         Podle § 36 odst. 3 zákona je zadavatel povinen stanovit a poskytnout zadávací podmínky v podrobnostech nezbytných pro účast dodavatele v zadávacím řízení. Ve vztahu ke způsobu hodnocení je tato povinnost výslovně akcentována mj. v ustanovení § 115 zákona, v jehož odst. 1 písm. b) je zakotvena povinnost, aby zadavatel v zadávací dokumentaci stanovil metodu vyhodnocení nabídek v jednotlivých kritériích; tzn. postup, jakým způsobem bude jednotlivé nabídky hodnotit a porovnávat, z čehož by mělo být dodavatelům zřejmé, jaké aspekty zadavatel preferuje (co bude lépe hodnotit, co považuje za lepší). Za situace, kdy zadavatel takto neučiní, tzn. dostatečně nekonkretizuje, jakým způsobem bude hodnotit, neposkytuje dodavatelům dostatek informací pro zpracování nabídek, potažmo pro (možnou úspěšnou) účast v zadávacím řízení.

90.         V šetřeném případě navrhovatel mj. namítá, žezpůsob hodnocení hodnotícího kritéria A1 – „Splnění požadavků na prototyp aplikace, prostředí aplikace, procesy, postupy vzájemné spolupráce“ je stanoven neurčitě, neboť vymezení způsobu přidělování bodů k jednotlivým požadavkům na prototyp je stanoveno obecně a není zřejmé, co bude v rámci každého jednotlivého požadavku preferováno či naopak posuzováno jako nedostatek.

91.         Z obsahu zadávací dokumentace vyplývá, že zadavatel stanovil celkem 3 hodnotící kritéria, a to kritérium A1 s názvem „Splnění požadavků na prototyp aplikace, prostředí aplikace, procesy, postupy vzájemné spolupráce“ s váhou 40 %, kritérium A2 s názvem „Certifikace členů realizačního týmu“ s váhou 30 % a kritérium B s názvem „Celková nabídková cena (v Kč bez DPH)“ s váhou 30 % (viz bod 76. odůvodnění tohoto rozhodnutí). Kritérium A1 je dále děleno na celkem 46 podkritérií hodnocení. Pro některá z těchto podkritérií zvolil zadavatel metodu hodnocení podle bodové škály od 0 bodů do 3 bodů, případně od 0 bodů do 5 bodů. Celkem se tento způsob hodnocení týkal 16 podkritérií. Zadavatel ke způsobu hodnocení v zadávací dokumentaci uvedl následující: „U požadavků, které jsou hodnoceny bodovou škálou (modrá pole), odborná komise společně zohlední u každé nabídky vhodnost a vyspělost nabízeného řešení/procesu ve vztahu k jednotlivým požadavkům zadavatele a dle toho nakolik odráží potřeby zadavatele, řešení přidělí body. Tzn., že žádná z nabídek nemusí získat maximální bodové ohodnocení u jednotlivých požadavků, pokud žádné z nabízených řešení nebude dostatečně odrážet potřeby zadavatele v rámci konkrétního požadavku.“. Současně pak tento postup hodnocení doplnil tabulkou, v níž uvedl, v jakém případě dodavatel získá při hodnocení splnění požadavku hodnocených bodovou škálou 5, 3, 2, 1 nebo 0 bodů. Z této vyplývá, že zadavatel bude hodnotit nejvyšším počtem bodů, tj. 5 nebo 3 body takovou nabídku, která: „Odráží vhodnost a vyspělost nabízeného řešení nebo procesu předmětné nabídky v rámci konkrétního požadavku s ohledem na plnou integraci požadavků do procesů, architektury, řešení (prototyp aplikace), vlastností použitého frameworku i dalších použitých nástrojů. Zadavatel nemá k nabízenému řešení připomínky.“. Podobným způsobem pak zadavatel vymezuje postup přidělení bodů v hodnotách 2, 1 nebo 0.

92.         Ačkoliv lze uvést, že metoda přiřazení bodů popsaná zadavatelem je spíše obecnější a nemusí dodavatelům poskytovat naprosto jednoznačné informace o tom, za co dostanou kolik bodů, nelze i přesto takto zvolený způsob hodnocení považovat za rozporný s § 115 odst. 1 písm. b) zákona. I když názor Úřadu na tuto otázku byl původně jiný, Úřad s ohledem na právní závěry předsedy Úřadu, který  v druhostupňovém rozhodnutí vyslovil závazný právní závěr, že zadavatel tomuto zákonnému ustanovení dostál, neboť v zadávací dokumentaci jednak stanovil metodu vyhodnocení nabídek v jednotlivých kritériích a jednak dostatečným způsobem popsal způsob a postup přiřazení bodových hodnot nabídkám v jednotlivých podkritériích, došel Úřad při novém posouzení věci k závěru uvedenému v předchozí větě, tj. že zadavatel dodržel pravidlo stanovené v § 115 odst. 1 písm. b) zákona.

93.         Podle předsedy Úřadu „současný zákon o veřejných zakázkách klade větší důraz na to, aby zadavatelé hodnotili nabídky na veřejné zakázky nikoliv výhradně podle nabídkové ceny, ale podle ekonomické výhodnosti. I přesto, že tuto možnost obsahoval i dřívější zákon o veřejných zakázkách, uchylovali se zadavatelé častěji spíše k hodnocení podle nejnižší nabídkové ceny. Nicméně s vývojem rozhodovací praxe došlo k poměrně výraznému posunu i u zadavatelů, kteří ve větší míře k hodnocení nabídek používají i kritéria kvality. V souvislosti s tím lze konstatovat, že i na straně zadavatelů dochází k pozitivnímu vývoji nejen, co se týče samotného použití kritérií kvality, ale také v nastavování metod a způsobů jejich hodnocení v zadávacích podmínkách. Při přezkoumávání zadávacích podmínek, které stanoví způsob hodnocení nabídek podle kritérií kvality, je však nutné nalézt rovnováhu v právech a povinnostech zadavatelů a dodavatelů. Nelze proto požadavky na přesnost vymezení hodnotících kritérií vykládat tak, že dodavatel musí ze zadávacích podmínek vždy získat zcela přesnou informaci o tom, kolik bodů dostane za každý aspekt podané nabídky. To platí zvláště za situace, kdy je proti tomu postavena povinnost zadavatele hodnotící kritéria vymezit tak přesným způsobem, že mu již neumožňují jakékoliv subjektivní posouzení nabídky.“.

94.         Předseda Úřadu rovněž vyslovil v druhostupňovém rozhodnutí obecné východisko, podle něhož „účelem subjektivních hodnotících kritérií je poskytnout prostor subjektivnímu uvážení zadavatele při hodnocení nabídek. Při posouzení právní otázky, do jaké míry musí být stanovená hodnotící kritéria konkrétní, je třeba především vycházet z jejich účelu. Pokud je to možné, zadavatel se musí snažit tato kritéria v zadávací dokumentaci co nejvíce objektivizovat. Nicméně, právě proto, že podstata subjektivních hodnotících kritérií souvisí s uvážením zadavatele, nelze požadavek objektivizace aplikovat tak přísně, aby subjektivní hodnotící kritérium ztratilo svůj význam tím, že by se stalo až příliš objektivním. U každého subjektivního hodnotícího kritéria jistě existuje určitá hranice, kterou už při jeho objektivizaci nelze přestoupit, jinak by se setřel jeho význam kritéria subjektivního.“.

95.         Podle § 116 odst. 2 zákona mohou být kritériem kvality například i estetické nebo funkční vlastnosti či uživatelská přístupnost, přičemž podle § 116 odst. 3 zákona musí být kritéria kvality vymezena tak, aby podle nich nabídky mohly být porovnatelné a naplnění kritérií ověřitelné.

96.         V této souvislosti předseda Úřadu v druhostupňovém rozhodnutí uvedl, že »Zadavatel u takovýchto subjektivních hodnotících kritérií musí specifikovat, na základě čeho bude naplnění těchto kritérií hodnotit, tzn. že musí podrobně rozepsat, co bude hodnotit (předmět hodnocení), jaké vlastnosti předmětu hodnocení mají vliv na výsledek hodnocení, a nakonec jakou metodou bude přidělovat ohledně jednotlivých kritérií a dílčích kritérií bodové hodnocení. Takové vymezení vyplývá i z judikatury správních soudů, konkrétně např. z rozsudku krajského soudu v Brně ze dne 25. 2. 2020 č. j. 31 Af 35/2018-75 podle nějž: „Na zadavateli bylo, aby jasně uvedl, co je pro něj důležité (tj. jasně vymezil kritéria kvality), jak moc je to pro něj důležité (aby těmto kritériím přidělil váhu) a k čemu bude při hodnocení míry naplnění jednotlivých kritérií přihlížet (uvedl určitá hlediska, metodu hodnocení, vysvětlení kritéria).“ (bod 26 rozsudku). Ačkoliv předmětem posouzení případu, k němuž se vztahuje citovaný rozsudek, bylo zadání koncese, lze závěry ohledně kritérií kvality aplikovat i na daný případ. Současně je vhodné citovat i další ze závěrů obsažených v uvedeném rozsudku, v němž krajský soud uvádí: „Požadavek na srozumitelnost a jednoznačnost kritérií kvality ale neznamená nutnost stanovit kritéria tak, aby hodnocení nabídek bylo vždy výsledkem matematického výpočtu či určitého měření. V rámci kritérií kvality může zadavatel vznášet řadu požadavků, které nebudou zcela exaktně měřitelné. Může se přitom jednat o zcela legitimní požadavky odpovídající předmětu veřejné zakázky (resp. koncese) i smyslu právní úpravy. V takovém případě je vytvářen určitý prostor pro uvážení hodnotící komise, který sám o sobě nepředstavuje rozpor s právní úpravou zadávání veřejných zakázek (srov. žalobcem citovaný rozsudek Soudního dvora ve věci TNS Dimarso NV). Jestliže stanovený způsob hodnocení kritérií kvality připouští uvážení hodnotící komise, neznamená to nutně, že by se jednalo o netransparentní postup. Transparentnost se odvíjí od rozsahu takového uvážení. Jestliže je samotné kritérium kvality či způsob jeho hodnocení natolik vágní či nejednoznačný, že umožňuje svévoli hodnotící komise, lze jistě hovořit o netransparentním vymezení zadávacích podmínek. Je však nutno rozlišovat mezi tím, kdy zadávací podmínky ponechávají hodnotící komisi prostor pro svévoli a kdy ji pouze ponechávají právem aprobovaný prostor pro uvážení.“ (bod 16 rozsudku (…).«.

97.         S odkazem na výše uvedené a na závěry učiněné předsedou v druhostupňovém rozhodnutí Úřad konstatuje, že v daném případě zadavatel vymezeným požadavkům dostál, neboť v rámci jednotlivých kritérií i podkritérií hodnocení podrobně popsal, co bude hodnotit, a vymezil, jaké vlastnosti budou mít vliv na hodnocení. Současně pak popsal i metodu přidělení bodového hodnocení. Současně ovšem možný prvek nejistoty je zadávacími podmínkami natolik omezen, že hodnotící komisi při hodnocení nabídek ponechává toliko aprobovaný prostor pro uvážení, aniž by vzbuzoval pochybnosti o možnosti svévole při hodnocení. Zadavatel tak vyvinul dostatečné úsilí k tomu, aby svá hodnotící kritéria objektivizoval. Tam, kde mohl, snažil se o co nejpodrobnější popis nastavených hodnotících kritérií. Tam, kde to z podstaty věci možné není, uvedl alespoň východiska, ze kterých bude při hodnocení vycházet. Je proto třeba uzavřít, že zadavatel nastavil hodnotící kritéria napadaná navrhovatelem v souladu se zákonem.

98.         Na základě výše uvedeného a současně s ohledem na skutečnost, že je Úřad vázán právními závěry vyslovenými v druhostupňovém rozhodnutí, Úřad konstatuje, že ve vztahu k vymezení způsobu hodnocení hodnotícího kritéria A1 - „Splnění požadavků na prototyp aplikace, prostředí aplikace, procesy, postupy vzájemné spolupráce“ Úřad neshledal důvody pro uložení nápravného opatření.

Ke stanovení dílčího hodnotícího kritéria A2 – „Certifikace členů realizačního týmu“ a k rozvržení počtu bodů pro jednotlivé certifikáty pro účely hodnocení

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

99.         V článku 14.2. „Kritérium hodnocení A2 – Certifikace členů realizačního týmu“ zadávací dokumentace[2] zadavatel stanovil následující podmínky:

„Hodnocení dle tohoto kritéria je dáno body v níže uvedené tabulce.

Účastník v rámci své nabídky předloží seznam certifikátů (z níže uvedených certifikátů), kterými disponují členové týmu vč. uvedení jména konkrétního člena týmu příp. členů týmu), který certifikátem disponuje. (…)

Pro hodnocení podle tohoto kritéria je rozhodující, zda libovolný člen realizačního týmu má jednu z níže uvedených certifikací. Pokud má stejnou certifikaci více členů realizačního týmu, bodové hodnocení se nenásobí počtem členů týmu, kteří jsou certifikováni, ale započte se pouze jednou na celý tým.

Certifikáty požadované u jednotlivých členů realizačního týmu v rámci prokázání technické kvalifikace (uvedené v čl. 6 Podmínek kvalifikace) nejsou součástí hodnotících kritérií a účastníkům za ně v rámci hodnotících kritérií nebudou přiřazeny body.

Certifikát	Body
Certified Scrum Master/Certified Scrum Professional/Agile Certified Professional	6
Oracle SOA Suite Certified Implementation Specialist	5
Oracle WebLogic Server Certified Implementation Specialist	5
Oracle Certified Professional Java Developer	3
Oracle GoldenGate Certified Implementation Specialist	1
Oracle Data Integrator Certified implementation Specialist	1
Oracle Database PL/SQL Developer Certified Professional	1
Azure Security Engineer	1
Azure Solutions Architect	2
Azure DevOps Engineer	2
IBM Certified Specialist – FileNet Content Manager	3
Alfresco Content Services	2
Alfresco Process Services	2

U každé nabídky budou následně sečteny body, které daná nabídka získala v rámci Kritéria hodnocení A2. (…)“.

Posouzení věci

100.     Navrhovatel ve svém návrhu poukazuje rovněž na hodnotící kritérium A2 – „Certifikace členů realizačního týmu“ (dále také jen „hodnotící kritérium A2“), které je podle jeho názoru stanoveno nepřiměřeně, resp. nedovoluje provést řádné hodnocení nabídek tak, aby se rozsah certifikací mohl relevantně odrazit v hodnocení kvalifikace účastníků pro plnění veřejné zakázky. Současně navrhovatel namítá, že rozvržení počtu bodů pro jednotlivé certifikáty pro účely hodnocení není odůvodněné, a že neodráží míru kvalifikace dodavatele pro danou veřejnou zakázku.

101.     Ve vztahu k navrhovatelem namítanému stanovení nepřiměřeného počtu certifikátů členů realizačního týmu, které mají být předmětem hodnocení, Úřad uvádí následující.

102.     Z obsahu dokumentace o zadávacím řízení, konkrétně z obsahu článku 6. přílohy č. 2 zadávací dokumentace (Podmínky technické kvalifikace) (viz bod 123. odůvodnění tohoto rozhodnutí) a článku 14.2 zadávací dokumentace (viz bod 99. odůvodnění tohoto rozhodnutí) vyplývá, že zadavatel v zadávacích podmínkách stanovil jednak požadavky na povinné kvalifikační předpoklady/požadavky, tj. podmínky účasti dodavatele v zadávacím řízení (v rámci požadavků na technickou kvalifikaci) a dále požadavky, které představují podklady pro hodnotící kritérium A2 - „Certifikace členů realizačního týmu“. Ve vztahu k požadavkům na doložení konkrétních certifikátů členů realizačního týmu za účelem hodnocení prostřednictvím hodnotícího kritéria A2 Úřad uvádí, že v daném případě se nejedná o obligatorní podmínku účasti, což znamená, že i dodavatel se členy realizačního týmu, kteří nedisponují certifikáty zvolenými zadavatelem pro účely hodnocení, se mohl zadávacího řízení zúčastnit. Úřad na tomto místě upozorňuje, že navrhovatel ve své argumentaci nenamítá nepřiměřenost stanovení hodnotícího kritéria A2 ve vztahu k předmětu veřejné zakázky, tj. nerozporuje skutečnost, zda certifikáty uvedené v rámci hodnotícího kritéria A2 souvisí s předmětem plnění veřejné zakázky. Podle jeho názoru je však nepřiměřený počet certifikátů, za něž lze získat v rámci hodnocení dle hodnotícího kritéria A2 příslušné bodové ohodnocení. Navrhovatel má za to, že v takovém případě je diskriminována část dodavatelů, kteří sice nedisponují takovým počtem certifikátů členů realizačního týmu, ale mají jinak stejně kvalifikované členy realizačního týmu.

103.     Zadavatel předmětnou zadávací podmínku (hodnotící kritérium A2) v rozhodnutí o námitkách odůvodňuje tak, že hodnocené certifikáty sice nejsou pro splnění předmětu plnění zcela nezbytné, ale představují pro zadavatele kvalitnější poskytování poptávaných služeb. Zadavatel považuje za oprávněné očekávat, že tým, který bude disponovat danými certifikáty, bude kvalifikovanější a jím poskytované plnění kvalitnější. Dále zadavatel upřesnil, že předmětné certifikáty zvolil pouze za účelem získat pro plnění co možná největší odborníky, a v důsledku toho co nejkvalitněji naplnit celý předmět plnění veřejné zakázky.

104.     S ohledem na uvedené odůvodnění zadavatele lze konstatovat, že zadavatel byl při stanovení předmětné zadávací podmínky nepochybně veden snahou zajistit pro plnění veřejné zakázky vysoce kvalifikované členy realizačního týmu dodavatele, jejichž odborná kvalifikace bude zužitkována při realizaci veřejné zakázky.

105.     Rozhodovací praxe předsedy Úřadu nabádá Úřad k tomu, aby při formulaci závěrů ohledně naplnění podmínek skryté diskriminace přistupoval zdrženlivě, maje na paměti, že kontrola zadávání veřejných zakázek má být smysluplná a nemá klást na zadavatele nelogické a přehnané požadavky. Úřad má rovněž respektovat, že zadavatel je oprávněn stanovit kritéria hodnocení veřejné zakázky s ohledem na řádné zajištění svých potřeb. V této souvislosti platí, že k přezkumu důvodů zadavatele, kterými obhajuje nastavení hodnotících kritérií veřejné zakázky, by měl Úřad přistoupit pouze v případě zásadní logické či racionální nesrovnalosti, která zároveň bude z jeho strany dostatečně odborně podložena (k tomu srovnej rozhodnutí předsedy Úřadu sp. zn. R0216/2019 ze dne 21. 1. 2020). Úřad má za to, že zadavatel nastavením předmětného hodnotícího kritéria zjevně usiluje o bonifikaci dodavatele se členy týmu, kteří v příslušné odborné oblasti absolvovali více certifikačních kurzů, a kteří tímto způsobem rozšířili své vzdělání a svou odbornost pro poskytování konzultačních a vývojových služeb vztahujících se k předmětu plnění veřejné zakázky. Není přitom na Úřadu (a ani na navrhovateli), aby zadavateli určoval, co má být předmětem jeho hodnocení a zda má pro zadavatele smysl, aby získal co nejzkušenějšího dodavatele, jak ostatně konstatoval i předseda Úřadu ve výše uvedeném rozhodnutí. Dle Úřadu je třeba upozornit zejména na rozdíl proti situaci, kdy by zadavatel nastavil přísně podmínky kvalifikace, a omezil tak hospodářskou soutěž. V šetřeném případě však zadavatel neomezil možnost dodavatelů účastnit se zadávacího řízení, nýbrž pouze zvýhodnil ty, kteří disponují co největším počtem certifikátů, a to za účelem získání kvalitního dodavatele pro realizaci veřejné zakázky. V daném případě tedy nelze hovořit o bezdůvodném zvýhodnění některých dodavatelů, neboť zadavatel svůj požadavek odůvodnil objektivní potřebou zajistit co možná nejkvalitnější realizaci veřejné zakázky. S přihlédnutím k výše uvedenému dospěl Úřad k závěru, že ve vysvětlení zadavatele neshledává zásadní logické či racionální nesrovnalosti a skutečnost, že má některý z dodavatelů, resp. účastníků zadávacího řízení členy realizačního týmu, kteří nedisponují všemi certifikáty stanovenými zadavatelem pro účely hodnocení v rámci hodnotícího kritéria A2, lze hodnotit pouze jako jeho komparativní nevýhodu, nikoliv jako jeho diskriminaci.

106.     Zároveň Úřad k tomuto kritériu hodnocení uvádí, že bylo stanoveno průhledným, korektním a právně předvídatelným způsobem (jinými slovy bylo řádně zveřejněno a všichni dodavatelé se s ním mohli seznámit v tentýž okamžik), platí stejně pro všechny dodavatele, a že jeho naplnění je jasně ověřitelné (dodavatelé jsou povinni podle článku 14.2. zadávací dokumentace uvést ke každému certifikátu jméno člena týmu, který předmětným certifikátem disponuje).

107.     Jak již bylo uvedeno výše, Úřad dospěl k závěru, že zadavatel formulací předmětné zadávací podmínky, konkrétně kritéria hodnocení, pouze usiluje o dodavatele, který disponuje personálním zázemím, se zkušenými, schopnými a odborně zdatnými členy realizačního týmu s kompetencemi, které považuje za přínosné pro plnění veřejné zakázky v požadované kvalitě.

108.     Na základě výše uvedeného Úřad neshledal, že by předmětné kritérium hodnocení bylo stanoveno v rozporu se zákonem, či že by zadavatel jeho stanovením porušil zásady transparentnosti, rovného zacházení nebo zákazu diskriminace.

109.     Pokud navrhovatel namítá, že zadavatel v rozhodnutí o námitkách dostatečně nereagoval na argumentaci navrhovatele, když se „nevyjádřil nijak konkrétněji, než, že dle jeho názoru – čím více certifikátů, tím kvalitnější plnění.“, Úřad uvádí následující. Úřad posoudil obsah rozhodnutí o námitkách ve vztahu k obsahu podaných námitek týkajících se stanovení dílčího hodnotícího kritéria A2 – Certifikace členů realizačního týmu a dospěl k závěru, že se navrhovateli od zadavatele dostala vůči všem namítaným skutečnostem dostatečná zpětná vazba v tom smyslu, aby byl navrhovatel srozuměn s tím, proč zadavatel jednotlivým namítaným skutečnostem nevyhověl. Pokud navrhovatel zastává názor, že zadavatel rezignoval na své povinnosti vyplývající ze zákona, Úřad uvádí, že zadavatel v daném případě v rozhodnutí o námitkách vyložil svůj náhled na namítanou skutečnost (stanovení počtu certifikátů členů realizačního týmu za účelem hodnocení), který sice není shodný s názorem navrhovatele, avšak tato skutečnost neznamená, že by rozhodnutí o námitkách bylo zadavatelem učiněno v rozporu se zákonem.

110.     Co se týče námitky navrhovatele týkající se rozvržení počtu bodů pro jednotlivé certifikáty, zadavatel k jednotlivým certifikátům stanoveným v rámci hodnotícího kritéria A2 jejich bodové hodnocení odůvodnil ve vyjádření k návrhu následovně:

- „Certified Scrum Master/Certified Scrum Professional/Agile Certified Professional – část rozvoje IS VZP ČR v programu NIS je řízena a dodávána agilně a větší část klasicky metodou vodopád. Kromě prvotního nastavení spolupráce mezi Zadavatelem a dodavatelem, očekává Zadavatel požadavky na odborné konzultace, zpracování studií nebo procesů, jak vzájemně sladit a řešit vzniklé situace mezi týmy pracujícími a dodávajícími různými přístupy. Pro plnění veřejné zakázky je tento certifikát nejvýše hodnocen z důvodu nastavení, procesování a řešení rozporů navazujících prací v programu NIS řízeného odlišnými metodami.

- Oracle SOA Suite Certified Implementation Specialist – Oracle SOA Suite je hlavní komponenta integrační platformy VZP ČR, certifikát je tedy ohodnocen za 5 bodů vzhledem ke svému významu při plnění veřejné zakázky. Příslušný certifikát bude pro Zadavatele zárukou, že dodavatel je v této technologii dostatečně kvalifikovaný.

- Oracle WebLogic Server Certified Implementation Specialist - Oracle WebLogic Server je aplikační server použitý jak na integrační platformě VZP ČR, tak v komponentách stávajícího IS VZP ČR, certifikát je tedy ohodnocen za 5 bodů vzhledem ke svému významu při plnění veřejné zakázky. Znalost a zkušenosti s Oracle WebLogic Server jsou důležité při poskytování služeb v předmětu plnění veřejné zakázky.

- Oracle Certified Professional Java Developer – Zadavatel v rámci prokázání kvalifikace u role Integrační specialista požaduje povinně po všech dodavatelích předložení úrovně Associate JAVA Developer. Oracle Certified Professional Java Developer představuje vyšší formu takového certifikátu, což pro Zadavatele tedy představuje vyšší odbornost člena týmu, pročež za něj dodavatelé mohou získat další 3 body v rámci hodnocení.

- Oracle GoldenGate Certified Implementation Specialist – jednou z nových a teprve plánovaných integračních komponent je ODS. Vzhledem k využívání technologií Oracle ve stávajícím IS VZP ČR je Oracle GoldenGate přirozenou komponentou pro datové integrace s téměř on-line replikací dat mezi databázemi. Význam komponenty GoldenGate je pro integrace výrazně nižší než SOA Suite. Hodnocení je nastaveno na 1 bod.

- Oracle Data Integrator Certified Implementation Specialist – ODI je aplikace, která se ve VZP ČR využívá k vývoji a provozu ETL procesů DWH. Pro novou integrační komponentu ODS bude v pilotní fázi výhodné, pokud převezme maximum z již existujících ETL než začne využívat Oracle GoldenGate. Význam komponenty ODI je pro integrace výrazně nižší než SOA Suite. Hodnocení je nastaveno na 1 bod.

 - Oracle Database PL/SQL Developer Certified Professional – Oracle PL/SQL je programovací jazyk, ve kterém je vybudován téměř celý stávající IS VZP ČR. Znalost PL/SQL je nedílnou součástí některých výše uvedených Oracle produktů, proto je hodnocení nastaveno pouze na 1 bod.

- Azure Security Engineer – Aplikace MojeVZP a VZPPortal jsou vytvořeny a provozovány v cloudovém prostředí MS Azure. Integrace a bezpečné propojení on premise systému a aplikací s MojeVZP a VZP Portal přes integrační platformu je a bude hlavním prostředkem k dosažení digitální organizace bez papírových dokumentů. Zadavatel považuje tuto znalost jako vhodný nikoli nutný doplněk k Azure Solutions Architect, proto je hodnoceno za 1 bod.

- Azure Solutions Architect – Azure DevOps je prostředí, ve kterém bude realizováno zadávání požadavků na poskytování konzultačních a vývojových služeb a předávání výstupů předmětu plnění veřejné zakázky. Integrační služby a komponenty, které vzniknou jako předmět plnění veřejné zakázky budou propojovat stávající IS VZP ČR, aplikace MojeVZP a VZPPortal i NIS. Azure DevOps je prostředí pro řízení a realizaci spolupráce, nikoli zásadní integrační technologii VZP ČR, proto je hodnoceno za 2 body.

- Azure DevOps Engineer – Azure DevOps je prostředí, ve kterém bude realizováno zadávání požadavků na poskytování konzultačních a vývojových služeb a předávání výstupů předmětu plnění veřejné zakázky. Nedílnou součástí každé dodávky vývojových služeb v předmětu plnění veřejné zakázky bude automatizace sestavování instalačních balíčků a jejich nasazování do různých prostředí. Azure DevOps je prostředí pro řízení a realizaci spolupráce, nikoli zásadní integrační technologii VZP ČR, proto je hodnoceno za 2 body.

- IBM Certified Specialist – FileNet Content Manager – IBM FileNet je platforma Document Management Systému a navazující spisové služby. Zadavatel tuto technologii vlastní, ale nemá dodavatele nebo specialisty, kteří by dokázali řešení na této platformě rozvíjet, případně se s ním integrovat. Vzhledem k výše uvedenému a nutnosti tuto technologii integrovat do procesů VZP ČRT ohodnotil zadavatel výším počtem bodů, tj. za 3 body.

- Alfresco Content Services – V předmětu této veřejné zakázky jsou i odborné konzultace a vývoj nových aplikačních komponent. Technologie Alfresco je ve VZP ČR nově schválená pro vývoj a provozování aplikací (…). Zadavatel ohodnotil za 2 body vzhledem k očekávání akcelerace automatizace dalších agend VZP ČR.

- Alfresco Process Services – V předmětu této veřejné zakázky jsou i odborné konzultace a vývoj nových aplikačních komponent. Zadavatel ohodnotil za 2 body vzhledem k očekávání akcelerace automatizace dalších agend VZP ČR.“.

111.     Úřad shledává odůvodnění zadavatele, podle něhož certifikáty hodnocené více body mají zásadní význam k plnění předmětu zakázky, rovněž za logické. I v tomto případě totiž není úkolem Úřadu diktovat zadavateli, nakolik si má cenit jednotlivých certifikátů pro realizaci předmětné veřejné zakázky. Pokud tedy zadavatel předložil odůvodnění svých preferencí ve vztahu k jednotlivým certifikacím (např. že určitý certifikát znamená pro zadavatele důležitý přínos při poskytování služeb v předmětu plnění veřejné zakázky ze strany dodavatele a na druhé straně jiný certifikát zadavatel vnímá jako vhodný, ale ne nutný doplněk ke znalostem dodavatele), nelze než konstatovat, že své preference odůvodnil objektivními potřebami ve vztahu k plnění veřejné zakázky. Předloženou hodnotovou stupnicí v zadávací dokumentaci dal zadavatel dodavatelům jasný a srozumitelný signál, které certifikace preferuje, a tedy jaké dodavatele při hodnocení zvýhodní. Na základě výše uvedeného Úřad neshledal, že by způsob hodnocení v rámci hodnotícího kritéria A2 (rozvržení počtu bodů pro jednotlivé certifikáty) byl stanoven v rozporu se zákonem.

K požadavku zadavatele na prokázání zkušeností členů realizačního týmu s opensource technologiemi

Relevantní ustanovení zákona

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

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

114.     Podle § 28 odst. 1 písm. a) bod 2. se pro účely tohoto zákona rozumí zadávacími podmínkami veškeré zadavatelem stanovené podmínky účasti v zadávacím řízení.

115.     Podle § 28 odst. 1 písm. c) se kvalifikací rozumí způsobilost a schopnost dodavatele plnit veřejnou zakázku.

116.     Podle § 36 odst. 1 zákona nesmí být zadávací podmínky 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.

117.     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.

118.     Podle § 37 odst. 1 písm. a) zákona podmínky účasti v zadávacím řízení může zadavatel stanovit jako podmínky kvalifikace.

119.     Podle § 73 odst. 6 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í.

120.     Podle § 79 odst. 1 zákona kritéria technické kvalifikace stanoví zadavatel za účelem prokázání lidských zdrojů, technických zdrojů nebo odborných schopností a zkušeností nezbytných pro plnění veřejné zakázky v odpovídající kvalitě. Zadavatel může považovat technickou kvalifikaci za neprokázanou, pokud prokáže, že dodavatel má protichůdné zájmy, které by mohly negativně ovlivnit plnění veřejné zakázky.

121.     Podle § 79 odst. 2 písm. c) zákona k prokázání kritérií technické kvalifikace může zadavatel 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 stavení práce, bez ohledu na to, zda jde o zaměstnance dodavatele nebo osoby v jiném vztahu k dodavateli.

122.     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.

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

123.     V článku 6. odstavci 2. přílohy č. 2 zadávací dokumentace (Podmínky kvalifikace) je uvedeno: »Zadavatel v souladu s § 73 ZZVZ požaduje prokázání technické kvalifikace dodavatelů podle § 79 odst. 2 písm. d) ZZVZ. (…) Zadavatel požaduje, aby dodavatel, se kterým bude uzavřena smlouva na plnění veřejné zakázky, měl po celou dobu účinnosti smlouvy k dispozici realizační tým, který se bude podílet na plnění veřejné zakázky, bez ohledu na to, zda jde o zaměstnance dodavatele nebo osoby v jiném vztahu k dodavateli (…). Všichni členové realizačního týmu musí splňovat„Obecné požadavky na členy realizačního týmu“ a zároveň v realizačním týmu musí být takoví techničtí specialisté, aby v souhrnu splňovali všechny „požadavky na odbornost členů realizačního týmu (…)

Požadavky na odbornost členů realizačního týmu:

1.    Oblast odborných konzultací

V realizačním týmu pro zajištění odborných konzultací musí být takoví specialisté, aby v souhrnu splňovali (tj. zajišťovali) všechny požadavky na níže uvedenou odbornost členů realizačního týmu.

Realizační tým dodavatele pro zajištění odborných konzultací musí sestávat z minimálně 2 odborných pracovníků splňujících níže uvedené požadavky na odbornou kvalifikaci pro každou z níže uvedených oblastí.

a) Integrační architekt

• minimálně 3 roky praxe v oblasti integračních projektů pomocí webových služeb,
• minimálně 1 rok praxe v oblasti integračních projektů s produkty Oracle Fusion Middleware,
• znalost produktů Oracle SOA Suite, Oracle BPEL, Oracle AQ, Oracle Service Bus, MS Azure, IBM FileNet, ElasticSearch, Alfresco,
• znalost konceptů webových služeb SOAP protokolu, REST služeb, rozšíření WS Security, autentizačních mechanismů SAML a JWT,
• minimálně 1 rok praxe modelování v Enterprise Architect.

b) Integrační specialista

• minimálně 2 roky praxe v oblasti integračních projektů pomocí webových služeb,
• minimálně 1 rok praxe v oblasti integračních projektů s produkty Oracle SOA Suitě, Oracle BPEL, Oracle AQ,

• znalost produktů Oracle SOA Suite, Oracle BPEL, Oracle AQ, Oracle Service Bus, Oracle Data Integrator, Oracle GoldenGate jako vývojář,
• znalost konceptů webových služeb SOAP protokolu, REST služeb, rozšíření WS Security, autentizačních mechanismů SAML a JWT,
• znalost XML, XSD, BPEL, JAVA, Azure DevOps, Oracle PL/SQL,
• znalost skriptovacích jazyků, znalost prostředí Azure DevOps, uživatelská znalost Linuxu,
• znalost standardů dokumentace API - OpenAPI a Swaggeru, případně API Blueprint,
• požadovaná povinná certifikace:

o   Oracle Certified Associate, Java Developer (resp. Oracle Certified Associate, Java Programmer) a současně

o   Azure Fundamentals.

2.    Oblast služeb vývoje

V realizačním týmu pro zajištění služeb v oblasti vývoje musí být takoví specialisté, aby v souhrnu splňovali (tj. zajišťovali) všechny požadavky na níže uvedenou odbornost členů realizačního týmu.

Realizační tým dodavatele pro zajištění služeb vývoje musí sestávat z minimálně 3 odborných pracovníků splňujících níže uvedené požadavky na odbornou kvalifikaci pro každou z níže uvedených oblastí:

a)      Specialista Elastic

• minimálně 1 rok praxe v Elastic,
• znalost práce v Azure DevOps, uživatelská znalost Linuxu,
• požadovaná povinná certifikace:

o   Elastic Certified Engineer nebo Elastic Certified Analyst.

b)      Aplikační vývojář

• minimálně 1 rok praxe v oblasti vývoje webových aplikací,
• znalost HTML5, JavaScript,
• znalost prostředí Azure DevOps,
• požadovaná povinná certifikace:

o   Certified JavaScript Developer nebo Certified JavaScript Specialist nebo Certified JavaScript Professional a současně

o   Certified HTML5 Developer nebo Certified HTML5 Specialist nebo Certified HTML5 Professional.

c)      Integrační vývojář

• minimálně 1 rok praxe v oblasti integračních projektů pomocí webových služeb,
• znalost produktů Oracle SOA Suite, Oracle BPEL, Oracle AQ, Oracle Service Bus,
• znalost konceptů webových služeb SOAP protokolu, REST služeb, rozšíření WS Security, případně autentizačních mechanismů SAML a JWT,
• znalost XML, XSD, BPEL, JAVA,
• znalost skriptovacích jazyků, znalost práce v Azure DevOps, uživatelská znalost Linuxu,
• požadovaná povinná certifikace:

o   Oracle Certified Associate, Java Developer (resp. Oracle Certified Associate, Java Programmer).«.

124.     V rámci „Vysvětlení zadávací dokumentace č. 3 ze dne 23. 12. 2020“ odpověděl zadavatel na dotaz č. 2:

„Zadavatel stanovil požadavky na certifikace členů týmu v rámci technické kvalifikace a zároveň rozsáhlý seznam certifikací pro účely hodnocení. Při předpokládaném obsazení týmu pěti osobami se jedná o kumulaci certifikátů, která je velmi specifická, neodpovídá běžným požadavkům a na trhu se bude vyskytovat pouze u malé části dodavatelů. Upraví zadavatel požadavky na certifikáty členů týmu tak, aby více odpovídaly situaci obvyklé na trhu, tj. zúží rozsah požadovaných certifikací?“

následovně:

„(…) Zadavatel stanovil pro členy týmu technické minimum Java, JavaScript, HTML5 a Elastic Search, aby umožnil, co nejširšímu počtu dodavatelů podat nabídku na předmětnou veřejnou zakázku. Kombinaci těchto technických znalostí považuje zadavatel na trhu za běžně rozšířenou. Zadavatel provozuje systémy, aplikace a nástroje pro vývoj (DevOps) na technologiích Oracle, Oracle Fusion Middleware, IBM FileNet, Alfresco Digital Business Platform a MS Azure DevOps. Zadavatel zařadil všechny tyto technologie do hodnocení nabídek [kritérium hodnocení A2, viz bod 14.2 (…) zadávací dokumentace], aby získal co nejvhodnějšího dodavatele, pro integraci všech těchto aplikací, systémů a prostředí pro vývoj, nasazení i provoz informačních systémů. Požadavky zadavatele na certifikáty členů týmu, které budou předmětem hodnocení nabídek, zadavatel nestanovil 3 jako povinné pro účast dodavatele v zadávacím řízení, záleží tudíž na dodavateli, zda a jaké certifikáty pro účely hodnocení nabídky předloží. Zadavatel požaduje tým složený z minimálně 5 osob. Současně je dodavateli umožněno nominovat tým o více jak 5 osobách, pokud je to potřeba na pokrytí požadavků na jednotlivé technologie a certifikáty. Jednotlivé osoby nominovaného týmu dodavatelem budou objednávány v dílčích objednávkách podle potřeb zadavatele. S ohledem na výše uvedené zadavatel nebude upravovat požadavky na certifikaci členů týmu.“.

125.     V rámci „Vysvětlení zadávací dokumentace č. 4 ze dne 23. 12. 2020“ odpověděl zadavatel na dotaz č. 1:

„Zadavatel v zadávací dokumentaci v příloze č. 2 Podmínky kvalifikace pro pozici „Integrační architekt“ ve skupině 1. Oblast odborných konzultací definoval požadavek, aby tento člen realizačního týmu splňoval všechny požadavky na odbornou kvalifikaci a požaduje znalost konkrétních produktů – Oracle SOA Suite, Oracle BPEL, Oracle AQ, Oracle Service Bus, MS Azure, IBM FileNet, ElasticSearch, Alfresco. Uvedené požadavky Zadavatele jsou velice specificky zaměřené a vyžadují specializované pozice, které nelze v uvedeném rozsahu předpokládat od role integračního architekta zaměřeného na odborné konzultace či vývoj souladný s předmětem veřejné zakázky uvedeného v kap. 6.2. Hlavního dokumentu veřejné zakázky. Z pohledu Uchazeče se jedná kombinaci integračních a cloudových produktů s vyjmenovanou open-sourcovou platformou o požadavek nepřiměřený požadovanému plnění této veřejné zakázky a současně s ohledem na požadované plnění také diskriminační. Uchazeč proto tímto žádá Zadavatele o jednoznačné odborné zdůvodnění, proč pozice integračního architekta má mít tak širokou znalost velice specifických nesourodých produktů a současně o přehodnocení relevance tohoto požadavků v rámci příslušných kvalifikačních požadavků.“

následovně:

„(…) Zadavatel provozuje Integrační platformu na produktech Oracle SOA Suite a Oracle Service Bus. Vlastní integrační funkce jsou vytvořeny v jazyce BPEL a pro asynchronní komunikaci se používají Oracle AQ fronty. Jako DevOps prostředí je používán MS Azure DevOps (cloud), kam se ukládají zdrojové kódy, kde jsou definovány pipelines pro vytváření instalačních balíčků z těchto zdrojových kódů a odkud je řízeno nasazování vytvořených balíčků do jednotlivých prostředí. IBM FileNet je platforma Dokument Management Systému, který je postupně integrován s ostatními systémy VZP ČR. Alfresco Digital Business Platform (open source) je platforma drobných agend, které je potřeba integrovat s hlavními IS VZP ČR. Všechny tyto systémy generují podrobné logy, které se ukládají v ElasticSearch (open source). Z logů uložených v ElasticSearch plánuje VZP ČR připravit systém reportů a dashboardů, které budou poskytovat informace o komunikaci mezi systémy, práci uživatelů se systémy a využívání dat v těchto systémech uložených. Bez přiměřené znalosti výše uvedených produktů nemůže podle názoru zadavatele Integrační architekt poskytovat odborné konzultace a vypracovávat zadání pro vývoj pro VZP ČR. Zadavatel důkladně zvážil požadavky na roli Integračního architekta. Tyto požadavky odpovídají potřebám zadavatele a nelze je omezit. Pokud by zadavatel požadavky na roli Integračního architekta omezil, získal by dodavatele, který by nebyl schopen poskytovat odborné konzultace v celém rozsahu integrací ve VZP ČR.“.

126.     V rámci „Vysvětlení zadávací dokumentace č. 4 ze dne 23. 12. 2020“ odpověděl zadavatel na dotaz č. 2:

»Zadavatel v zadávací dokumentaci v příloze č. 2 Podmínky kvalifikace pro pozici „Integrační specialista“ ve skupině 1. Oblast odborných konzultací definoval požadavek, aby tento člen realizačního týmu splňoval všechny požadavky na odbornou kvalifikaci a požaduje znalost produktů Oracle a JAVA určené pro vývoj aplikací, u Oracle Goldengate je tak dokonce explicitně uvedeno. Současně s tím požaduje Zadavatel u dané pozice povinnou vývojářskou certifikaci Oracle Certified Associate, Java Developer a současně certifikace Azure Fundamentals. Certifikace zaměřená na vývoj vyžaduje specializovanou pozici, kterou nelze v uvedeném rozsahu předpokládat od role integračního specialisty a jde tak o požadavek nepřiměřený požadovanému plnění této veřejné zakázky a současně s ohledem na požadované plnění také diskriminační. Uchazeč proto tímto žádá Zadavatele o jednoznačné odborné zdůvodnění, proč pozice integračního specialisty má mít tak širokou znalost pro oblast vývoje, z jakého důvodu není relevantní znalost integračních platforem a současně o přehodnocení relevance tohoto požadavků v rámci příslušných kvalifikačních požadavků.«.

následovně:

„(…) Požadovaná plnění a odborné konzultace očekávané zadavatelem pro roli Integračního speciality jsou detailně vyjmenovány v Příloze č. 1 (…) zadávací dokumentace – „Obchodní podmínky“, konkrétně v její Příloze č. 1 – „Technická specifikace“. Toto plnění zahrnuje:

a) Návrh a implementaci integrací v prostředí Oracle SOA Suite a Oracle Service Bus.

b) Úpravy a rozvoj stávajících integračních služeb na platformě IPF.

c) Vytvoření konceptu řešení monitoringu integračních služeb v prostředí Elastic.

d) Návrhy a tvorby konceptů na zlepšení a rozvoj monitoringu integračních služeb.

e) Objevování, testování a ověřování nových technologií a přístupů k integraci.

f) Příprava prototypů integračních scénářů – ověření nových možností.

g) Příprava konceptů a prototypů nových integračních komponent, např. ODS.

h) Příprava konceptů a prototypů nových aplikačních komponent.

i) Návrh dokumentace a údržba standardů a doporučených postupů pro integraci.

j) Spolupráci s interními i externími vývojovými týmy, spolupráci s věcně odbornými útvary VZP ČR.

k) Účast na projektech vyžadujících poskytování integračních služeb, vč. realizace.

Podle názoru zadavatele je vynikající znalost jazyka JAVA naprosto nezbytným požadavkem např. pro „Příprava prototypů integračních scénářů“, ale i pro další plnění. Příprava konceptu a prototypu nové integrační komponenty ODS se neobejde bez znalosti produktu Oracle Golden Gate. Bez znalosti konfigurace Azure agentů a pipelines, jakož i celého prostředí Azure DevOps není možné nasadit ani prototyp do příslušného sandboxu (součást vývojového prostředí VZP ČR). Zadavatel důkladně zvážil požadavky na roli Integračního speciality. Zadavatel má však za to, že tyto požadavky odpovídají jeho potřebám, pročež je nelze omezit.“.

127.     V rámci „Vysvětlení zadávací dokumentace č. 8 ze dne 27. 1. 2021“ odpověděl zadavatel na dotaz č. 2:

„Zadávateľ vo vysvetlení zadávacej dokumentácie č. 3 zo dňa 23.12.2020 na strane 2 uvádza, že „Zadavatel provozuje systémy, aplikace a nástroje pro vývoj (DevOps) na technologiích Oracle, Oracle Fusion Middleware, IBM FileNet, Alfresco Digital Business Platform a MS Azure DevOps“. Žiadame o bližšie vysvetlenie aký majú podiel tieto technológie na aktuálnej a budúcej prevádzke informačných systémov zadávateľa. Pripúšťa zadávateľ preukázanie kvalifikácie skúsenosťami aj z iných opensource technológií? V prípade, pokiaľ zadávateľ trvá na uvedenej špecifickej technológií Alfresco Digital Business Platform, žiadame Vás ako uchádzač o podrobné odôvodnenie.“

následovně:

„(…) Zadavatel provozuje informační systém (dále IS VZP), který podporuje širokou škálu činností jak při zajišťování vlastních funkcí veřejného zdravotního pojištění, tak při podpoře interních procesů. Podíl jednotlivých technologií je zastoupen následovně:

• Nejrozsáhlejší část IS VZP je provozována na technologiích Oracle (databáze) a Oracle Fusion Middleware (aplikační servery a integrační platforma). Každý rok se počet činností a procesů podporovaných touto částí IS VZP zvyšuje o jednotky nových zajišťovaných procesů nebo činností.
• Dokument management systém, spisová služba a další dokumentové služby jsou provozovány na technologii IBM FileNet. S rostoucí digitalizací a naplňování platné legislativy plánuje zadavatel velký nárůst ve využívání této technologie.
• Pro podporu některých interních procesů zahajuje zadavatel vývoj aplikací na technologii Alfresco Digital Business Platform. Zadavatel plánuje rychle vyvinout řadu malých aplikací k podpoře interních procesů.
• Celý DevOps proces pro všechny aplikace a systémy vyžaduje zadavatel v technologii MS Azure DevOps a to včetně sestavování aplikací i instalačních balíčků (build) a nasazování do všech typů prostředí (deploy). Zadavatel vyžaduje plnou implementaci DevOps v prostředí MS Azure DevOps pro realizaci všech dodávek SW „na míru“.

Z další části dotazu není zřejmé, zda směřuje na využití Open-source při tvorbě prototypu aplikace „Cestovní příkazy“ či se vztahuje k certifikátům, uvedeným v rámci hodnotícího kritéria A2 – „Certifikace členů realizačního týmu“ (viz bod 14.2 Hlavního dokumentu zadávací dokumentace). Zadavatel tedy poskytuje následující vysvětlení: V rámci hodnotícího kritéria A1 – „Prototyp aplikace Cestovní příkazy a prezentace řešení“ (viz bod 14.1 Hlavního dokumentu zadávací dokumentace), bude odborná komise u předloženého prototypu hodnotit mj. splnění požadavku A06 – „Využití Open-source řešení“. Příslušný počet bodů obdrží od odborné komise prototyp vytvořený v jakémkoli Open source řešení. Ve vztahu k certifikátům uvedeným v rámci hodnoticího kritéria A2, zadavatel opětovně uvádí, že na technologii Alfresco Digital Business Platform plánuje zadavatel rychle vyvinout řadu malých aplikací k podpoře interních procesů. Dodavatel se znalostí Alfresco Digital Business Platform uplatní tuto znalost ve VZP ČR v rámci odborných konzultací poskytovaných členy realizačního týmu v rámci této veřejné zakázky. Namísto certifikátů Alfresco Content Services nebo Alfresco Process Services není tedy možné uznat kvalifikace a zkušenosti z jiných Open-source technologií.“.

128.     V rozhodnutí o námitkách zadavatel ve vztahu k námitkám navrhovatele týkajícím se požadavků na certifikaci a zkušenosti v rámci podmínek kvalifikace mj. uvedl:

„K požadovaným znalostem Zadavatel uvádí následující objasnění:

-       Oracle SOA Suite, Oracle Service Bus jsou produkty, na kterých je postavena integrační platforma VZP ČR.

-       Oracle AQ je integrační technologie, která se ve VZP ČR využívá pro většinu asynchronních komunikací v integračních službách.

-       Oracle Fusion Middleware je pojmenování skupiny produktů Oracle, mezi které patří Oracle SOA Suite, Oracle Service Bus používaných ve VZP ČR.

-       Oracle BPEL je druh jazyka pro vývoj integračních služeb pro Oracle SOA Suite ve VZP ČR.

-       Oracle PL/SQL je programovací jazyk podstatné části stávajícího IS VZP ČR.

-       Oracle Data Integrátor je používaný produkt a technologie, která se ve VZP ČR využívá pro ETL procesy.

-       Oracle GoldenGate je produkt o kterém VZP ČR uvažuje, jako o produktu, který má umožnit téměř on-line replikaci dat mezi stávajícím informačním systémem a budoucími komponentami integrační platformy.

-       ElasticSearch je produkt, do kterého jsou postupně ukládány logy ze všech produktů, aplikací, komponent a IT infrastruktury VZP ČR pro analýzu těchto logů a vytvoření provozního a bezpečnostního reportingu pro další využití jako Security information and event management.

-       MS Azure DevOps je prostředí pro spolupráci vývojových týmů a provozu ve VZP ČR, ve kterém řídíme a plánujeme práci vývojových týmů, předáváme výsledky práce a automaticky nasazujeme jednotlivé dodané produkty, jejich vylepšení i opravy do všech IT prostředí VZP ČR.

-       IBM FileNet je platforma pro Document management system dodaná do VZP ČR se kterou postupně začínáme integrovat i další systémy a aplikace.

-       Alfresco je platforma schválená Správní radou VZP ČR v létě 2020 pro použití na doplňkové agendy a procesy, které nepokrývá stávající IS VZP ČR.

-       Enterprise Architect je aplikace pro podporu modelování a vytváření dokumentace o systémech a aplikacích VZP ČR.

-       SOAP (Simple Object Access Protocol) je protokol pro výměnu zpráv založených na XML, na kterém jsou postaveny webové synchronní integrační služby ve VZP ČR.

-       REST (Representational State Transfer) služby jsou ve VZP ČR alternativou k SOAP službám, které zatím nejsou na integrační platformě použity, ale budou se používat např. právě s výše zmíněnou platformou IBM FileNet.

-       Webové služby jsou prostředkem pro mezi-aplikační komunikace, a tak vytvářejí vhodný nástroj pro integraci firemních systémů. VZP ČR používá webové integrační služby založené na SOAP protokolu, ale umožňuje a počítá i s REST integračními službami.

-       XML (Extensible Markup Language) je obecný značkovací jazyk. Jazyk je určen především pro výměnu dat mezi aplikacemi a pro publikování dokumentů, u kterých popisuje strukturu z hlediska věcného obsahu jednotlivých částí. Používáno ve VZP ČR.

-       WSDL (Web Services Description Language) je jazykem pro popis funkcí, jež nabízí tzv. webová služba, a dále pro popis vstupů a výstupů těchto funkcí. WSDL popisuje SOAP komunikaci ve VZP ČR. WSDL vychází z formátu XML.

-       XSD (XML Schema Definition) je schéma v XML pro popis struktury XML dokumentů. Definuje soustavu specifikací a pravidel, jak má vypadat XML dokument. Používáno ve VZP ČR.

-       WS Security (Web Services Security) je rozšíření WSDL a SOAP webových služeb pro aplikování bezpečnosti ve webových službách. Používáno ve VZP ČR.

-       SAML (Security Assertion Markup Language) je standard založený na XML poskytující mechanismus pro výměnu autentizačních a autorizačních dat mezi zúčastněnými stranami, tj. poskytovatelem služeb a poskytovatelem identity. Používáno ve VZP ČR.

-       JWT (JSON Web Token) je internetový standard pro vytváření dat s volitelným podpisem nebo volitelným šifrováním, jehož datová část obsahuje data ve formátu JSON. Plánováno k použití ve VZP ČR.

-       JAVA je programovací jazyk používaný na integrační platformě VZP ČR ke specifickým účelům.

-       Linux je počítačový operační systém serverů integrační platformy ve VZP ČR.

-       Swagger je Open source framework pro návrh, tvorbu, dokumentaci a konzumaci REST webových služeb, jejichž použití je ve VZP ČR plánováno.

-       OpenAPI, API Blueprint jazyky/formáty pro popis rozhraní webových služeb.

-       HTML5 je poslední verze jazyka HTML sloužícího pro tvorbu webových stránek a jehož podpora je požadovaná v připravovaných standardech VZP ČR.

-       JavaScript je skriptovací jazyk, který lze vložit přímo jako součást HTML webové stránky.

Zadavatel se domnívá, že požadavky na technické znalosti pro všechny požadované členy týmu jsou v souladu s technologiemi a nástroji, které VZP ČR používá, a na nichž je postaven IS VZP ČR, jsou tedy nutné k jeho dalšímu rozvoji a odpovídají složitosti a rozsahu předmětu veřejné zakázky.

K požadovaným certifikátům Zadavatel poskytuje následující odůvodnění:

-       Java Developer je požadován pro prokázání znalosti programovacího jazyka JAVA, konceptů a součástí webových služeb.

-       Azure Fundamentals je požadován pro prokázání znalosti prostředí AZURE DevOps, zkušenosti s prací v tomto prostředí a schopnosti vytvářet skripty pro sestavování a nasazování instalačních balíčků ukládaných vývojovým týmem do AZURE Repos.

-       Elastic Certified Engineer nebo Elastic Certified Analyst je požadován pro prokázání schopnosti vytvářet reporty, dashboardy, indexovat a nahrávat data v ElasticSearch i orientace v agentech pro předávání a nahrávání dat do ElasticSearch.

-       HTML5 je požadován pro prokázání znalosti vytváření webových aplikací v poslední verzi jazyka HTML.

-       JavaScript je požadován pro prokázání znalosti vkládání těchto skriptů do HTML kódu webových stránek.

Zadavatel se domnívá, že požadavky na certifikaci členů týmu plně odpovídají složitosti a rozsahu předmětu veřejné zakázky.

K námitce Stěžovatele, že z volně dostupných dokumentů Zadavatele nevyplývá, že by využíval technologii Alfresco, Zadavatel uvádí, že v Stěžovatelem uvedených dokumentech z roku 2019 není tato technologie uvedena, neboť její použití ve VZP ČR bylo schváleno Správní radou až v létě 2020 a dosud žádná aplikace na této technologii nebyla nasazena do produkce.“.

Posouzení věci

129.     Úřad nejdříve v obecné rovině uvádí, že účelem a cílem stanovení kritérií technické kvalifikace je selekce dodavatelů, kteří jsou schopni dodat požadované plnění ve stanovené kvalitě, rozsahu a čase.

130.     Navrhovatel namítá, že kombinace požadovaných znalostí a certifikací pro splnění technické kvalifikace uvedených v čl. 6, bodu 1. a 2. přílohy č. 2 zadávací dokumentace (viz výše bod 123. odůvodnění tohoto rozhodnutí) je nepřiměřeně rozsáhlá a neodpovídá složitosti a rozsahu předmětu veřejné zakázky. Navrhovateli zejména není zřejmé, z jakého důvodu zadavatel požaduje prokázat znalost technologie Alfresco a příslušné certifikace. Ve vztahu k technologii Alfresco navrhovatel v návrhu podotýká, že zadavatel opomíjí existenci srovnatelných systémů, přičemž upozorňuje na možnosti alternativy pro každou část platformy Alfresco. Nemožnost nahrazení konkrétních odkazů v rámci prokazování technické kvalifikace jinými opensource technologiemi považuje navrhovatel za diskriminační.

131.     Jak vyplývá z obsahu výše uvedených odpovědí zadavatele v rámci vysvětlení zadávací dokumentace a rovněž z obsahu rozhodnutí o námitkách (viz body 123. – 128. odůvodnění tohoto rozhodnutí), zadavatel ve vztahu k znalosti technologií či k certifikacím, jež považuje u členů realizačního týmu za stěžejní pro realizaci předmětu plnění, uvedl konkrétní důvody, na jejichž základě příslušné kvalifikační požadavky stanovil. Zadavatel je toho názoru, že požadavky na technické znalosti jsou v souladu s technologiemi a nástroji, které zadavatel používá a na nichž je postaven informační systém zadavatele. Stejně tak je zadavatel přesvědčen o tom, že požadavky na certifikaci členů týmu odpovídají složitosti a rozsahu předmětu plnění veřejné zakázky.

132.     Úřad v prvé řadě upozorňuje na skutečnost, že námitka navrhovatele týkající se nepřiměřenosti předmětných kvalifikačních požadavků je formulována pouze obecně (nepřiměřená rozsáhlost požadavků, které dle jeho názoru neodpovídají složitosti a rozsahu předmětu veřejné zakázky) s tím, že v této souvislosti konkrétně upozorňuje pouze na zadavatelem požadovanou technologii Alfresco. Ve vztahu k ostatním požadavkům zadavatele na znalost technologií, programovacích jazyků a na příslušnou certifikaci navrhovatel pouze obecně deklaruje svůj nesouhlas s touto zadávací podmínkou a shledává příslušné odůvodnění zadavatele za nedostatečné.

133.     Ve vztahu k požadované znalosti technologie Alfresco samotný zadavatel potvrdil, že využití této technologie bylo ve VZP ČR schváleno správní radou v létě roku 2020. Na základě uvedené skutečnosti lze konstatovat, že ještě před zahájením zadávacího řízení na veřejnou zakázku měl zadavatel postaveno na jisto, že ačkoliv předmětná technologie není dosud v prostředí VZP ČR využívána, je oprávněn její používání „pro podporu některých interních procesů“ zahájit a na této technologii „vyvinout řadu malých aplikací“. Důvody nasazení technologie Alfresco zadavatel předestřel např. v rámci „Vysvětlení zadávací dokumentace č. 8 ze dne 27. 1. 2021“ v odpovědi na dotaz č. 2 (viz výše bod 127. odůvodnění tohoto rozhodnutí).

134.     S ohledem na výše uvedené je zjevné, že zadavatel má „dobrý úmysl“ s předmětnou technologií pracovat a využít ji při rozvoji informačního systému VZP ČR (při realizaci prověřované veřejné zakázky). Ačkoliv tedy zadavatel dosud v rámci informačního systému VZP ČR na technologii Alfresco nevyvinul a nenasadil žádnou aplikaci, je v daném případě relevantní požadovat odpovídající kvalifikaci realizačního týmu (tj. znalost technologie Alfresco) pro tyto (teprve plánované) činnosti. Úřad v této souvislosti poznamenává, že v daném případě, kdy předmět plnění veřejné zakázky není zcela přesně vymezen (podle vyjádření zadavatele budou služby vybraného dodavatele poskytovány na základě jednotlivých objednávek, kdy detailní požadavky budou specifikovány zadavatelem po konzultaci s vybraným dodavatelem, a to včetně způsobu poskytování služeb, výstupů služeb, termínů předání výstupu služby a akceptačních kritérií), nelze ani vyloučit situaci, že zadavatel v rámci plnění veřejné zakázky předmětnou technologii Alfresco nevyužije v nyní plánovaném rozsahu nebo vůbec (když např. po konzultaci s vybraným dodavatelem přistoupí k jinému řešení). I v takovém případě by stanovení požadavků na znalosti technologie Alfresco však nebylo nepřiměřené předmětu plnění, neboť dle závěru Krajského soudu v Brně uvedeného v rozsudku č. j. 29 Af 63/2020-213 nelze dle zákona vyloučit možnost navázání kvalifikačních předpokladů na potenciální plnění (tj. plnění, které není zadavatel povinen odebrat, nebo jej odebere až ve vhodném okamžiku). V předmětném rozsudku Krajský soud v Brně mj. konstatoval, že: „(…) za správnost a úplnost zadávacích podmínek je odpovědný zadavatel, což vyplývá z § 36 odst. 3 ZZVZ. Je to také pouze zadavatel, který zná své potřeby, které mají být splněním veřejné zakázky uspokojeny, a jako takový pouze on může vymezit, co má, či nemá být součástí plnění veřejné zakázky. (…) Soud se tedy ztotožňuje s žalovaným, že ZZVZ obecně připouští, aby se kvalifikační kritéria vztahovala k plnění, které není zadavatel povinen odebrat. Zároveň chystá-li se zadavatel pořídit nějaké plnění (uzavřít smlouvu), avšak vyhradil si možnost určité plnění nepožadovat nebo jej požadovat až bude-li to vhodné, nelze takovému jednání automaticky přisuzovat zlou víru, jak tomu v podstatě činí žalobce, a spatřovat v něm snahu o diskriminaci určitých dodavatelů.“. Podle názoru Úřadu lze výše uvedený závěr Krajského soudu v Brně aplikovat na nyní prověřovaný případ, neboť zadavatel sice dosud technologii Alfresco nepoužíval a systém, který hodlá v rámci realizace veřejné zakázky modernizovat, neobsahuje žádné aplikace, které by byly vystavěny na této technologii, avšak právě připravené možnosti (schválení použití technologie Alfresco ve VZP ČR) a jasná deklarace zadavatele technologii Alfresco využít při plnění veřejné zakázky představují zřejmou vůli zadavatele. Úřad podotýká, že navrhovatel nepředložil žádné důkazy či indicie, na základě nichž by bylo možné výše uvedený záměr zadavatele zpochybnit. Současně nelze (s ohledem na výše uvedený závěr Krajského soudu v Brně) ve vztahu k postupu zadavatele „automaticky přisuzovat zlou víru a spatřovat v něm snahu o diskriminaci určitých dodavatelů“.

135.     K argumentaci navrhovatele, podle níž zadavatel opomíjí existenci srovnatelných systémů (alternativ pro každou část platformy Alfresco) Úřad uvádí, že požadavek na znalost konkrétní technologie (v tomto případě Alfresco) v případě, kdy zadavatel využití takové technologie v rámci předmětu plnění plánuje, nepovažuje za nijak excesivní, ale za zcela odpovídající a přiměřený, neboť jak již bylo uvedeno výše, zřejmá vůle zadavatele využít technologii Alfresco při plnění veřejné zakázky nebyla nijak zpochybněna či vyvrácena. Pokud je tedy požadavek na znalost technologie Alfresco odůvodněn předmětem plnění, nelze považovat za jakkoli diskriminační skutečnost, že zadavatel neplánuje využt alternativní technologie (a tedy i příslušné znalosti realizačního týmu). S ohledem na uvedené skutečnosti Úřad shledal požadavek zadavatele na znalosti technologie Alfresco v případě člena realizačního týmu „Integrační architekt“ (viz bod 123. odůvodnění tohoto rozhodnutí) za oprávněný.

136.     Co se týče dalších požadavků zadavatele na znalost technologií, programovacích jazyků a na příslušnou certifikaci realizačního týmu uvedených v čl. 6, bodu 1. a 2. přílohy č. 2 zadávací dokumentace Úřad nesouhlasí s názorem navrhovatele, podle něhož zadavatel dostatečně neodůvodnil vztah těchto požadavků k předmětu plnění, když u některých požadovaných znalostí zadavatel pouze uvedl, že určitý produkt, jazyk či nástroj je užíván v rámci VZP ČR. Pokud jsou totiž podle sdělení zadavatele uvedeného v rozhodnutí o námitkách (viz bod 128. odůvodnění tohoto rozhodnutí) všechny požadavky na technické znalosti členů realizačního týmu v souladu s technologiemi a nástroji, které zadavatel využívá, a na nichž je postaven informační systém zadavatele, je zřejmé, že jsou nutné k jeho dalšímu rozvoji. Z logiky věci pak lze rovněž odkázat na výše uvedené závěry Úřadu formulované ve vztahu k požadavku zadavatele na znalost produktu Alfresco, podle nichž nelze automaticky přisuzovat jednání zadavatele snahu diskriminovat určité dodavatele. Pokud totiž zadavatel při stanovení požadavků na kvalifikaci realizačního týmu vycházel ze skutečnosti, na jakých technologiích je postaven jeho stávající informační systém (Úřad upozorňuje, že navrhovatel konkrétně zpochybnil pouze absenci technologie Alfresco ve stávajícím informačním systému zadavatele) a deklaruje využití těchto technologií při jeho modernizaci, nelze předjímat, že zadavatel záměrně diskriminuje určitý okruh dodavatelů, neboť znalost technologií, jazyků či nástrojů, které jsou využívány ve VZP ČR v současnosti, bude nepochybně možné využít při rozvoji informačního systému VZP ČR. S ohledem na uvedené Úřad dospěl k závěru, že požadavky na technickou kvalifikaci, které mají doložit znalosti technologií a produktů, jež má zadavatel v plánu při modernizaci informačního systému využít, odpovídají předmětu plnění veřejné zakázky a jsou tedy oprávněné.

K požadavku zadavatele na certifikace vydávané společností ElasticSearch

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

137.     V článku 6., odstavci 2., přílohy č. 2 zadávací dokumentace (Podmínky kvalifikace) je mj. uvedeno: „Realizační tým dodavatele pro zajištění služeb vývoje musí sestávat z minimálně 3 odborných pracovníků splňujících níže uvedené požadavky na odbornou kvalifikaci pro každou z níže uvedených oblastí:

a) Specialista Elastic

• minimálně 1 rok praxe v Elastic,
• znalost práce v Azure DevOps, uživatelská znalost Linuxu,
• požadovaná povinná certifikace:

o   Elastic Certified Engineer nebo Elastic Certified Analyst.“.

138.     V rámci „Vysvětlení zadávací dokumentace č. 8 ze dne 27. 1. 2021“ odpověděl zadavatel na dotaz č. 1 ve znění: „Zadávateľ v prílohe č. 2 HDZD – Podmínky kvalifikace v bode 6. Technická kvalifikace na strane 9 požaduje na pozícií Specialista Elastic povinnú certifikáciu Elastic Certified Engineer alebo Elastic Certified Analyst. Žiadame o bližšie vysvetlenie či zadávateľ bude akceptovať ako ekvivalent aj certifikát vydaný Google Cloud prostredníctvom Coursera s názvom Elastic Google Cloud Infrastructure: Scaling and Automation, respektíve certifikát vydaný Google Cloud prostredníctvom Coursera s názvom Architecting with Google Compune Engine, ktorý pozostáva z 5 certifikovaných oblastí: Google Cloud Platform Fundamentals: Core Infrastructure, Essential Google Cloud Infrastructure: Foundation, Essential Google Cloud Infrastructure: Core Services, Elastic Google Cloud Infrastructure: Scaling and Automation, Reliable Google Cloud Infrastructure: Design and Process. Máme za to, že na základe partnerstva spoločnosti Google a Elasticsearch pre platformu ElasticSearch na Google Cloud Platform je vyššie uvedený Google certifikát postačujúcim ekvivalentom zadávateľom požadovaného certifikátu na pozícii Specialista Elastic.“ následovně: „Z obsahu kurzu Elastic Google Cloud Infrastructure: Scaling and Automation (https://www.coursera.org/learn/gcp-infrastructure-scaling-automation) není zřejmé, že by obsahem certifikátu bylo expertní používání produktu ElasticSearch pro analýzu a vizualizaci dat, vytváření dashboardů a další analýza dat tak, jak je uvedeno v popisu kurzů Elastic Certified Engineer / Elastic Certified Analyst. Na základě dostupného popisu obsahu certifikátu Elastic Google Cloud Infrastructure: Scaling and Automation tedy zadavatel neshledal, že by tento certifikát byl ekvivalentní k Elastic Certified Engineer nebo Elastic Certified Analyst.“.

139.     Z obsahu nabídky navrhovatele vyplývá, že v rámci podkladů pro prokázání kvalifikace na předmětnou veřejnou zakázku navrhovatel za účelem prokázání kvalifikace člena realizačního týmu na pozici „Specialista Elastic“ doložil certifikát Elastic Certified Analyst ze dne 28. 1. 2021.

Posouzení věci

140.     Ve vztahu k požadavku zadavatele na doložení certifikátů „Elastic Certified Engineer“ nebo „Elastic Certified Analyst“ pro prokázání kvalifikace člena realizačního týmu dodavatele „Specialista Elastic“ navrhovatel namítá, že zadavatel odmítá bez relevantního důvodu uznat ekvivalentní certifikát Elastic Google Cloud Infrastructure: Scaling and Automation, což navrhovatel shledává jako porušení zásady zákazu diskriminace.

141.     Za účelem posouzení skutečnosti, zda je možné certifikát Elastic Google Cloud Infrastructure: Scaling and Automation uznat jako ekvivalentní k certifikátům požadovaným zadavatelem (Elastic Certified Engineer nebo Elastic Certified Analyst) Úřad oslovil společnost Google Czech Republic, s.r.o. s žádostí o objasnění, zda obsah kurzu pro získání certifikátu Elastic Google Cloud Infrastructure: Scaling and Automation zahrnuje používání produktu ElasticSearch a zda lze tento certifikát považovat za rovnocenný (z pohledu certifikovaných znalostí) k certifikátům Elastic Certified Engineer nebo Elastic Certified Analyst (viz bod 50. odůvodnění tohoto rozhodnutí).

142.     Z obsahu odpovědi společnosti Google Ireland Ltd. (viz bod 58. odůvodnění tohoto rozhodnutí) vyplývá, že kurz „Elastic Google Cloud Infrastructure: Scaling and Automation“, ani jiné kurzy Google Cloud nejsou srovnatelné s obsahem certifikátů „Elastic Certified Engineer“ a „Elastic Certified Analyst“, neboť nejsou zaměřeny na produkty ElasticSearch, přičemž slovo „Elastic“ v názvu uvedeného kurzu („Elastic Google Cloud Infrastructure: Scaling and Automation“) nepředstavuje odkaz na produkt ElasticSearch, nýbrž na elastickou povahu cloudové infrastruktury. Daný kurz Google nemá podle sdělení společnosti Google Ireland Ltd. za cíl poskytnout žádné specializované znalosti o produktech ElasticSearch. S ohledem na uvedené skutečnosti lze tedy konstatovat, že s názorem navrhovatele ohledně ekvivaletnosti předmětného certifikátu ve vztahu k zadavatelem požadovaným certifikátům nelze souhlasit a tedy odpověď zadavatele, podle níž zadavatel ekvivalentnost předmětných certifikátů neshledal, Úřad nepovažuje za projev diskriminace či jakkoliv jinak omezující krok vůči navrhovateli, potažmo vůči jiným dodavatelům, kteří certifikátem „Elastic Google Cloud Infrastructure: Scaling and Automation“ disponují. Na uvedeném nic nemění ani domněnka navrhovatele, podle níž by měl být certifikovaný expert „Elastic Google Cloud Infrastructure: Scaling and Automation“ schopen pracovat s platformou Elastic Search na Google Cloud Platform, neboť jasná deklarace společnosti Google Ireland Ltd. o neporovnatelnosti předmětných certifikátů dává jednoznačnou odpověď na posouzení věci. Právě s ohledem na skutečnost, že společnost Google Ireland Ltd., jakožto zástupce „rodiny Google“, jež je poskytovatelem služby Google Cloud, potvrdil, že daný „kurz Google“ nemá za cíl poskytnout žádné specializované znalosti o produktech ElasticSearch, nepovažoval Úřad za nezbytné oslovit společnost ElasticSearch ani společnost Google Ireland Ltd. za účelem potvrzení či vyvrácení výše uvedené domněnky navrhovatele.

143.     Úřad pro úplnost podotýká, že nepřehlédl, že navrhovatel ve své nabídce doložil certifikát splňující požadavek zadavatele, tj. certifikát Elastic Certified Analyst. S ohledem na uvedenou skutečnost Úřad upozorňuje, že ve vztahu k části návrhu týkající se možné ekvivalentnosti certifikátu Elastic Google Cloud Infrastructure: Scaling and Automation lze pochybovat o prokázání újmy na straně navrhovatele, neboť tento v návrhu upozorňuje na možnou diskriminaci dodavatelů nabízejících jiný certifikát než certifikát požadovaný zadavatelem, ačkoliv on sám požadavek zadavatele splňuje a případným nezákonným jednáním zadavatele by tak nemohl být dotčen, popř. omezen v možnosti úspěšné účasti v zadávacím řízení, potažmo v prokázání kvalifikace člena realizačního týmu na pozici Specialista Elastic.

144.     Ve světle shora uvedených skutečností a v souvislosti se všemi zjištěnými poznatky tudíž Úřad uzavírá, že neshledal důvody pro uložení nápravného opatření, a proto podle § 265 písm. a) zákona rozhodl tak, jak je uvedeno ve výroku 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 má 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

otisk úředního razítka

Mgr. Markéta Dlouhá

místopředsedkyně

Obdrží:

1.             Všeobecná zdravotní pojišťovna České republiky, Orlická 2020/4, 130 00 Praha 3

2.             JUDr. Jan Lukeš, Ph.D., advokát, Hybernská 1007/20, 110 00 Praha 1

Vypraveno dne:

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

---

[1] v revidované verzi – pozn. Úřadu.

[2] v revidované verzi – pozn. Úřadu.