Úřední zdrojee-Sbírka · nsoud.cz · nssoud.cz · nalus.usoud.cz · justice.cz · EUR-Lexdatabáze aktualizována 12. 10. 2026Jak ověřujeme data
Europaius
ROZHODNUTÍ

ÚOHS S0084/2021/VZ – Smlouva o poskytování Integračních zdrojů v rámci IS VZP ČR

ÚOHS · 7. 2. 2022

Čí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í.

O co šlo

Smlouva o poskytování Integračních zdrojů v rámci IS VZP ČR

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.

Číst dál ↓