číslo jednací: 15900/2020/522/JKr
spisová značka: S0140/2020/VZ

Instance I.
Věc Vývoj a implementace eISIR a společných částí
Účastníci
  1. Česká republika – Ministerstvo spravedlnosti
  2. DXC Technology Czech Republic, s. r. o.
Typ správního řízení Veřejná zakázka
Výrok § 257 písm. h) zákona č. 134/2016 Sb.
Rok 2020
Datum nabytí právní moci 24. 8. 2020
Související rozhodnutí 15900/2020/522/JKr
26224/2020/322/HSc
Dokumenty file icon 2020_S0140.pdf 964 KB

 

 

Spisová značka:

 

 

ÚOHS-S0140/2020/VZ

 

 

Číslo jednací:

 

 

ÚOHS-15900/2020/522/JKr

 

                 Brno: 29. května 2020

 

 

 

 

 

Úř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 27. 3. 2020 na návrh ze dne 26. 3. 2020, jehož účastníky jsou

  • zadavatel – Česká republika – Ministerstvo spravedlnosti, IČO 00025429, se sídlem Vyšehradská 427/16, 128 00 Praha – Nové Město,
  • navrhovatel – DXC Technology Czech Republic s.r.o., IČO 05211131, se sídlem Pikrtova 1737/1a, Nusle, 140 00 Praha 4,

ve věci přezkoumání úkonů zadavatele učiněných při zadávání veřejné zakázky „Vývoj a implementace eISIR a společných částí“ v řízení se soutěžním dialogem, jehož oznámení bylo odesláno k uveřejnění dne 31. 1. 2020 a uveřejněno ve Věstníku veřejných zakázek dne 3. 2. 2020 pod ev. č. Z2020-004646, ve znění oprav uveřejněných dne 6. 2. 2020 a dne 14. 2. 2020, a v Úředním věstníku Evropské unie dne 5. 2. 2020 pod ev. č. 2020/S 025-056870, ve znění opravy uveřejněné dne 14. 2. 2020 pod ev. č. 2020/S 032-075877,

 

rozhodl takto:

 

I.

Správní řízení vedené ve věci návrhu navrhovatele – DXC Technology Czech Republic s.r.o., IČO 05211131, se sídlem Pikrtova 1737/1a, Nusle, 140 00 Praha 4 – ze dne 26. 3. 2020 na zahájení správního řízení o přezkoumání úkonů zadavatele – Česká republika – Ministerstvo spravedlnosti, IČO 00025429, se sídlem Vyšehradská 427/16, 128 00 Praha – Nové Město – učiněných při zadávání veřejné zakázky „Vývoj a implementace eISIR a společných částí“ v řízení se soutěžním dialogem, jehož oznámení bylo odesláno k uveřejnění dne 31. 1. 2020 a uveřejněno ve Věstníku veřejných zakázek dne 3. 2. 2020 pod ev. č. Z2020-004646, ve znění oprav uveřejněných dne 6. 2. 2020 a dne 14. 2. 2020, a v Úředním věstníku Evropské unie dne 5. 2. 2020 pod ev. č. 2020/S 025-056870, ve znění opravy uveřejněné dne 14. 2. 2020 pod ev. č. 2020/S 032-075877, se v části týkající se tvrzené nezákonnosti požadavku zadavatele na složení realizačního týmu (techniky, kteří se budou podílet na plnění veřejné zakázky), který zadavatel stanovil v čl. 2.5.2 „Technická kvalifikace dle § 79 odst. 2 písm. c) a d) ZZVZ“ přílohy č. 4 „Kvalifikační dokumentace“ zadávací dokumentace ze dne 31. 1. 2020 v rámci požadavků na prokázání splnění kritéria technické kvalifikace dle § 79 odst. 2 písm. c) a d) zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, podle § 257 písm. h) cit. zákona zastavuje, neboť návrhuv této části nepředcházely řádně a včas podané námitky.

 

II.

Návrh navrhovatele – DXC Technology Czech Republic s.r.o., IČO 05211131, se sídlem Pikrtova 1737/1a, Nusle, 140 00 Praha 4 – ze dne 26. 3. 2020na zahájení správního řízení o přezkoumání úkonů zadavatele – Česká republika – Ministerstvo spravedlnosti, IČO 00025429, se sídlem Vyšehradská 427/16, 128 00 Praha – Nové Město – učiněných při zadávání veřejné zakázky „Vývoj a implementace eISIR a společných částí“ v řízení se soutěžním dialogem, jehož oznámení bylo odesláno k uveřejnění dne 31. 1. 2020 a uveřejněno ve Věstníku veřejných zakázek dne 3. 2. 2020 pod ev. č. Z2020-004646, ve znění oprav uveřejněných dne 6. 2. 2020 a dne 14. 2. 2020, a v Úředním věstníku Evropské unie dne 5. 2. 2020 pod ev. č. 2020/S 025-056870, ve znění opravy uveřejněné dne 14. 2. 2020 pod ev. č. 2020/S 032-075877, se v části týkající se tvrzené nezákonnosti požadavků zadavatele na reference účasti na projektu obdobné velikosti a zaměření v případě členů realizačního týmu (techniků, kteří se budou podílet na plnění veřejné zakázky) na pozici:

  • hlavní architekt (požadavek „reference účasti na min. dvou projektech obdobné velikosti a zaměření v roli hlavního architekta“),
  • databázový specialista (požadavek „reference účasti na projektu obdobné velikosti a zaměření v roli databázového specialisty“),
  • specialista UI/UIX (požadavek „reference účasti na projektu obdobné velikosti a zaměření v roli UI/UIX specialisty“),

které zadavatel stanovil v čl. 2.5.2 „Technická kvalifikace dle § 79 odst. 2 písm. c) a d) ZZVZ“ přílohy č. 4 „Kvalifikační dokumentace“ zadávací dokumentace ze dne 31. 1. 2020 v rámcipožadavků na prokázání splnění kritéria technické kvalifikace dle § 79 odst. 2 písm. d) zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, podle § 265 písm. a) cit. zákona zamítá, neboť nebyly zjištěny důvody pro uložení nápravného opatření.

 

III.

Návrh navrhovatele – DXC Technology Czech Republic s.r.o., IČO 05211131, se sídlem Pikrtova 1737/1a, Nusle, 140 00 Praha 4 – ze dne 26. 3. 2020 na zahájení správního řízení o přezkoumání úkonů zadavatele – Česká republika – Ministerstvo spravedlnosti, IČO 00025429, se sídlem Vyšehradská 427/16, 128 00 Praha – Nové Město – učiněných při zadávání veřejné zakázky „Vývoj a implementace eISIR a společných částí“ v řízení se soutěžním dialogem, jehož oznámení bylo odesláno k uveřejnění dne 31. 1. 2020 a uveřejněno ve Věstníku veřejných zakázek dne 3. 2. 2020 pod ev. č. Z2020-004646, ve znění oprav uveřejněných dne 6. 2. 2020 a dne 14. 2. 2020, a v Úředním věstníku Evropské unie dne 5. 2. 2020 pod ev. č. 2020/S 025-056870, ve znění opravy uveřejněné dne 14. 2. 2020 pod ev. č. 2020/S 032-075877, se v části týkající se postupu zadavatele při poskytnutí části zadávací dokumentace – obrázku 1 „Schéma předpokládané aplikační architektury projektu“ v kapitole 5.1 „Předpokládaná aplikační architektura Systému eISIR“ přílohy č. 2 „Projektový záměr“ zadávací dokumentace ze dne 31. 1. 2020 dodavatelům, konkrétně údajně nedostatečné doby poskytnutí tohoto obrázku v čitelné podobě, resp. neprodloužení lhůty pro podání žádostí o účast v návaznosti na poskytnutí tohoto obrázku dodavatelům s vysvětlením zadávací dokumentace č. 2 ze dne 19. 2. 2020, podle § 265 písm. a) zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, zamítá, neboť nebyly zjištěny důvody pro uložení nápravného opatření.

 


Odůvodnění

 

I.              ZADÁVACÍ ŘÍZENÍ

1.             Zadavatel – Česká republika – Ministerstvo spravedlnosti, IČO 00025429, se sídlem Vyšehradská 427/16, 128 00 Praha – Nové Město (dále jen „zadavatel“) – jako veřejný zadavatel podle § 4 odst. 1 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ů (dále jen „zákon“ nebo „ZZVZ“)[1], zahájil  dne 31. 1. 2020 ve  smyslu § 68 odst. 2 zákona odesláním oznámení o zahájení zadávacího řízení k uveřejnění řízení se soutěžním dialogem za účelem zadání veřejné zakázky „Vývoj a implementace eISIR a společných částí“. Oznámení o zahájení zadávacího řízení bylo uveřejněno ve Věstníku veřejných zakázek dne 3. 2. 2020 pod ev. č. Z2020-004646, ve znění oprav uveřejněných dne 3. 2. 2020 a dne 14. 2. 2020, a v Úředním věstníku Evropské unie dne 5. 2. 2020 pod ev. č. 2020/S 025-056870, ve znění opravy uveřejněné dne 14. 2. 2020 pod ev. č. 2020/S 032-075877 (dále jen „veřejná zakázka“ nebo „zadávací řízení“).

2.             V příloze č. 2 „Projektový záměrzadávací dokumentace ze dne 31. 1. 2020 (dále jen „zadávací dokumentace“ a „projektový záměr“ či „příloha č. 2 zadávací dokumentace“),konkrétně v kapitole 1»Předmět veřejné zakázky „Vývoj a implementace eISIR a společných částí« je předmět veřejné zakázky vymezen jako: »návrh, implementace, nasazení a provoz:

            - elektronického insolvenčního rejstříku eISIR,

            - sdílených služeb pro práci s dokumenty eSPIS,

            - nového systému spisové služby splňujícího národní standard,

            - dalších sdílených podpůrných služeb a aplikací zahrnujících Registr jmen, Číselníky, Rozvrh     práce a Centrální tvorbu dokumentů (centrální sdílené aplikace, dále též souhrnně      označovány jako „Centrum justice“),

            (dále souhrnně označováno „Systém eISIR“).«

3.             Z formuláře Oznámení o zahájení zadávacího řízení uveřejněného ve Věstníku veřejných zakázek dne 3. 2. 2020 plyne, že zadavatel stanovil lhůtu pro podání žádostí o účast do 2. 3. 2020, 10:00 hod.

4.             Zadavatel vysvětlením zadávací dokumentace č. 1 ze dne 11. 2. 2020, které bylo uveřejněno na profilu zadavatele[2] téhož dne, prodloužil lhůtu pro podání žádostí o účast do 3. 3. 2020, 10:00 hod.[3]     

5.             Zadavatel dne 3. 3. 2018 v 8:58 hod. obdržel prostřednictvím elektronického nástroje od navrhovatele – DXC Technology Czech Republic s.r.o., IČO 05211131, se sídlem Pikrtova 1737/1a, Nusle, 140 00 Praha 4 (dále jen „navrhovatel“) – „Námitku proti zadávací dokumentaci“ z téhož dne (dále jen „námitky“ nebo „námitky ze dne 3. 3. 2020“).

6.             Zadavatel o námitkách navrhovatele rozhodl dne 17. 3. 2020 tak, že je jako nedůvodné odmítl (dále jen „rozhodnutí o námitkách“).

7.             Navrhovatel se s rozhodnutím o námitkách neztotožnil, a proto podal dne 27. 3. 2020 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 ze dne 26. 3. 2020 (dále jen „návrh“).

II.           OBSAH NÁVRHU

8.             Navrhovatel spatřuje porušení zákona ve stanovení některých požadavků na prokázání technické kvalifikace podle § 79 odst. 2 písm. c) a d) zákona, neboť tyto považuje za excesivní a diskriminační vzhledem k současnému vymezení předmětu veřejné zakázky a vzhledem k tomu, že tento předmět je ve fázi podávání žádostí o účast v soutěžním dialogu vymezen pouze předběžně. Dle navrhovatele ze současné zadávací dokumentace nelze dovozovat konkrétní požadavky na složení realizačního týmu a zkušenosti jeho členů. Stanovené požadavky dle navrhovatele bezdůvodně vylučují dodavatele, kteří by jinak mohli podat žádost o účast v zadávacím řízení. Navrhovatel v návrhu uvádí, že „[z]e současně dostupné Zadávací dokumentace ani z Projektového záměru nelze dovodit ani zjistit, zda realizační tým musí mít právě složení takových odborníků a s takovou kvalifikací, jak vyžaduje zadavatel, a zda takové požadavky zadavatele na technickou kvalifikaci nejsou s ohledem na předmět veřejné zakázky diskriminační.“

9.             Pokud jde o požadavky na seznam techniků, kteří se budou podílet na plnění veřejné zakázky, tj. o požadavky na složení realizačního týmu, navrhovatel nijak nekonkretizuje, jaký konkrétní požadavek považuje za nezákonný.

10.         Pokud jde o požadavky na odbornou kvalifikaci – zkušenosti členů realizačního týmu, navrhovatel v případě některých členů týmu považuje za nepřiměřený požadavek na prokázání jejich odborné kvalifikace, konkrétně požadavek na referenci/reference účasti na projektu „obdobné velikosti“, tj. „projektu obdobné velikosti a zaměření“ jak je vymezen v příloze č. 4 „Kvalifikační dokumentace“ zadávací dokumentace (dále jen „kvalifikační dokumentace“ či „příloha č. 4 zadávací dokumentace“). Navrhovatel v této souvislosti uvádí tyto pozice členů v realizačním týmu:

            - hlavní architekt, kdy zadavatel u této pozice stanovil požadavek „reference účasti na min.      dvou projektech obdobné velikosti a zaměření v roli hlavního architekta“,

            - databázový specialista, kdy zadavatel u této pozice stanovil požadavek „reference účasti        na projektu obdobné velikosti a zaměření v roli databázového specialisty“ a

            - specialista UI/UIX, kdy zadavatel u této pozice stanovil požadavek „reference účasti na           projektu obdobné velikosti a zaměření v roli UI/UIX specialisty“.

11.         K pozici hlavního architekta navrhovatel uvádí, že u této pozice „požaduje zadavatel dokonce účast na dvou obdobných zakázkách, což je požadavek už při současné vědomosti o budoucím předmětu veřejné zakázky zjevně excesivní, protože nevede k ověření schopnosti účastníka zpracovat nabídku a realizovat veřejnou zakázku.“

12.         K pozici databázového specialisty a pozici „specialisty UI/UX“ navrhovatel uvádí, že „je odkaz na referenci účasti na projektu obdobné velikosti a zaměření pro danou roli diskriminační a zcela nelogická, neboť tyto role může efektivně na projektu zastávat jakákoliv osoba s uvedenou kvalifikací. Jedná se totiž o obecnou roli, u níž není kvalita jejího výkonu podmíněna tím, že se tento člen realizačního týmu podílel na realizaci jiné obdobné zakázky, neboť úkoly, které tyto osoby vykonávají, jsou obdobné bez ohledu na velikost realizované zakázky.“

13.         Navrhovatel také poukazuje (v souvislosti s namítanými skutečnostmi) na to, že veškeré požadavky zadavatele uvedené v zadávací dokumentaci v části technické kvalifikace musí být navíc splněny současně.

14.         Dále navrhovatel spatřuje porušení zákona v tom, že zadavatel v zadávací dokumentaci poskytl obrázek „Schéma předpokládané aplikační architektury projektu“ v nečitelné podobě a následně poskytl tento obrázek v čitelné podobě, avšak neprodloužil současně lhůtu pro podání žádostí o účast. Podle navrhovatele zadavatel tímto postupem zkrátil dodavatelům lhůtu pro posouzení zadávací dokumentace, čímž nepřiměřeným způsobem omezil možný okruh dodavatelů, resp. množství dodavatelů, kteří by jinak mohli podat žádost o účast.  

15.         Navrhovatel navrhuje, aby Úřad zadávací řízení zrušil.

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

16.         Dnem 27. 3. 2020, kdy Úřad Návrh obdržel, bylo podle § 249 zákona ve spojení s § 44 odst. 1 zákona č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů (dále jen „správní řád“), zahájeno správní řízení o přezkoumání úkonů zadavatele.

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

  • zadavatel,
  • navrhovatel.

18.         Zahájení správního řízení oznámil Úřad jeho účastníkům přípisem č. j. ÚOHS-09783/2020/522/PKř ze dne 31. 3. 2020.

19.         Dne 6. 4. 2020 Úřad obdržel vyjádření zadavatele k návrhu z téhož dne (dále jen „vyjádření zadavatele“). Ve dnech 6. 4. 2020 a 7. 4. 2020 pak Úřad obdržel dokumentaci o zadávacím řízení.   

Vyjádření zadavatele

20.         Zadavatel ve vyjádření k námitce týkající se údajným excesivním kvalifikačním požadavkům uvádí, že má za to, že postupoval v souladu se zákonem. Zadavatel dále odkazuje na obsah rozhodnutí o námitkách (jeho obsah je proto v tomto popisu obsahu vyjádření zadavatele k návrhu zohledněn).

21.         Zadavatel upozorňuje na to, že předmětná veřejná zakázka je zadávána v řízení se soutěžním dialogem, a zadavatel tak nemá možnost ověřit splnění kvalifikačních kritérií později v průběhu zadávacího řízení.

22.         Podle zadavatele je stávající obsah zadávací dokumentace, zejména projektového záměru, dostatečný pro stanovení kvalifikačních požadavků na potenciální účastníky soutěžního dialogu.

23.         Kvalifikační požadavky na realizační tým a požadované role jsou dle zadavatele přiměřené a zcela legitimní vzhledem k předmětu plnění a odpovídají předpokládané náročnosti a rozsahu předmětu plnění, který vyplývá zejména z projektového záměru. Jedná se o požadavky, které jsou běžné v zakázkách a projektech s obdobnou náročností a s obdobným rozsahem. Dle zadavatele je tak nelze vnímat jako nedůvodné nebo diskriminační. Zadavatel dle svého vyjádření stanovil kvalifikační požadavky s ohledem na finální cíl zadávacího řízení. Dodává, že kvalifikační kritéria stanovil spíše nižší a že požadavky na „projekt obdobné velikosti a zaměření“ představují pouze minimum toho, co zadavatel ví, že bude předmětem veřejné zakázky, resp. co očekává při realizaci veřejné zakázky. V této souvislosti poukazuje na požadovaný počet pravidelně přistupujících uživatelů či počtu spravovaných dokumentů.

24.         Co se týče rozsahu informačního systému, který je předmětem řešené veřejné zakázky, a legislativních požadavků na tento systém a jeho provoz odůvodňujících nastavení kvalifikačních podmínek, zadavatel ve svém vyjádření shrnuje, že „poptávaný informační systém bude obsahovat řadu podsystémů a komponent jako například eSPIS, elSIR, Registr jmen atd., kromě toho se předpokládá flexibilní možnost napojení dalších nadstavbových justičních aplikací a možnost znovupoužití implementovaných komponent, což předpokládá mj. maximální kompatibilitu se stávající architekturou informačních systémů justice a koncepční a flexibilní návrh architektury poptávaného řešení. Předpokládaný počet spravovaných dokumentů může dosahovat až cca 10 mil. a počet unikátních uživatelů, mimo uživatelů z řad veřejnosti, může být až 2 800 (pro část insolvenční agendy). Z legislativního pohledu bude na daný informační systém veřejné správy dopadat zákon o kybernetické bezpečnosti (bude se jednat o kritickou informační infrastrukturu), zákon o informačních systémech veřejné správy či zákon o archivnictví a spisové službě, zákon o přístupnosti internetových stránek a mobilních aplikací, potažmo další normy a standardy nezákonného charakteru. Výše zmíněné předpisy kladou na informační systém nemalé nároky stran bezpečnosti, funkčnosti, dostupnosti a v neposlední řadě uživatelské přívětivosti (UX). Předpokládaná cena pouze za vývoj tohoto informačního systému (tedy bez podpory a servisu) je dle čl. 4.6 zadávací dokumentace přes 158 mil. Kč (bez DPH).“Uvedené parametry informačního systému jsou pak dle zadavatele již nyní zřejmé ze zadávací dokumentace, zejména pak z projektového záměru.

25.         V rozhodnutí o námitkách navrhovatele zadavatel uvádí, že předmětem plnění veřejné zakázky „bude robustní sofistikovaný informační systémem veřejné správy, který bude obsahovat řadu podsystémů, jako například eSPIS, eISIR, Registr jmen, Číselníky, Rozvrh práce a tak dále (viz čl. 1 projektového záměru), na což navazují součásti dodávky jako je integrace aplikací, migrace dat či rozvojové služby (v podrobnostech viz čl. 2 Projektového záměru). Nad rámec uvedeného půjde o informační systém veřejné správy, který bude muset plnit požadavky řady předpisů, norem a standardů, namátkou lze uvést zákon o kybernetické bezpečnosti, zákon o informačních systémech veřejné správy nebo zákon o archivnictví a spisové službě, v podrobnostech viz čl. 4 projektového záměru.

Z pohledu zadavatele je tedy požadavek na předložení reference o účasti na projektu obdobné velikosti u jednotlivých členů realizačního týmu zcela důvodný, ospravedlnitelný a objektivně nezbytný. Poptávaný systém bude základnou pro následnou postupnou digitalizaci celého resortu justice. Pro zadavatele je velmi důležité mít efektivně a flexibilně postavenou architekturu řešení, která v budoucnu umožní napojení dalších nadstavbových justičních aplikací. Zároveň musí být dodávaný systém co nejvíce kompatibilní se stávající již existující architekturou justice. Z výše uvedených důvodů je klíčová zejména role architekta a je proto u ní zcela oprávněně předpokládána vysoká míra zkušeností. To se odrazilo v oprávněném požadavku na účast hlavního architekta minimálně ve dvou projektech obdobné velikosti. Příliš benevolentní kvalifikační kritéria ve vztahu k potenciálním účastníkům zadávacího řízení by znamenala připuštění účasti dodavatelů, kteří s projekty obdobné velikosti nemají žádné zkušenosti, což by v důsledku mohlo ohrozit plnění řešené veřejné zakázky. Požadavek účasti na projektu obdobné velikosti v příslušné roli nesouvisí pouze se samotnou náplní práce daného člena realizačního týmu, ale také se schopností koordinovat svou činnost v rámci takto rozsáhlého projektu s ostatními členy realizačního týmu a orientovat se napříč celým projektem tak, aby bylo možné fungování realizačního týmu jako celku. Proto je zcela legitimní požadovat účast na projektu obdobné velikosti u všech pozic realizačního týmu včetně pozic UI/UIX specialisty a databázového speciality. V této rovině je zcela legitimní a přiměřený i kvalifikační požadavek účasti na dvou projektech obdobné velikosti u hlavního architekta celého výsledného systému. V tomto směru tak nelze dát stěžovateli za pravdu, že by kvalifikační podmínky byly jakkoli diskriminační či nepřiměřené, a tedy v rozporu s § 6 odst. 1 nebo 2 ZZVZ.“

26.         Z výše uvedených důvodů považuje zadavatel dle svého vyjádření za klíčovou zejména roli architekta, a proto je u ní předpokládána vysoká míra zkušeností, což se projevilo v požadavku na účast hlavního architekta minimálně ve dvou projektech obdobné velikosti.

27.         Požadavek účasti člena realizačního týmu na „projektu obdobné velikosti a zaměření“ v příslušné roli podle zadavatele navíc nesouvisí pouze se samotnou náplní práce daného člena realizačního týmu, ale také se schopností koordinovat svou činnost v rámci rozsáhlého projektu s ostatními členy realizačního týmu a orientovat se napříč celým projektem tak, aby bylo možné zajistit a garantovat fungování realizačního týmu jako celku. Proto je dle zadavatele legitimní požadovat účast na projektu obdobné velikosti u všech pozic realizačního týmu včetně pozic UI/UIX specialisty a databázového speciality.

28.         Zadavatel dále uvádí, že minimální požadovaný počet 400 000 spravovaných dokumentů, který zadavatel stanovil pro „projekt obdobné velikosti a zaměření“, zdaleka nedosahuje reálného budoucího stavu počtu dokumentů v systému, který se dle projektového záměru předpokládá v rozsahu cca 10 mil. dokumentů. Předmětný požadavek dle zadavatele ověří, že dodavatel byl schopen implementovat systém pro správu dokumentů alespoň tohoto rozsahu. Rovněž požadavek na minimální měsíční počet 300 pravidelně přistupujících unikátních uživatelů, který zadavatel stanovil pro „projekt obdobné velikosti a zaměření“, představuje počet, u kterého je zadavatel přesvědčen, že dodavatel s touto zkušeností dokáže efektivně pracovat s požadavky jak na dostupnost systému, tak s řízením požadavků na systém jako takových. Zadavatel dodává, že dle projektového záměru se předpokládá přístup v rozsahu cca 2 800 unikátních uživatelů. Proto i požadavek na roli specialista UI/UIX s odpovídající zkušeností považuje zadavatel za přiměřený, neboť s ohledem na přijetí zákona č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací, jsou na uživatelskou přívětivost veškerých informačních systémů veřejné správy kladeny větší nároky. V rámci plnění bude dle zadavatele implementováno mnoho komponent, s kterými budou pracovat přímo interní i externí uživatelé, a proto je nutné mít na straně dodavatele v projektovém týmu tohoto specialistu s odpovídající zkušeností.

29.         Zadavatel dále ve vyjádření k návrhu uvádí, že v obecné rovině nerozporuje, že je teoreticky možné, aby danou roli splnila i osoba, která s projektem obdobné velikosti a zaměření nemá zkušenosti, nicméně zapojení takové osoby do realizačního týmu na klíčových pozicích je rizikem, které zadavatel není povinen ani ochoten akceptovat.

30.         Zadavatel se ve vyjádření k návrhu zvlášť ve vztahu ke všem jednotlivým pozicím/rolím v realizačním týmu podrobněji vyjadřuje k důvodům stanovení sporných kvalifikačních požadavků.

31.         Pokud jde o pozici hlavního architekta, zadavatel uvádí: „Důležitost této role v souvislosti s požadavky na architekturu vznikajícího systému byla zdůrazněna již v rozhodnutí o námitkách. Pro zadavatele je hlavní architekt projektu zcela stěžejní rolí vzhledem k zamýšlenému rozsahu systému, proto zadavatel požaduje tuto roli a považuje požadavek na zkušenost ze dvou projektů obdobné velikosti a zaměření za logický a zcela přiměřený, odpovídající právě důležitostí této klíčové role pro plnění předmětu veřejné zakázky.“

32.         Pokud jde o pozici databázového specialisty, zadavatel uvádí: „Součásti poptávaného řešení má být i databáze, proto jsou správná implementace poptávaného systému v rámci databázového řešení systému a provedení migrace dat ze stávajícího systému do nového systému jedny z nedůležitějších kroků projektu jako takového, a činností této role. Opět se tak jedná o zcela přiměřený požadavek účasti databázového specialisty se zkušenostmi z projektu obdobného charakteru.“

33.         Pokud jde o pozici specialisty UI/UIX, zadavatel uvádí: „Pro informační systémy veřejné správy platí specifické zákonné požadavky pro tzv. front-end, řešící přístupnost (blíže viz čl. 10 Projektového záměru), konkrétně jde o požadavky dle zákona o ISVS a zákona o přístupnosti internetových stránek a mobilních aplikací. Vzhledem k legislativním požadavkům na UI/UIX řešeného ISVS a k jeho rozsahu (veřejnou a neveřejnou část či počtu unikátních uživatelů) je zadavatel opět toho názoru, že požadavek na obsazení této role v projektu a příslušné zkušenosti z projektu obdobné velikosti a zaměření jsou zcela legitimní a přiměřené.“

34.         Pokud jde o námitku týkající se požadavků zadavatele na složení realizačního týmu, zadavatel se zvlášť k této námitce ve svém vyjádření téměř nevyjadřuje, uvádí pouze, že „[d]efinované pozice jsou tak prakticky jen základní, obvyklé role členů realizačního týmu v obdobných projektech.“ Bez požadovaných rolí by dle zadavatele nebylo možné realizovat projekt v předpokládaném čase a zejména kvalitě.

35.         K námitce týkající se zkrácení lhůty pro seznámení se se „Schématem předpokládané aplikační architektury projektu“ v zadávací dokumentaci uvádí, že schéma bylo dostatečně slovně popsáno v kapitole 5 projektového záměru a dodatečně doplněno v čitelné podobě. Zadavatel uvádí, že schéma je ilustrativní a doplňující. Zadavatel poukazuje na to, že již v projektovém záměru uvedl, že se jedná o předpokládanou aplikační architekturu a že se nejedná o konečný návrh, a tedy, že diagram má sloužit výhradně pro jednodušší orientaci dodavatele v řešené problematice. Zadavatel zdůrazňuje, že „nízký význam schématu pro zvážení účasti (tedy jeho nezávazný a ilustrativní charakter) byl zjevný od počátku, i při dílčí nečitelnosti některých položek.“ Zadavatel proto odmítá názor navrhovatele, že nejistota ohledně obsahu nečitelných částí schématu mohla odradit některé dodavatele od přípravy žádosti o účast. Tuto spekulaci považuje zadavatel za odtrženou od reality.

36.         Podle zadavatele nemohlo dodatečné poskytnutí čitelného schématu jakkoli ovlivnit možnost dodavatelů zúčastnit se zadávacího řízení. Případné prodloužení lhůty pro podání žádostí o účast za účelem seznámení se s tímto schématem považuje zadavatel za zcela zbytečné a neefektivní řešení, které by vedlo pouze ke zbytečným průtahům zadávacího řízení.

37.         Zadavatel uvádí, že v souladu s § 99 odst. 2 zákona posoudil povahu úpravy zadávací dokumentace a dospěl k závěru, že tato úprava je nepodstatná a její povaha nevyžaduje prodloužení lhůty pro podání žádostí o účast.

38.         Zadavatel navrhuje, aby Úřad návrh dle § 265 písm. a) zákona zamítl. 

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

39.         Usnesením č. j. ÚOHS-10993/2020/522/JKr ze dne 16. 4. 2020 určil Úřad zadavateli lhůtu k podání informace o dalších úkonech, které provede v šetřeném zadávacím řízení v průběhu správního řízení a zaslání příslušné dokumentace o zadávacím řízení pořízené v souvislosti s provedenými úkony.

40.         V návaznosti na další úkony provedené v zadávacím řízení doručil zadavatel Úřadu dne 28. 4. 2020 další dokumenty, které považuje za součást dokumentace o zadávacím řízení na veřejnou zakázku.

41.         Dne 28. 4. 2020 Úřad obdržel podání zadavatele z téhož dne, ve kterém zadavatel požádal o zaslání obsahu správního spisu.  Dne 5. 5. 2020 Úřad obdržel podání zadavatele, ve kterém zadavatel doplnil svoji žádost o zaslání obsahu správního spisu ze dne 28. 4. 2020 a vyjádřil se k oprávnění náměstka ministra spravedlnosti pro řízení sekce provozní a právní při jednání za zadavatele.

42.         Dne 6. 5. 2020 Úřad umožnil zadavateli nahlédnout do správního spisu formou zaslání obsahu spisu do datové schránky zadavatele, přičemž Úřad dodává, že takovýto postup byl zvolen s ohledem k omezení provozu pro veřejnost v době nouzového stavu.

43.         Rozhodnutím č. j. ÚOHS-13646/2020/522/JKr ze dne 7. 5. 2020 Úřad z moci úřední nařídil podle § 61 odst. 1 správního řádu předběžné opatření, kterým zadavateli uložil zákaz uzavřít smlouvu v zadávacím řízení na veřejnou zakázku.

44.         V návaznosti na další úkony provedené v zadávacím řízení doručil zadavatel Úřadu dne 15. 5. 2020 další dokumenty, které považuje za součást dokumentace o zadávacím řízení na veřejnou zakázku.

45.         Dne 15. 5. 2020 Úřad obdržel podání zadavatele ze dne 14. 5. 2020, ve kterém zadavatel doplnil svoje vyjádření k návrhu. Zadavatel na podporu názoru, že stanovené požadavky na kvalifikaci nejsou excesivní ani diskriminační, uvádí, že na základě provedeného posouzení splnění podmínek účasti zadavatel zjistil, že všichni čtyři žadatelé o účast podmínky účasti v zadávacím řízení splňují. Účast takového množství dodavatelů na takto náročnou a složitou veřejnou zakázku je dle zadavatele velmi uspokojivá a spíše výjimečná. Stanovené požadavky na kvalifikaci tak dle názoru zadavatele umožnily zachování účinné hospodářské soutěže.

46.         Usnesením č. j. ÚOHS-13209/2020/522/JKr ze dne 20. 5. 2020 Úřad určil účastníkům správního řízení lhůtu, ve které se mohli vyjádřit k podkladům rozhodnutí.

47.         Dne 21. 5. 2020 umožnil Úřad navrhovateli nahlédnout do správního spisu vedeného pod sp. zn. S0140/2020/VZ.

48.         Zadavatel a navrhovatel se ve stanovené lhůtě ani později v průběhu správního řízení již dále nevyjádřili.

IV.         ZÁVĚRY ÚŘADU

49.         Úř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ů pro rozhodnutí, zejména relevantních částí obdržené dokumentace o zadávacím řízení a vyjádření účastníků řízení konstatuje, že vyjma části návrhu týkající se tvrzené nezákonnosti požadavku zadavatele na složení realizačního týmu (techniky, kteří se budou podílet na plnění veřejné zakázky), který zadavatel stanovil v čl. 2.5.2 „Technická kvalifikace dle § 79 odst. 2 písm. c) a d) ZZVZ“ kvalifikační dokumentace v rámci požadavků na prokázání splnění kritéria technické kvalifikace dle § 79 odst. 2 písm. c) a d) zákona, nebyly zjištěny důvody pro uložení nápravného opatření, a proto rozhodl podle § 265 písm. a) zákona o zamítnutí návrhu. V části týkající se tvrzené nezákonnosti požadavku zadavatele na složení realizačního týmu pak Úřad správní řízení zastavil podle § 257 písm. h) zákona (neboť této části návrhu nepřecházely řádně a včas podané námitky). K tomu Úřad uvádí následující rozhodné skutečnosti.

Relevantní ustanovení zákona

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

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

52.         Podle § 28 odst. 1 písm. a) zákona se pro účely tohoto zákona rozumí zadávacími podmínkami veškeré zadavatelem stanovené

            1. podmínky průběhu zadávacího řízení,

            2. podmínky účasti v zadávacím řízení,

            3. pravidla pro snížení počtu účastníků zadávacího řízení nebo snížení počtu předběžných         nabídek nebo řešení,

            4. pravidla pro hodnocení nabídek,

            5. další podmínky pro uzavření smlouvy na veřejnou zakázku podle § 104 zákona.

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

54.         Podle § 28 odst. 1 písm. c) zákona se pro účely tohoto zákona rozumí kvalifikací způsobilost a schopnost dodavatele plnit veřejnou zakázku.

55.         Podle § 28 odst. 1 písm. d) zákona se pro účely tohoto zákona rozumí žádostí o účast údaje nebo doklady prokazující kvalifikaci dodavatele, které dodavatel podal písemně zadavateli na základě zadávací dokumentace.

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

57.         Podle § 36 odst. 2 zákona zadávací podmínky zadavatel uvede v zadávací dokumentaci nebo je sdělí účastníkům zadávacího řízení při jednání.

58.         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í. Zadavatel nesmí přenášet odpovědnost za správnost a úplnost zadávacích podmínek na dodavatele.

59.         Podle § 37 odst. 1 zákona podmínky účasti v zadávacím řízení může zadavatel stanovit jako

            a) podmínky kvalifikace,

            b) technické podmínky vymezující předmět veřejné zakázky včetně podmínek nakládání             s právy k průmyslovému nebo duševnímu vlastnictví vzniklými v souvislosti s plněním    smlouvy na veřejnou zakázku,

            c) obchodní nebo jiné smluvní podmínky vztahující se k předmětu veřejné zakázky, nebo

            d) zvláštní podmínky plnění veřejné zakázky, a to zejména v oblasti vlivu předmětu veřejné      zakázky na životní prostředí, sociálních důsledků vyplývajících z předmětu veřejné zakázky,             hospodářské oblasti nebo inovací.

60.         Podle § 68 odst. 2 zákona zadavatel zahajuje řízení se soutěžním dialogem odesláním oznámení o zahájení zadávacího řízení k uveřejnění způsobem podle § 212 zákona, kterým vyzývá neomezený počet dodavatelů k podání žádosti o účast.

61.         Podle § 68 odst. 3 zákona zadavatel stanoví lhůtu pro podání žádostí o účast na nejméně 30 dnů od zahájení zadávacího řízení. Tato lhůta musí být prodloužena o 5 dnů, jestliže zadavatel neumožní podávat nabídky prostřednictvím elektronického nástroje. Zadavatel  v zadávací dokumentaci stanoví předpokládaný časový rozvrh soutěžního dialogu.

62.         Podle § 68 odst. 4 zákona zadavatel posoudí soulad žádosti o účast se zadávacími podmínkami a provede snížení počtu účastníků zadávacího řízení podle § 111 zákona, pokud si tak vyhradil v oznámení o zahájení zadávacího řízení. Zadavatel vyloučí z účasti v zadávacím řízení účastníky, jejichž žádost o účast nesplňuje zadávací podmínky nebo nebyli vybráni při snížení počtu účastníků zadávacího řízení. Nevyloučené účastníky zadávacího řízení vyzve k účasti v soutěžním dialogu. Výzva k účasti v soutěžním dialogu musí obsahovat náležitosti stanovené v příloze č. 6 k tomuto zákonu.

63.         Podle § 69 odst. 1 zákona zadavatel s účastníky zadávacího řízení vede soutěžní dialog s cílem nalézt řešení způsobilá splnit potřeby zadavatele (dále jen „řešení“).

64.         Podle § 69 odst. 2 zákona zadavatel může během soutěžního dialogu projednat veřejnou zakázku ze všech hledisek.

65.         Podle § 73 odst. 3 zákona v nadlimitním režimu může zadavatel požadovat prokázání

            a) ekonomické kvalifikace podle § 78 zákona nebo

            b) technické kvalifikace podle § 79 zákona.

66.         Podle § 73 odst. 5 zákona zadavatel je povinen v zadávací dokumentaci stanovit, které údaje, doklady, vzorky nebo modely k prokázání splnění požadovaných kritérií kvalifikace požaduje.

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

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

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

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

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

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

71.         Podle § 89 odst. 1 zákona jsou technické podmínky požadavky na vlastnosti předmětu veřejné zakázky, které zadavatel stanoví prostřednictvím

            a) parametrů vyjadřujících požadavky na výkon nebo funkci, popisu účelu nebo potřeb,             které mají být naplněny,

            b) odkazu na normy nebo technické dokumenty, nebo

            c) odkazu na štítky.

72.         Podle § 96 odst. 1 zákona zadavatel uveřejní zadávací dokumentaci s výjimkou formulářů podle § 212 zákona a výzev uvedených v příloze č. 6 k tomuto zákonu na profilu zadavatele ode dne uveřejnění oznámení o zahájení zadávacího řízení nebo od odeslání výzvy k podání žádosti o účast podle § 58 odst. 5 zákona nejméně do konce lhůty pro podání nabídek; to neplatí pro jednací řízení bez uveřejnění. 

73.         Podle § 98 odst. 1 zákona zadavatel může zadávací dokumentaci vysvětlit, pokud takové vysvětlení, případně související dokumenty, uveřejní na profilu zadavatele, a to

            a) nejméně 5 pracovních dnů před uplynutím lhůty pro podání žádostí o účast,   předběžných nabídek nebo nabídek, nebo

            b) v případech, kdy je lhůta pro podání nabídek zkrácena podle § 57 odst. 2 písm. b) zákona     nebo § 59 odst. 5 zákona, nejméně 4 pracovní dny před uplynutím lhůty pro podání žádostí            o účast, předběžných nabídek nebo nabídek.

74.         Podle § 98 odst. 5 zákona pokud by spolu s vysvětlením zadávací dokumentace zadavatel provedl i změnu zadávacích podmínek, postupuje podle § 99 zákona.

75.         Podle § 99 odst. 1 zákona zadávací podmínky obsažené v zadávací dokumentaci může zadavatel změnit nebo doplnit před uplynutím lhůty pro podání žádosti o účast, předběžných nabídek nebo nabídek. Změna nebo doplnění zadávací dokumentace podmínek musí být uveřejněna nebo oznámena dodavatelům stejným způsobem jako zadávací podmínka, která byla změněna nebo doplněna.

76.         Podle § 99 odst. 2 zákona pokud to povaha doplnění nebo změny zadávací dokumentace vyžaduje, zadavatel současně přiměřeně prodlouží lhůtu pro podání žádostí o účast, předběžných nabídek nebo nabídek. V případě takové změny nebo doplnění zadávací dokumentace, která může rozšířit okruh možných účastníků zadávacího řízení, prodlouží zadavatel lhůtu tak, aby od odeslání změny nebo doplnění zadávací dokumentace činila nejméně celou svou původní délku.

77.         Podle § 241 odst. 1 zákona námitky může podat dodavatel, kterému postupem zadavatele souvisejícím se zadáváním podlimitní nebo nadlimitní veřejné zakázky, včetně koncese s výjimkou koncesí malého rozsahu podle § 178 zákona nebo se zvláštními postupy podle části šesté hrozí nebo vznikla újma (dále jen „stěžovatel“).

78.         Podle § 241 odst. 2 zákona se námitky podle § 241 odst. 1 zákona podávají písemně a lze je podat proti

            a) všem úkonům nebo opomenutím zadavatele v zadávacím řízení a zvláštnímu postupu           podle části šesté zákona, včetně stanovení zadávacích podmínek,

            b) volbě druhu zadávacího řízení nebo režimu veřejné zakázky, nebo

            c) postupu zadavatele, který směřuje k zadání veřejné zakázky mimo zadávací řízení             v rozporu s tímto zákonem.

79.         Podle § 242 odst. 2 zákona námitky proti úkonům oznamovaným v dokumentech, které je zadavatel povinen podle tohoto zákona uveřejnit či odeslat stěžovateli, musí být doručeny zadavateli do 15 dnů od jejich uveřejnění či doručení stěžovateli.

80.         Podle § 242 odst. 3 zákona pokud je v zadávacím řízení stanovena lhůta pro podání žádostí o účast, musí být námitky proti podmínkám vztahujícím se ke kvalifikaci dodavatele doručeny zadavateli nejpozději do skončení této lhůty.

81.         Podle § 248 odst. 1 zákona Úřad vykonává dozor nad dodržováním pravidel stanovených tímto zákonem a zadávacími podmínkami pro zadání podlimitní a nadlimitní veřejné zakázky, včetně koncese s výjimkou koncesí malého rozsahu podle § 178 zákona, a pro zvláštní postupy podle části šesté, při kterém

            a) rozhoduje o tom, zda zadavatel při zadávání veřejné zakázky nebo při zvláštním postupu      postupoval v souladu s tímto zákonem,

            b) rozhoduje o tom, zda postup zadavatele, který směřuje k zadání veřejné zakázky mimo         zadávací řízení, je v souladu s tímto zákonem,

            c) ukládá nápravná opatření,

            d) rozhoduje o návrhu podle § 267 zákona,

            e) kontroluje podle kontrolního řádu soulad úkonů zadavatele při zadávání veřejných    zakázek s tímto zákonem.

82.         Podle § 249 zákona řízení o přezkoumání úkonů zadavatele se zahajuje na písemný návrh stěžovatele (dále jen „navrhovatel“) nebo z moci úřední.

83.         Podle § 257 písm. h) zákona Úřad zahájené řízení usnesením zastaví, jestliže návrhu nepředcházely řádně a včas podané námitky; to neplatí pro návrhy podle § 254 zákona. 

84.         Podle § 263 odst. 2 zákona nedodrží-li zadavatel pravidla stanovená pro zadání veřejné zakázky nebo pro zvláštní postup podle části šesté zákona, přičemž tím ovlivní nebo může ovlivnit výběr dodavatele nebo výběr návrhu, a dosud nedošlo k uzavření smlouvy, Úřad zruší zadávací řízení nebo soutěž o návrh nebo jen jednotlivý úkon zadavatele.

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

86.         Podle § 265 písm. a) zákona Úřad návrh zamítne, pokud nebyly zjištěny důvody pro uložení nápravného opatření.

Zjištěné skutečnosti

Skutečnosti zjištěné ze zadávací dokumentace

87.         V čl. 2. „CHARAKTER ZADÁVACÍ DOKUMENTACE“ zadávací dokumentace je uvedeno mimo jiné, že „[ú]daje obsažené v této zadávací dokumentaci vyjadřují požadavky zadavatele, které jsou mu známy v době zahájení řízení se soutěžním dialogem. Informace zadavatele uvedené v této zadávací dokumentaci vyjadřují pouze obecný záměr a základní představy zadavatele o plnění veřejné zakázky.

Zadavatel není v současné době objektivně schopen definovat všechny podrobné a konkrétní technické, právní, finanční a jiné podmínky pro plnění veřejné zakázky. Tyto podmínky budou vymezeny v zadávací dokumentaci až na základě výsledků jednání s jednotlivými účastníky soutěžního dialogu.

Informace uvedené v této zadávací dokumentaci mají dodavatelům umožnit kvalifikovanou účast v soutěžním dialogu a přípravu reakce na požadavky zadavatele tak, jak je uvedeno v této zadávací dokumentaci, jako podkladu pro vedení soutěžního dialogu mezi zadavatelem a jednotlivými účastníky soutěžního dialogu.

Tato zadávací dokumentace nepředstavuje podklad pro zpracování nabídky a neobsahuje podrobné údaje nezbytné pro zpracování nabídky.“

88.         V témže článku zadávací dokumentace je dále uvedeno, že „[t]ato zadávací dokumentace je formulována s ohledem na své reálné použití až v dialogové a následně nabídkové fázi zadávacího řízení, tj. po skončení fáze kvalifikační. Zadavatel předpokládá možnou změnu zadávací dokumentace v návaznosti na výsledky dialogové fáze. Pro vyloučení pochybností platí, že v úvodu zadávacího řízení (v kvalifikační fázi) dodavatelé podávají pouze žádost o účast, přičemž v této fázi zadávacího řízení slouží tato zadávací dokumentace dodavatelům k získání rámcové představy o předmětu plnění a hodnotících kritériích. K podání nabídek dle této zadávací dokumentace budou dodavatelé adresně vyzváni v průběhu zadávacího řízení. Tato zadávací dokumentace je připravena na to, aby zadávací podmínky ve všech klíčových technických parametrech pokrývaly vhodné řešení (případně vhodná řešení), nalezená zadavatelem v návaznosti na průběh soutěžního dialogu.“

89.         V čl. 3. „ZÁMĚR ZADAVATELE A CÍLE SOUTĚŽNÍHO DIALOGU“ zadávací dokumentace je uvedeno mimo jiné, že »[o]becným záměrem zadavatele je vytvoření nového informačního systému justičního elektronického spisu a jeho nástavby pro agendu insolvenčního řízení (dále jen „elSIR"), nasazení tohoto systému do prostředí justice a zajištění provozu, podpory a rozvoje vytvořeného informačního sytému. Zadání této veřejné zakázky směřuje k tomu, aby bylo nalezeno řešení informačního systému elSIR, které by odpovídalo představám zadavatele a respektovalo všechny jeho požadavky, jakož i požadavky kladené na činnost zadavatele a veškeré právní předpisy.«

90.         V odst. 4.1 „Předpokládaný předmět veřejné zakázky“ zadávací dokumentace je uvedeno mimo jiné, že »[v] této fázi zadavatel není objektivně schopen vymezit veškeré technické podmínky a právní a finanční požadavky na plnění veřejné zakázky tak, aby mohl sestavit zadávací dokumentaci. Jediné, co je zadavatel schopen definovat je, že předmětem (či spíše účelem) plnění veřejné zakázky bude:

            - vytvoření informačního systému elSIR, nasazení tohoto systému do prostředí justice (dále      jen „Dílo")

            - a zajištění provozu, podpory a rozvoje vytvořeného informačního sytému (dále jen      „Provoz a servis").

 

            Zadavatel zná některé parametry, přičemž tyto jsou popsány v této zadávací      dokumentaci. Zadavatel dále jako součást zadávací dokumentace předkládá následující     dokumenty, které v obecné rovině vyjadřují jeho představu o předmětu plnění této veřejné   zakázky a definují některé závazné parametry:

            - Obchodní podmínky resortu zadavatele (Příloha č. 1 zadávací dokumentace)

            - Projektový záměr (Příloha č. 2 zadávací dokumentace)

            - Harmonogram (Příloha č. 3 zadávací dokumentace)

            Informace uvedené v této zadávací dokumentaci mají účastníkům mj. umožnit vytvořit si         představu o předpokládaném budoucím předmětu plnění a případně posoudit vhodnost        řešení, které zadavatel v době zpracování této zadávací dokumentace taktéž předpokládá.          Právě uvedené bude zahrnovat možnost účastníků vyjádřit se (učinit „reakci")             k zadavatelem předpokládaným požadavkům na elSIR, které zadavatel může vzít následně             v potaz při zpracování finální zadávací dokumentace k veřejné zakázce.«

91.         V odst. 4.6 „Předpokládaná hodnota veřejné zakázky“ zadávací dokumentace je uvedeno, že „[p]ředpokládaná hodnota veřejné zakázky činí u ceny za Dílo 158 754 107,44 Kč bez DPH (192 092 470 Kč s DPH). Předpokládaná hodnota veřejné zakázky u ceny za Provoz a servis nebude zveřejněna.“

92.         V čl. 5.1 „Fáze zadávacího řízení“ zadávací dokumentace je uvedeno mimo jiné, že průběh zadávacího řízení je rozdělen do tří částí, a to

a) fáze kvalifikační;

b) fáze soutěžního dialogu; a

c) fáze nabídková.

93.         V odst. 5.2 „Fáze kvalifikační“ zadávací dokumentace je uvedeno, že „[k]valifikační fáze je zahájena odesláním oznámení o zahájení zadávacího řízení k uveřejnění. Ve lhůtě vymezené v oznámení o zahájení zadávacího řízení mohou dodavatelé podávat své žádosti o účast. Po uplynutí lhůty pro podání žádostí o účast zadavatel posoudí soulad podaných žádostí o účast se zadávacími podmínkami v kvalifikační dokumentaci. Dodavatelé, kteří nesplní požadavky zadavatele na kvalifikaci, budou vyloučeni z účasti v zadávacím řízení. Následně bude v kvalifikační fázi snížen počet účastníků zadávacího řízení tak, aby ve fázi soutěžního dialogu jednal zadavatel s nejvýše třemi účastníky.

(...) Další informace o kvalifikační fázi jsou uvedeny v kvalifikační dokumentaci.“

94.         V odst. 5.3 „Fáze soutěžního dialogu“ zadávací dokumentace je uvedeno mimo jiné, že „[v] soutěžním dialogu bude zadavatel jednat o veškerých podmínkách a aspektech veřejné zakázky. V rámci soutěžního dialogu bude zadavatel s účastníky zadávacího řízení jednat zejména o technických, finančních a smluvních podmínkách plnění veřejné zakázky. Za tímto účelem budou konána jednání s účastníky zadávacího řízení, jejichž předmětem bude projednání těchto podmínek za účelem stanovení finálních závazných zadávacích podmínek zadavatelem v rozsahu a podrobnostech umožňujících účastníkům podat nabídky. Cílem soutěžního dialogu je především seznámit se se zamýšleným řešením potřeb a požadavků zadavatele, upřesnit technické a jiné podmínky předmětu veřejné zakázky, definovat závazný vzor smlouvy.“

95.         V odst. 5.4 „Fáze nabídková“ zadávací dokumentace je uvedeno mimo jiné, že „[n]abídky budou zpracovány v souladu s finálními závaznými zadávacími podmínkami, které budou vypracovány zadavatelem v návaznosti na průběh a výsledky fáze soutěžního dialogu a obsaženy ve výzvě k podání nabídek. V rámci těchto finálních zadávacích podmínek bude zejména poskytnut účastníkům finální závazný vzor smlouvy na plnění předmětu veřejné zakázky, a dále budou závazným způsobem upřesněn předmět plnění veřejné zakázky, hodnotící kritéria, podle nichž se budou hodnotit nabídky, lhůta pro podání nabídek, podmínky pro složení jistoty a další podrobnosti nezbytné pro zpracování a podání nabídky.“

96.         Z čl. 16 „Seznam příloh“ zadávací dokumentace plyne, že nedílnou součástí zadávací dokumentace jsou mimo jiné přílohy č. 2 – projektový záměr a č. 4 – kvalifikační dokumentace včetně příloh.

Skutečnosti zjištěné z přílohy č. 2 zadávací dokumentace (projektový záměr)

97.         V kapitole 1 »Předmět veřejné zakázky „Vývoj a implementace eISIR a společných částí« projektového záměru je uvedeno:

            »Veřejná zakázka „Vývoj a implementace eISIR a společných částí“ je součástí projektu            eJustice 2020 – část eISIR. Pojem elektronizace justice, ve zkratce eJustice, lze definovat         jako využití informačních a komunikačních technologií v justici s cílem podpořit spravedlivé,          zákonné a rychlé rozhodování organizačních složek resortu justice a jejich efektivní,        hospodárné a transparentní fungování. Zadavatel má za cíl tímto projektem vybudovat          technologicky moderní systém splňující závazné legislativní požadavky, dále požadavky na způsob evidence spisů a bezpečnost dat.

            Předmětem této veřejné zakázky je návrh, implementace, nasazení a provoz:

            - elektronického insolvenčního rejstříku eISIR,

            - sdílených služeb pro práci s dokumenty eSPIS,

            - nového systému spisové služby splňujícího národní standard,

            - dalších sdílených podpůrných služeb a aplikací zahrnujících Registr jmen, Číselníky, Rozvrh     práce a Centrální tvorbu dokumentů (centrální sdílené aplikace, dále též souhrnně      označovány jako „Centrum justice“),

            (dále souhrnně označováno „Systém eISIR“).

            Jednotlivé komponenty řešení budou implementovány jako samostatné služby             (či mikroslužby – microservices) vzájemně propojené prostřednictvím jasně definovaného        standardního API zadavatele, tedy využitím webových služeb, integrační platformy či   message brokeru.

            Součástí předmětu plnění jsou analytické práce, vývoj, implementace a integrace Systému       eISIR do prostředí zadavatele, migrace definovaných dat, pilot Systému eISIR a zajištění         provozu, podpory a rozvoje vytvořeného Systému eISIR po dobu pěti let od nabytí účinnosti    Smlouvy uzavřené s vybraným dodavatelem.

            Důvodem pro vyhlášení veřejné zakázky ze strany zadavatele je modernizace aplikačního             programového vybavení resortu a zajištění technologického zázemí odpovídající aktuálním      technologiím. Od této skutečnosti zadavatel očekává posílení efektivity a rychlosti při   rutinních činnostech organizačních složek resortu justice, zvýšení transparentnosti      rozhodování a zlepšení dostupnosti informací pro subjekty soudních řízení.

            Cílem veřejné zakázky je vytvoření sdílených služeb pro práci s dokumenty eSPIS.             Tyto služby budou integrovány se spisovou službou (dále jen „eSSL“) s využitím webových         služeb             definovaných v Národním standardu elektronických systémů spisových služeb (dále       jen „NSESSS“). eSPIS tak bude splňovat podmínky stanovené zákonem č. 499/2004 Sb.,             o archivnictví a spisové službě a o změně některých zákonů, ve znění pozdějších předpisů,        prováděcích předpisů k zákonu a bude v souladu s Národním standardem pro elektronické    systémy spisové služby.

            Dále je cílem zakázky vytvoření nadstavbového Systému eISIR pro agendu insolvenční. Celý      Systém eISIR musí být vytvořen jako procesně orientovaný. eSPIS musí umožnit modulární      napojení dalších nadstavbových aplikací prostřednictvím webových služeb splňujících         integrační standardy MSp. Součástí integrace jsou dále napojení na zásadní prvky     eGovermentu, jako je Národní identitní autorita – NIA, Informační systém datových             schránek – ISDS, integrace se základními registry ROS, ROB, RÚIAN, propojeného datového     fondu prostřednictvím eGON Service Bus – eGSB, Jednotný identitní prostor a katalog             autentizačních a autorizačních služeb (dále jen „JIP/KAAS“), Národní katalog otevřených dat        (dále jen „NKOD“) a dále pak možnost nahlížení do spisu na Portálu občana.

            Podpůrné části – aplikace Centra Justice představují množinu aplikačních komponent             a systémů, které budou do budoucna využívány alespoň dvěma různými agendovými     informačními systémy (dále jen „AIS“) justice. Tento koncept má za úkol eliminovat do            budoucna duplicitní ukládání záznamů a vznik duplicitních nástrojů a spojů mezi             jednotlivými systémy justice. Dvě komponenty v rámci Centra justice a programu eJustice   2020 jsou již vytvořeny či ve vývoji, jedná se o Registr justičních činitelů (dále jen „ReJČ“)              a Generátor přidělování (dále jen „eGP“) – nástroj pro přidělování soudních věcí s prvkem      náhody. Tyto obě komponenty budou integrovány do Systému eISIR resp. eSPIS.«

98.         V kapitole 1.1 „eSPIS“ projektového záměru je popsán eSPIS, přičemž je zde uvedeno mimo jiné, že  eSPIS je modulární informační systém pro správu dokumentů a spisů v rezortu justice a že součástí dodávky eSPIS je dodání elektronické spisové služby. Mezi zásadní funkce eSPISu patří:

            - „zajištění správy dokumentů a vedení spisového materiálu;

            - odesílání a příjem dokumentů, integrace s elektronickou podatelnou;

            - vzdálené nahlížení do spisu přes internet pro oprávněné osoby;

            - napojení na základní registry, rejstříky a evidence;

            - práce se spisem;

            - pomocné administrativní funkce pro rozhodovací činnost (chytré vypořádání námitek,            vyznačování poznámek v textu aj.);

            - prezenční režim spisového materiálu;

            - digitální archivace a skartační řízení dokumentů.“

99.         V kapitole 1.2 „eISIR“ projektového záměru je popsán eISIR, přičemž je zde uvedeno mimo jiné, že »eISIR je agendový (nadstavbový) modul pro eSPIS (dále jen „eISIR“). Slouží k vedení a správě plně elektronických spisů v agendě insolvenční, tj. insolvenční rejstřík INS, rejstřík incidenčních sporů ICm a všeobecný rejstřík NCI a INZu krajských soudů, a v odvolací a dovolací insolvenční agendě vrchních soudů a Nejvyššího soudu. Modul obsahuje zvláštní funkce pro vedení spisů insolvenční agendy, pro evidenci rejstříkových dat, pro zveřejňování ve veřejné části, dále pak nástroj pro určení insolvenčního správce a další. eISIR bude mít mimo interní části založené na eSPISu i externí část – veřejný insolvenční rejstřík. Ten slouží veřejnosti jako zdroj informací o insolvenčních řízeních v souladu se zákonem č. 182/2006 Sb., o úpadku a způsobech jeho řešení (insolvenční zákon), ve znění pozdějších předpisů.

            (...)

            Mezi zásadní funkce modulu eISIR patří:

            - podpora vedení plně elektronického insolvenčního spisu;

            - podpora pro využití XML dat z PDF či webových formulářů (úplné elektronické podání);

            - podpora procesního workflow (standardizované insolvenční procesy a události, které je          spouští);

            - evidence údajů, statistik a výkazů insolvenční agendy;

            - zveřejňování ve veřejné části insolvenčního rejstříku včetně anonymizace potřebných             údajů;

            - hromadná práce s dokumenty a evidencemi (např. evidence a zpracování přihlášek    pohledávek, hromadná změna věřitele apod.);

            - integrace s dalšími systémy Centra Justice;

            - poskytnutí dat pro Justiční LKOD (otevřená data).«

100.     V kapitole 1.3 „Registr jmen“ projektového záměru je popsán Registr jmen, přičemž je zde uvedeno mimo jiné, že »[r]egistr jmen je podpůrným systémem, který zajišťuje jednoznačnou identifikaci osob napříč AIS justice a který zprostředkovává komunikaci se základními registry a externími evidencemi (dále jen „ReJmen“).

            ReJmen pomocí napojení na ISZR (Informační systém základních registrů) a propojený datový fond zajišťuje:

            - ztotožňování osob;

            - načítání specifických aktuálních údajů z ČSSZ B2B rozhraní k jednotlivým fyzickým osobám;

            - načítání aktuálních i historických základních údajů fyzických a právnických osob;

            - ověřování platnosti adres a datových schránek fyzických osob.

            ReJmen dále zajišťuje:

            - notifikaci AIS o změnách údajů osob;

            - poskytování informací o řízeních, která jsou s osobami vedena (údaj o spisové značce a roli    osoby v řízení). «

101.     V kapitole 1.4 „Číselníky“ projektového záměru je popsána aplikace Číselníky, přičemž je zde uvedeno mimo jiné, že „[a]plikace Číselníky (centrální číselníky) by se měla stát primárním poskytovatelem číselníkových hodnot v rámci systémů justice.“

102.     V kapitole 1.5 „Centrální tvorba dokumentů“ projektového záměru je popsána Centrální tvorba dokumentů, přičemž je zde uvedeno mimo jiné, že se jedná o  »nástroj pro automatizovanou tvorbu písemností z evidenčních dat agendových a podpůrných informačních systémů justice (dále jen „CTD“).«

103.     V kapitole 1.6 „Rozvrh práce“ projektového záměru je popsán Rozvrh práce, přičemž je zde uvedeno mimo jiné, že „[i]nformační systém Rozvrh práce je aplikace určená primárně pro řešení nastavení a sestavení rozvrhu práce soudu včetně nastavení způsobu přidělování věcí.“

104.     V kapitole 1.7 „Seznam insolvenčních správců“ projektového záměru je popsán Seznam insolvenčních správců, přičemž je zde uvedeno mimo jiné, že „[s]eznam obsahuje základní požadované údaje (profily) insolvenčních správců. Má veřejnou část a podporuje vyhledávání základních informací pomocí filtrace (např. dle např. oblasti, typu zaměření atd.). Veřejná část seznamu bude prezentována v insolvenčním rejstříku (veřejná část eISIR).“

105.     V kapitole 2 „Součást dodávky“ projektového záměru jsou dále popsány součásti dodávky, popř. co součást dodávky v rámci plnění veřejné zakázky netvoří. Jsou zde tedy uvedeny v čl. 2. 1–2.15 informace o analýze, systémech a aplikacích, integraci aplikací, pilotu Systému eISIR, uvedení do rutinního provozu, migraci dat, poskytování servisních služeb a rozvojových služeb, databázích a dalších platformách, serverovém prostředí a úložišti, virtualizaci, operačním systému, zálohování, síťové infrastruktuře a prostředí.

106.     V kapitole 2.1 „Analýza“ projektového záměru je uvedeno, že „[s]oučástí dodávky je analýza Systému eISIR a jeho všech součástí obsahující především:

            - Architektura Systému eISIR

            - Funkční a nefunkční požadavky a jejich naplnění

            - Procesy

            - Integrace na externí systémy         

            - Datový model

            - Funkční celky a mapování na funkční/nefunkční požadavky

            - Technologie HW/SW

            - Usecases

            - Testcases

            - Návrh obrazovek

            - Základní definice reportů"

107.     V kapitole 2.2 „Systémy a aplikace“ projektového záměru je uvedeno, že „[s]oučástí dodávky je vývoj, instalace, implementace a integrace následujících systémů a aplikací (včetně kompletní dokumentace):

            - eSPIS (včetně eSSL)

            - eISIR

            - ReJmen

            - Číselníky

            - CTD

            - Rozvrh práce

            - Seznam insolvenčních správců.“

108.     V kapitole 2.3 „Integrace aplikací“ projektového záměru je uvedeno, že „[s]oučástí dodávky je i integrace stávajících nebo budoucích systémů a aplikací, které samotné nejsou součástí dodávky:

            - Active directory

            - Národní identitní autorita + Portál občana

            - Dokumentové centrum (generování PDF, jejich podepisování, pečetění atp.)

            - Národní archiv

            - Centrální podatelna (CePo/CeVý)

            - Registry justičních činitelů (ReJČ)

            - Generátor náhodného přidělení (eGP)

            - Ekonomický systém organizací (IRES)

            - Informační systém veřejných rejstříků (ISVR – obchodní rejstřík)

            - Informační systém rejstříku trestů (ISRT)

            - Insolvenční rejstřík na portálu evropské e‑justice (IRI)

            - Czech POINT

            - Informační systém základních registrů (ISZR a PPDF)

            - Justiční LKOD

            - Datový sklad (DW).“

109.     V kapitole 2.4 „Pilot Systému eISIR“ projektového záměru je uvedeno:

            - „V rámci pilotu Systému eISIR se budou účastnit následující typy pilotních organizací:

                        - 2 krajské soudy

                        - 2 vrchní soudy

                        - 1 nejvyšší soud

- Ministerstvo spravedlnosti (seznam insolvenčních správců a rozhraní pro výkon dohledu)

            - Součástí pilotu bude i nastavení příslušných procesů, dokumentů, potřebných struktur             a číselníků pro pilotní organizace.

            - Součástí pilotního řešení je vytvoření školící dokumentace.

            - Součástí pilotního řešení je i školení uživatelů na pilotních organizacích (předpokládá se         celkem 10 školení pro pilotní organizace pro celkem 250 zaměstnanců).

            - Další součástí pilotu budou integrace na jednotné lokální řešení IRES (ekonomická agenda     pilotních organizací).“

110.     V kapitole 2.5 „Uvedení do rutinního provozu“ projektového záměru je uvedeno:

            - „Postupné rozšíření Systému eISIR na všechny insolvenční soudy a jejich pobočky (včetně        školení uživatelů), tj.

                        Městský soud v Praze

                        Krajský soud v Ústí nad Labem

                                   Krajský soud v Ústí nad Labem – pobočka Liberec

                        Krajský soud v Ostravě

                                   Krajský soud v Ostravě – pobočka Olomouc

                        Krajský soud v Brně

                        Krajský soud v Jihlavě

                        Krajský soud v Hradci Králové

                                   Krajský soud v Hradci Králové – pobočka Pardubice

                        Krajský soud v Plzni

                        Krajský soud v Českých Budějovicích

                        Vrchní soud v Praze

                        Vrchní soud v Olomouci

                        Nejvyšší soud ČR

            - Uvedení Systému eISIR do rutinního provozu na Ministerstvu spravedlnosti ČR

            - Uvedení veřejné části Systému eISIR do rutinního provozu.“

111.     V kapitole 2.6 „Migrace dat“ projektového záměru je uvedeno, že „[v]zhledem k současnému provozu insolvenčního rejstříku jako kritické informační infrastruktury, bude zadavatel požadovat zajištění stavu předpokládaného zákonem. Zejména

- Dostupnost veřejné části insolvenčního rejstříku v zákonném rozsahu, zákon č. 182/2006 Sb., o úpadku a způsobech jeho řešení (insolvenční zákon).

            - Umožnění náhledu a práce s daty původního systému ISIR pro soudy.

            Rozsah a možné varianty řešení migrace budou detailně specifikovány v rámci soutěžního        dialogu.“

112.     V kapitole 2.7 „Poskytování servisních služeb“ projektového záměru je uvedeno, že „[p]o uvedení Systému eISIR do ostrého provozu bude zadavatel požadovat poskytování služeb podpory provozu systému po dobu 5 let.“

113.     V kapitole 2.8 „Rozvojové služby“ projektového záměru je uvedeno, že „[p]o uvedení Systému eISIR do ostrého provozu bude zadavatel požadovat poskytování rozvojových služeb k Systému eISIR po dobu 5 let.“ 

114.     V kapitole 2.10 „Serverové prostředí a úložiště“ projektového záměru je uvedeno mimo jiné, že „[d]ostatečnou kapacitu a dostatečný výkon pro webové, aplikační a databázové servery zajistí zadavatel.“

115.     V kapitole 2.15 „Prostředí“ projektového záměru je uvedeno mimo jiné, že „[v] rámci dodávky Systému eISIR jsou požadována kompletní 3 prostředí (vývojové, testovací a produkční prostředí).“

116.     V kapitole 3 „Principy základních procesů“ projektového záměru jsou popsány „příklady základních highlevel procesů a systémy a komponenty, které proces podporují. Nejedná se o přesný popis procesů, ale spíše o náhled do hlavních, někdy i nepovinných, kroků jednotlivých procesů pro pochopení principů Systému eISIR pro dodavatele.“

117.     V kapitole 4 „Právní předpisy, normy a standardy“ projektového záměru je uveden výčet mimo jiné právních předpisů, se kterými musí být systém eISIR nebo jeho části v souladu, přičemž se jedná o:

            - zákon č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů,             ve znění pozdějších předpisů, a související předpisy, zejména vyhlášku č. 259/2012 Sb.,             o podrobnostech výkonu spisové služby, ve znění pozdějších předpisů,

            - Národní standard pro elektronické systémy spisové služby,

            - zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů,

            - zákon č. 365/2000 Sb., o informačních systémech veřejné správy a o změně souvisejících       některých dalších zákonů.

118.     V dané kapitole je uveden rovněž výčet „Ostatní důležité související předpisy", který obsahuje:

            - Nařízení Evropského parlamentu a Rady (EU) č. 910/2014 o elektronické identifikaci             a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu             a o zrušení směrnice 1999/93/ES (a příslušné prováděcí právní předpisy),

            - zákon č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce,             ve znění pozdějších předpisů,

            - zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů,

            - zákon č. 182/2006 Sb., o úpadku a způsobech jeho řešení (insolvenční zákon),             ve znění pozdějších předpisů,

            - zákon č. 312/2006 Sb., o insolvenčních správcích, ve znění pozdějších předpisů,

            - Nařízení Evropského parlamentu a Rady (EU) č. 2016/679 ze dne 27. dubna 2016             o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu         těchto údajů a o zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů),

            - zákon č. 110/2019 Sb., o zpracování osobních údajů, ve znění pozdějších předpisů.

119.     V kapitole 5 „Architektura“ projektového záměru je v jednotlivých podkapitolách popsána předpokládaná aplikační architektura Systému eISIR, základní principy integrace služeb informačních systémů, základní principy návrhu uživatelských rozhraní a základní principy práce s dokumenty a spisy.

120.     V kapitole 5.1 „Předpokládaná aplikační architektura Systému eISIR“ projektového záměru je obsažen obrázek nadepsaný „Obrázek 1 - Schéma předpokládané aplikační architektury projektu“. Dále je zde uvedeno, že dané schéma „znázorňuje logickou strukturu aplikací a jejich vazeb (notace ArchiMate 3.0). Pro zamezení nejasností se uvádí, že se nejedná o finální návrh, diagram má sloužit výhradně pro jednodušší orientaci dodavatele v řešené problematice.“

121.     Při původním velikosti daného schématu je toto schéma vč. popisků nečitelné. Při maximálním zvětšení daného schématu jsou:

            - popis „Pohled na strukturu aplikací, komponent a jejich rozhraní. Zakresleny jsou také            vazba na aplikační služby implementované projektem eISIR a využití centrálních prvků     eGovermentu a jejich služeb jednotlivými systémy a jejich komponentami.“ zřetelně (bez         výraznějších obtíží) čitelný,

            - legenda: „Stávající prvek“ a „Projektem budovaný prvek“ zřetelně (bez výraznějších obtíží)    čitelná,

            - struktura aplikací, komponent a jejich rozhraní zřetelně (bez výraznějších obtíží) čitelná,

            - vazby zřetelně (bez výraznějších obtíží) čitelné,

            - popisky jednotlivých skupin a podskupin aplikací, komponent, systémů, prvků, služeb   apod. jsou obtížněji čitelné a některé nečitelné; většinu těchto popisků však lze při     podrobné znalosti obsahu zadávací dokumentace a terminologii v ní použité (zejména            projektového záměru) přečíst, resp. určit,

            - popisky jednotlivých konkrétních aplikací, komponent, systémů, prvků, služeb apod. jsou         obtížněji čitelné a některé nečitelné; většinu těchto popisků však lze při podrobné znalosti           obsahu zadávací dokumentace (zejména projektového záměru, viz např. obsah jednotlivých         kapitol v rámci kapitoly 2 „Součást dodávky“ projektového záměru) a terminologii v ní            použité, včetně názvů a zkratek pro jednotlivé aplikace, systémy apod., přečíst, resp. určit;   uvedené se týká zejména projektem budovaných prvků v částech Justiční aplikace             a komponenty, Elektronický spis, Komunikační rozhraní centrálních aplikací, Podpůrné justiční systémy.

122.     V kapitole 5.2 „Základní principy návrhu informačních systémů“ projektového záměru je uvedeno mimo jiné, že »[s]ystémy a služby systémů budou budovány modulárně, přičemž moduly budou implementovány jako samostatné sdílené služby anebo interní mikro služby s jasně definovaným rozhraním. Jako samostatné sdílené služby budou implementovány minimálně komponenty znázorněné na schématu v kapitole 5.1 (tmavě modře podbarvené aplikační komponenty ve skupině „podpůrné aplikace“).«

123.     V kapitolách 5.3, 5.4 a 5.5 projektového záměru je k využití webových služeb uvedeno mimo jiné:

            - „V případě integrace informačních systémů anebo konzumace sdílených služeb zadavatele    bude veškerá komunikace realizována formou volání webových služeb zprostředkovaných       integrační platformou ESB.“ (kapitola 5.3 „Základní principy integrace služeb informačních     systémů“)

            - „Uživatelské rozhraní je implementováno jako samostatná část, která s dalšími částmi           Systému eISIR komunikuje pomocí webových služeb (typicky REST). Realizace uživatelského      rozhraní musí umožňovat jeho jednoduchou výměnu a případně paralelní provoz více      alternativních uživatelských rozhraní (např. mobilní aplikace).“ (kapitola 5.4 „Základní    principy návrhu uživatelských rozhraní“)

            - „Přístup k dokumentům evidovaným v eSSL z budovaných systémů je realizován využitím        webových služeb eSSL dle Národního standardu pro elektronické systémy spisové služby     (NSESSS) a je přistupováno jménem uživatele pracujícího v budovaném Systému eISIR.“            (kapitola 5.5 „Základní principy práce s dokumenty a spisy“)

124.     V kapitole 6 „Využité technologie a technologické standardy“ projektového záměru je uvedeno, že „[z] předpokládané aplikační architektury, výše uvedených základních architektonických principů a dalších standardů řízení provozu a rozvoje IT v prostředí zadavatele, Zadavatel predikuje využití následujících technologií a technologických standardů, jež musí dodavatel prokazatelně ovládat pro řádnou realizaci uvedené zakázky:

            - Architektura aplikací využitím vzorů MVC, MVVC či obdobných;

            - Architektonický návrh v notacích ArchiMate, UML a BPMN;

- Webové, desktop a mobilní uživatelské rozhraní, principy UX/UIX (User/Interface Experience), SPA (Single pageapplication);

            - Programovací jazyky a vývojové frameworky;

            - Webové technologie (HTML, CSS atd.);

            - Integrační rozhraní a API, webové služby SOAP/REST;

            - Databáze, SQL;

            - Kontejnerizace aplikací jako možnost řešení DEV-OPS u front-end aplikací;

            - Reporting, business inteligence a datové pumpy (ETL);

            - Integrační platformy (ESB/messaging platformy);

            - Templateengine, nástroje pro generování dokumentů, XML, XSLT;

            - Vyhledávací systémy (např. Elasticsearch);

            - ITSM procesy;

- DevOps procesy s využitím GitLab (zejména CI/CD – Continuous Integration, Continuous Deployment).“

125.     V kapitole 8 „Výkon[n]ost prostředí“ projektového záměru jsou v jednotlivých podkapitolách uvedeny informace o odezvách Systému eISIR na typizované uživatelské dotazy, dostupnosti Systému eISIR, odhadu hlavních entit Systému eISIR a škálovatelnosti.

126.     V kapitole 8.3 „Odhad hlavních entit Systému eISIR“ projektového záměru je uvedeno:

            - „Počet spisů aktivních spisů je přibližně 200 000 (agendy INS a ICm);

            - Roční přírůstek spisů cca 23 až 32 tisíc spisů;

            - Počet přijatých elektronických podání za rok 120 000;

            - Počet dokumentů a objem dokumentů v rámci insolvenčního řízení (včetně verzí         dokumentů a anonymizace) je 10 000 000 dokumentů v celkovém objemu přibližně 200 TB     dat;

            - Předpokládaný počet uživatelů typu administrativní pracovníci je 2000 uživatelů          (intenzivně pracují se Systémem eISIR většinu pracovní doby, zpracovávají úkoly, vkládá       informace, apod.);

- Předpokládaný počet uživatelů typu soudci a referenti je 700 uživatelů (využívají Systém eISIR více staticky, čtou a vytváří dokumenty, vytváří úkoly, apod.);

            - Předpokládaný počet uživatelů typu správci a administrátoři jsou průměrně 3 uživatelé za      každou organizaci (soudy a zadavatel) tj. celkem cca 100 uživatelů (Systém eISIR zatěžují          minimálně);

            - Návštěvnost veřejného insolvenčního rejstříku je 15 000 přístupů denně.“

127.     V kapitole 9 „Bezpečnost“ projektového záměru jsou v jednotlivých podkapitolách uvedeny informace o kritické infrastruktuře, provozu veřejné části eISIRu na oddělené infrastruktuře, autentizaci a autorizaci, Syslogu, dalším logování, SSO v rámci všech komponent Systému eISIR a o provozní monitoringu.

128.     V kapitole 9.1 „Kritická infrastruktura“ projektového záměru je uvedeno mimo jiné:

            - „Systém eISIR je součástí kritické infrastruktury dle zákona o kybernetické bezpečnosti,              a proto celý systém musí splňovat kritéria kritické infrastruktury.(...)

            - Systém eISIR musí být navržen v souladu se ZKB a interními bezpečnostními instrukcemi             a politikami MSp.“

129.     V kapitole 9.2 „Provoz veřejné části eISIRu na oddělené infrastruktuře“ projektového záměru je uvedeno: »Komponenta „veřejný insolvenční rejstřík“ je využívána externími uživateli (veřejností) a je od zbytku eISIRu oddělena a provozována ve speciálním režimu. Tím je myšleno, že tato veřejná část eISIRu je zcela oddělena od zbytku eISIRu, přičemž jsou do ní eISIRem přenášena data z jeho interních komponent.«

130.     V kapitole 10 „Požadavky na front-end Systému eISIR“ projektového záměru jsou v jednotlivých podkapitolách uvedeny informace o uživatelském rozhraní, konkrétně o personifikaci uživatelského rozhraní, interním rozhraní a přístupnosti Systému eISIR. Například v kapitole 10.1.1 „Personifikace uživatelské rozhraní“ projektového záměru je uvedeno:

            - „Pracovní plochy v Systému eISIR jsou personalizované pro uživatele na základě jejich rolí.     Systém eISIR dále vhodně řeší situaci, kdy má uživatel více rolí (výběr varianty bude    podložen výsledky uživatelského testování).

            - Pracovní plochu si může uživatel přizpůsobit podle vlastních preferencí (tj. je možné skrýt      pole, která uživatel nepoužívá apod.).

            - Systém bude nabízet Nejčastější akce v systému v daném kontextu pro uživatele.“

131.     V kapitole 10.1.3 „Přístupnost Systému eISIR“ projektového záměru je uvedeno mimo jiné, že „[r]ozhraní Systému eISIR musí být v souladu s § 4 a § 5 [z]ákona č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací a o změně zákona č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů.“

132.     V kapitole 11 „Požadavky na dokumentaci vývoj, zdrojový kód a deployment“ projektového záměru jsou v jednotlivých podkapitolách uvedeny požadavky na technickou dokumentaci, provozní dokumentaci, uživatelskou dokumentaci, bezpečnostní dokumentaci, programátorskou dokumentaci, další dokumentaci (analytickou dokumentaci a model architektury systému eISIR a jeho okolí), Git a Continuous Deployment proces. Například z kapitoly 11.1.1 „Technická dokumentace“ projektového záměru plyne, že součástí technické dokumentace k Systému eISIR bude mimo jiné:

            - „detailní popis architektury Systému eISIR v přehledných schématech včetně uvedení relací   mezi komponentami,

- popis high level architektury na třech vrstvách architektury (byznys vrstva, aplikační vrstva,   technologická vrstva), (...)

            - detailní popis databázového schématu včetně relací.“

133.     V kapitole 11.1.2 „Provozní dokumentace“ projektového záměru je uvedeno, že základní provozní dokumentace je stanovena v § 10 až 12 vyhlášky č. 529/2006 Sb., o dlouhodobém řízení informačních systémů veřejné správy, ve znění pozdějších předpisů. Dále je z této kapitoly plyne, že součástí provozní dokumentace bude mimo jiné detailní popis interních a externích komunikačních rozhraní a popis konfigurace databází.

134.     V kapitole 11.1.3 „Uživatelská dokumentace“ projektového záměru je uvedeno mimo jiné, že „[s]oučástí uživatelské dokumentace bude:

            - administrátorská dokumentace,

            - detailní instalační příručka, jejíž součástí bude:

                        -  detailní instalační manuál,

                        - detailní popis případných změn v nastavení OS,

                        - detailní popis konfigurace aplikačních serverů,

            - seznam standardních provozních úkonů a pracovních postupů,

            - detailní popis správy uživatelů a rolí,

            - detailní uživatelská příručka,

            - jednoduchá uživatelská příručka pro externí uživatele (dostupná z webu),

            - uživatelské testovací scénáře.“

135.     Z kapitoly 11.1.5 „Programátorská dokumentace“ projektového záměru plyne, že součástí programátorské dokumentace bude mimo jiné dokumentovaný datový a databázový model Systému eISIR.

136.     V kapitole 11.1.6 „Další dokumentace“ projektového záměru je uvedeno mimo jiné, že „[s]oučástí dokumentace dále bude:

            - Kompletní analytická dokumentace obsahující výstupy včetně záznamů o uživatelském           testování;

            - Architektura Systému eISIR a jeho okolí na čtyřech vrstvách architektury (business,     aplikační a technologická vrstva) v jazyce ArchiMate verze 3 s možností importu modelu do            nástroje Sparx Enterprise Architect verze 13.“

Skutečnosti zjištěné z přílohy č. 4 zadávací dokumentace (kvalifikační dokumentace)

137.     V úvodu kvalifikační dokumentace je uvedeno, že „[t]ato kvalifikační dokumentace je vypracována jako podklad pro podání žádostí dodavatelů o účast v zadávacím řízení podle § 28 odst. 1 písm. d) ZZVZ.“

138.     V čl. 2.5.1 „Technická kvalifikace dle § 79 odst. 2 písm. b) ZZVZ“ kvalifikační dokumentace zadavatel stanovil požadavek na předložení seznamu významných dodávek a služeb za účelem prokázání splnění kritéria technické kvalifikace dle § 79 odst. 2 písm. b) zákona. Zadavatel stanovil minimální úroveň tohoto kritéria technické kvalifikace tak, že požadoval, aby dodavatel předložil seznam obsahující alespoň jednu významnou dodávku/službu splňující všechny níže uvedené požadavky:

            a)         » Významná dodávka/služba spočívající v realizaci informačního systému pro správu                 a oběh dokumentů (dále jen „Informační systém“);

            b)         Předmět významné služby musel spočívat v zajištění následujících činností:

                        i)          analýza (zejména procesní analýza a návrh uživatelského rozhraní),

                        ii)         zpracování detailního implementačního plánu Informačního systému,

                        iii)        implementace, integrace a konfigurace Informačního systému,

                        iv)        pilotní provoz (tj. provoz před spuštěním běžného provozu realizovaný v                                     rozsahu běžného provozu, běžnými uživateli s reálnými / ostrými daty),                                      proces akceptačního testování (testování v testovacím prostředí                                                  prostřednictvím testerů s testovacími daty) a předávání Informačního                                               systému do běžného provozu,

                        v)         zpracování uživatelské, provozní, architektonické a technické dokumentace                                Informačního systému,

            c) Informační systém, který byl předmětem významné služby, musel dále splňovat                    následující kritéria:

                        i)          Informační systém obsahoval integrační vazby na jiné informační systémy,

                        ii)         objednatelem požadovaný počet spravovaných dokumentů byl min 400.000,

                        iii)        požadovaný počet pravidelně přistupujících unikátních uživatelů byl dle                                      objednatele měsíčně min 300,

                        iv)        3 vrstvá architektura (obsahující prezenční, aplikační a databázovou vrstvu                                    s přístupem pomocí webového klienta).

            d) hodnota významné dodávky/služby za plnění definované pod písm. a) až c) výše musela        činit minimálně 30 mil. Kč bez DPH, a současně

e) součástí významné dodávky/služby muselo být také kontinuální poskytování služeb    podpory a rozvoje Informačního systému po dobu minimálně 12 měsíců, přičemž     hodnota podpory a rozvoje Informačního systému musela činit minimálně 6 mil. Kč bez        DPH za těchto 12 měsíců (do této hodnoty se nezapočítává případná cena potřebných      licencí pro poskytování služeb podpory).

            Pro úplnost zadavatel sděluje, že požadavky na významnou službu dle písm. a) až e)       musí být splněny všechny kumulativně.«

139.     V čl. 2.5.2 „Technická kvalifikace dle § 79 odst. 2 písm. c) a d) ZZVZ“ kvalifikační dokumentace zadavatel stanovil požadavek na prokázání splnění kritéria technické kvalifikace dle § 79 odst. 2 písm. c) a d) zákona, a to předložením seznamu techniků, kteří se budou podílet na realizaci plnění veřejné zakázky (seznamu členů realizačního týmu), jehož přílohou budou strukturované profesní životopisy a doklady o odborné kvalifikaci členů realizačního týmu (tam kde jsou požadovány), které se budou podílet na plnění předmětu veřejné zakázky, z nichž bude vyplývat, že tito členové realizačního týmu splňují níže uvedené požadavky zadavatele.

140.     V této souvislosti zadavatel stanovil několik úrovní splnění kritéria technické kvalifikace pro jednotlivé role členů realizačního týmu, a to mimo jiné

            - „Prokazatelná znalost – doložení dokladu o školení, doložení dokladu o absolvování kurzu,      nebo nabytí požadované znalosti v praxi účastí na projektu obdobné velikosti a zaměření      doložené popisem v životopisu;

            - Reference – osobní účast na realizaci níže stanovené služby či projektu doložená popisem      v životopisu, včetně identifikace projektu, v jehož rámci byla služba realizována,             a základních kontaktních údajů na zástupce objednatele služby. “

141.     Zadavatel dále stanovil, že pokud zadavatel požaduje u jednotlivých pozic prokazatelnou znalost, praxi či referenci dle výše uvedených definicí, je pro prokázání požadované kvalifikace irelevantní, v jakém časovém období před zahájením zadávacího řízení daná osoba příslušnou znalost či zkušenost získala.

142.     Zadavatel stanovil následující požadované pozice v realizačním týmu: 

            - Projektový manažer,

            - Specialista pro řízení servisních služeb podpory,

            - Specialista se zaměřením na bezpečnost webových aplikací,

            - Hlavní architekt,

            - Hlavní programátor,

            - Specialista na procesní analýzu,

            - Databázový specialista,

            - Specialista UI/UIX.

            Zadavatel stanovil, že vzhledem k rozsahu předmětu veřejné zakázky a počtu     požadovaných pozic jedna osoba nemůže zastávat současně více uvedených pozic             v realizačním týmu.

143.     Zadavatel vymezil minimální úroveň pro splnění kritéria technické kvalifikace - požadavky na jednotlivé členy realizačního týmu, přičemž u člena realizačního týmu na pozici

            - hlavní architekt požadoval mimo jiné „Reference účasti na min. dvou projektech obdobné     velikosti a zaměření v roli hlavního architekta“,

            - databázový specialista požadoval mimo jiné „Reference účasti na projektu obdobné   velikosti a zaměření v roli databázového specialisty“,

            - specialista UI/UIX požadoval mimo jiné „Reference účasti na projektu obdobné velikosti             a zaměření v roli UI/UIX specialisty“.

144.     Zadavatel stanovil, že pod pojmem „projekt obdobné velikosti a zaměření“ se rozumí „takový projekt, který zahrnoval buď:

            a) realizaci Informačního systému v rozsahu dle čl. 2.5.1 – požadavky na významnou službu      dle písm. a) až d), NEBO

            b) podpora a rozvoj Informačního systému pro správu a oběh dokumentů v rozsahu       (věcném, časovém i finančním) dle čl. 2.5.1 – požadavky na významnou službu dle     písm. c) a e).“

145.     V čl. 6 „POKYNY PRO ZPRACOVÁNÍ ŽÁDOSTÍ O ÚČAST“ kvalifikační dokumentace zadavatel stanovil mimo jiné, že „pro zpracování žádosti o účast preferuje zadavatel níže uvedené řazení dokladů a dokumentů:

            - Krycí list (...);

            - Obsah žádosti o účast 

            - Doklad o společné a nerozdílné odpovědnosti (v případě podání společné žádosti o účast).

            - Doklady dle § 83 odst. 1 ZZVZ, případně doklad o společné a nerozdílné odpovědnosti dle       § 83 odst. 3 ZZVZ (v případě prokazování kvalifikace prostřednictvím třetí osoby);

            - Doklady prokazující splnění kvalifikace;

            - Doklady nad rámec kvalifikace – pro účely snížení počtu dodavatelů;

            - Ostatní doklady.“

146.     V čl. 8 „TERMÍN A PODMÍNKY PRO PODÁNÍ ŽÁDOSTI O ÚČAST“ kvalifikační dokumentace zadavatel stanovil mimo jiné, že „[l]hůta pro podání žádostí o účast končí okamžikem uvedeným v příslušném formuláři oznámení o zakázce, uveřejněném ve Věstníku veřejných zakázek. Tato lhůta je rovněž uvedena na profilu zadavatele https://nen.nipez.cz/profil/profilMsp.

Další zjištěné skutečnosti

147.     Zadavatel ve vysvětlení zadávací dokumentace č. 2 ze dne 19. 2. 2020, které bylo včetně jeho přílohy uveřejněno na profilu zadavatele dne 19. 2. 2020, uvedl následující otázku č. 2 a odpověď na ni:

Otázka č. 2: 

»V příloze ZD „eISIR_02_ZD_Projektový zámer.docx“ Zadavatel uvádí na obrázku č. 1      Schéma předpokládané aplikační architektury projektu. Popisy v tomto důležitém schématu však nejsou ani při největším zvětšení čitelné. Žádáme zadavatele o poskytnutí            schématu ve vyšším rozlišení tak, aby byl text čitelný a schéma srozumitelné.«

Odpověď na otázku č. 2:

»V příloze přikládáme čitelnější podobu schématu ve formátu pdf. Zadavatel zároveň     zdůrazňuje, že uvedené schéma má pouze orientační charakter, jak je uvedeno v zadávací          dokumentaci: „Pro zamezení nejasností se uvádí, že se nejedná o finální návrh, diagram má   sloužit výhradně pro jednodušší orientaci dodavatele v řešené problematice“.«

148.     Zadavatel ve vysvětlení zadávací dokumentace č. 2 ze dne 19. 2. 2020 uvedl dále, že tímto vysvětlením nemění zadávací podmínky, proto lhůtu pro podání žádostí o účast (3. 3. 2020 v 10:00 hod) ponechává nezměněnou.

149.     Příloha vysvětlení zadávací dokumentace č. 2 – dokument „Příloha Vysvětlení ZD č. 2 - Predpokladana aplikacni architektura eISIR eSPIS.pdf“ – obsahuje schéma, v němž jsou veškeré popisky, struktury a vazby při dostatečném zvětšení zřetelně čitelné.

150.     Ze žádosti o vysvětlení zadávací dokumentace ze dne 14. 2. 2020 plyne, že zadavatel odpovědí na otázku č. 2 ve vysvětlení zadávací dokumentace č. 2 ze dne 19. 2. 2020 odpovídal na otázku položenou navrhovatelem v uvedené žádosti.

151.     Z údajů dostupných k předmětné veřejné zakázce na profilu zadavatele plyne, že zadávací dokumentace vč. příloh, tj. vč. projektového záměru byla na profilu zadavatele uveřejněna dne 3. 2. 2020 v 14:07 hod.

152.     Ve formuláři Oznámení změn nebo dodatečných informací uveřejněného ve Věstníku veřejných zakázek dne 14. 2. 2020 (evidenční číslo formuláře: F2020-005852), konkrétně v oddílu VII.1) „Informace, které mají být opraveny nebo přidány“ je uvedena změna lhůty pro doručení nabídek nebo žádostí o účast, a to ze dne 2. 3. 2020 10:00 na 3. 3. 2020 10:00. 

153.     Z předložené dokumentace o zadávacím řízená vyplývá, že dne 3. 3. 2020 došlo k otevření žádostí o účast. Jednalo se o žádosti o účast společností:

            - IBM Česká republika, spol. s r.o., IČO 14890992, se sídlem V parku 2294/4, Chodov, 148 00   Praha 4 (dále jen „IBM Česká republika, spol. s r.o.),

            - CCA Group a.s., IČO 25695312, se sídlem Karlovo náměstí 288/17, Nové Město,             120 00 Praha 2 (dále jen „CCA Group a.s.“),

            - ICZ a.s., IČO 25145444, se sídlem Na hřebenech II 1718/10, Nusle, 140 00 Praha 4 (dále         jen „ICZ a.s.“),

  - S&T s.r.o., IČO 28973747, se sídlem U jezera 2045/6, Stodůlky, 155 00 Praha  (dále jen           „S&T s.r.o.“).

154.     Z protokolu o posouzení splnění podmínek účasti dodavatele v zadávacím řízení ze dne 31. 3. 2020 plyne, že zadavatel posoudil podmínky účasti dodavatele IBM Česká republika, spol. s r.o. jako splněné.

155.     Z protokolů o posouzení splnění podmínek účasti dodavatele v zadávacím řízení ze dne 8. 4. 2020 plyne, že zadavatel posoudil podmínky účasti dodavatele CCA Group a.s. a dodavatele ICZ a.s. jako splněné.

156.     Z protokolu o posouzení splnění podmínek účasti dodavatele v zadávacím řízení ze dne 4. 5. 2020 plyne, že zadavatel posoudil podmínky účasti dodavatele S&T s.r.o. jako splněné.

Obsah námitek ze dne 3. 3. 2020

157.     Navrhovatel v námitkách uvádí, že se zadavatel dopustil porušení zákona, když „nesprávným stanovením zadávacích podmínek pro podání a hodnocení nabídek postupoval v rozporu s požadavkem ustanovení § 6 odst. 1 a odst. 2 zákona a nedodržel základní zásady transparentnosti, přiměřenosti, rovného zacházení a zákazu diskriminace.“ Konkrétně navrhovatel zmiňuje požadavek na referenci účasti na projektu obdobné velikosti a zaměření na danou roli u pozic hlavní architekt, databázový specialista a specialista UI/UIX. Tímto postupem zadavatel dle navrhovatele bezdůvodně předem vylučuje uchazeče, kteří by jinak mohli podat žádost o účast v zadávacím řízení.

158.     Dále navrhovatel uvádí, že zadavatel „neposkytl uchazečům v čitelné podobě všechny části Zadávací dokumentace.“ K uvedenému dodává, že „[t]ím, že zadavatel po zjištění této chyby jen zveřejnil čitelný text Zadávací dokumentace, ale neprodloužil lhůtu pro podání žádostí o účast, zkrátil možným uchazečům lhůtu pro posouzení zadávací dokumentace a zadávacích podmínek.“ Tvrzené pochybení dle navrhovatele vede k omezení počtu žádostí o účast.

Právní posouzení

K výroku I. tohoto rozhodnutí

159.     Navrhovatel ve svém návrhu namítá mj. nezákonnost požadavku zadavatele na složení realizačního týmu– na pozice techniků, kteří se budou podílet na plnění veřejné zakázky – který zadavatel stanovilv čl. 2.5.2 přílohy č. 4 zadávací dokumentace v rámcipožadavků na prokázání splnění kritéria technické kvalifikace dle § 79 odst. 2 písm. c) a d) zákona (viz bod 142 odůvodnění tohoto rozhodnutí). Úřad se předně zabýval tím, zda byla naplněna základní podmínka pro to, aby se mohl touto částí návrhu zabývat věcně, spočívající ve splnění povinnosti navrhovatele před podáním návrhu podat zadavateli řádně a včas námitky. Řádnost a včasnost podaných námitek je nutné posuzovat zejména s ohledem na jejich obsah a dodržení lhůty pro jejich podání.

160.     Dle § 257 písm. h) zákona Úřad zahájené řízení usnesením zastaví, jestliže návrhu nepředcházely řádně a včas podané námitky; to neplatí pro návrhy podle § 254 zákona (pozn. Úřadu: ustanovení § 254 zákona upravuje postup v situaci podání návrhu na uložení zákazu plnění smlouvy na veřejnou zakázku). Z citovaného ustanovení zákona tak jednoznačně plyne, že podání řádných a včasných námitek je podmínkou pro meritorní projednání návrhu na přezkoumání úkonů zadavatele.

161.     Z ustanovení § 241 zákona vyplývá, že námitky může podat dodavatel, kterému postupem zadavatele souvisejícím se zadáváním podlimitní nebo nadlimitní veřejné zakázky, včetně koncese s výjimkou koncesí malého rozsahu podle § 178 zákona nebo se zvláštními postupy podle části šesté zákona hrozí nebo vznikla újma. Námitky se podávají písemně a lze je podat proti všem úkonům nebo opomenutím zadavatele v zadávacím řízení a zvláštnímu postupu podle části šesté zákona, včetně stanovení zadávacích podmínek.

162.     Úřad v obecné rovině uvádí, že námitky jsou institutem, který představuje primární ochranu dodavatelů před případným nezákonným postupem zadavatele. Zákon vymezuje konkrétní časové okamžiky v průběhu zadávacího řízení, v jejichž rámci je z pohledu stěžovatele nutné využít práva k podání námitek. Každé zadávací řízení prochází určitými fázemi a možnost obrany proti postupu zadavatele vždy odpovídá té které fázi zadávacího řízení, ve které se předmětné zadávací řízení nachází. Uvedený přístup koresponduje se zásadou právní jistoty jak všech účastníků zadávacího řízení, resp. potenciálních dodavatelů, tak i samotného zadavatele, neboť si nelze představit situaci, kdy např. v pokročilé či závěrečné fázi zadávacího řízení, kdy má dojít k provedení výběru dodavatele, budou rozporovány zadávací podmínky, podle kterých celé zadávací řízení probíhalo (viz k tomu např. na rozsudek Nejvyššího správního soudu sp. zn. 2 Afs 67/2010 ze dne 25. 1. 2011, jehož závěry, byť byl vydán ve vztahu k dnes již neúčinnému zákonu č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů, lze použít i ve vztahu k aktuální účinné právní úpravě).

163.     Ustanovení § 242 odst. 3 zákona konstruuje zvláštní lhůtu pro podání námitek výhradně proti podmínkám vztahujícím se ke kvalifikaci dodavatele, resp. jedná se o ustanovení speciální vůči obecné lhůtě pro podání námitek ve smyslu § 242 odst. 1 zákona. Jak vyplývá z ustanovení § 242 odst. 3 zákona, pokud je v zadávacím řízení stanovena lhůta pro podání žádostí o účast, musí být námitky proti podmínkám vztahujícím se ke kvalifikaci dodavatele doručeny zadavateli nejpozději do skončení této lhůty.

164.     Z dokumentace o zadávacím řízení Úřad zjistil, že v šetřeném případě zadavatel stanovil lhůtu pro podání žádostí o účast do 2. 3. 2020, 10:00 hod. a tuto lhůtu prodloužil do 3. 3. 2020, 10:00 hod. Posledním dnem, kdy mohl navrhovatel zadavateli doručit námitky proti podmínkám vztahujícím se ke kvalifikaci dodavatele, tedy mj. proti požadavku zadavatele na složení realizačního týmu(techniky, kteří se budou podílet na plnění veřejné zakázky), byl tedy den 3. 3. 2020 do 10:00 hod. V období do 3. 3. 2020, 10:00 hod., kdy v předmětném zadávacím řízení skončila lhůta pro podání žádostí o účast, tak měl navrhovatel možnost namítat nezákonnost předmětného požadavku.

165.     Z předložené dokumentace o zadávacím řízení nevyplývá (a navrhovatel to ani netvrdí), že by v průběhu zadávacího řízení na veřejnou zakázku před podáním návrhu k Úřadu doručil navrhovatel zadavateli jiné podání než námitky ze dne 3. 3. 2020, jehož obsahem by byly námitky ve smyslu § 241 a násl. zákona. Z uvedeného důvodu Úřad vycházel dále při posouzení splnění předmětné povinnosti navrhovatele (podmínky vedení správního řízení) toliko z obsahu námitek ze dne 3. 3. 2020, jakožto jediných námitek navrhovatele, které předcházely podání návrhu. Úřad k tomu doplňuje, že předmětné námitky byly podány řádně a včas (viz k tomu bod 5 odůvodnění tohoto rozhodnutí).

166.     Úřad uvádí, že přezkoumal kompletní obsah námitek ze dne 3. 3. 2020 a shledal, že námitky se vztahují k požadavkům zadavatele na reference účasti na projektu obdobné velikosti a zaměření v případě členů realizačního týmu na pozicích hlavní architekt, databázový specialista a specialista UI/UIX, a dále k neposkytnutí části zadávací dokumentace (obrázku „Schéma předpokládané aplikační architektury projektu“) v čitelné podobě, resp. jeho poskytnutí v rámci vysvětlení zadávací dokumentace bez současného prodloužení lhůty stanovené pro podání žádostí o účast (viz body 157 a 158 odůvodnění tohoto rozhodnutí).

167.     Z uvedeného tak vyplývá, že námitka týkající se tvrzené nezákonnosti požadavku zadavatele na složení realizačního týmu není v námitkách ze dne 3. 3. 2020 obsažena. Jak již bylo uvedeno výše, jiné námitky navrhovatele než námitky ze dne 3. 3. 2020 podání návrhu nepředcházely. V této souvislosti Úřad rovněž s ohledem na rozsudek Nejvyššího správního soudu č. j. 2 Afs 67/2010-105 ze dne 25. 11. 2011 uvádí, že v daném případě nic nebránilo navrhovateli případnou nezákonnost předmětného požadavku namítat vůči zadavateli ve lhůtě k tomu určené (ostatně ani sám navrhovatel nic takového netvrdí). Vzhledem ke skutečnosti, že navrhovatel námitku týkající se předmětného požadavku ve lhůtě dle § 242 odst. 3 zákona, tj. v předmětném případě do dne 3. 3. 2020, 10:00 hod., zadavateli nepodal, Úřad konstatuje, že návrhu ve vztahu k uvedené pochybnosti, resp. této části návrhu nepředcházely řádně a včas podané námitky, a proto nezbývá, než správní řízení v této části s ohledem na § 257 písm. h) zákona zastavit.

168.     S ohledem na výše uvedené skutečnosti Úřad rozhodl podle § 257 písm. h) zákona o zastavení předmětného správního řízení v části týkající se tvrzené nezákonnosti požadavku zadavatele na složení realizačního týmu (techniky, kteří se budou podílet na plnění veřejné zakázky), neboť návrhu nepředcházely v uvedené částiřádně a včas podané námitky. Z tohoto důvodu Úřad rozhodl tak, jak je uvedeno ve výroku I. tohoto rozhodnutí.

K výroku II. tohoto rozhodnutí

169.     Úřad nejprve uvádí, že zadávací podmínky jsou nejvýznamnějším zdrojem informací, na jejichž základě se dodavatelé rozhodují, zda se zúčastní zadávacího řízení a zpracovávají své nabídky a žádosti o účast. Zákon proto zadavateli ukládá povinnost vymezit jejich prostřednictvím veškeré podrobnosti nezbytné pro účast dodavatele v zadávacím řízení. Mezi tyto zadávací podmínky patří i požadavky na prokázání technické kvalifikace, pokud je zadavatel stanoví, tedy pokud hodlá technickou kvalifikaci dodavatelů pro plnění veřejné zakázky ověřovat [srov. § 28 odst. 1 písm. a) bod 2 zákona, § 36 odst. 3 zákona, § 37 odst. 1 písm. a) zákona, § 73 odst. 3 písm. b) zákona].

170.     Zadavatel je při zadávání veřejných zakázek vázán mj. základními zásadami zadávacího řízení, jež jsou upraveny v § 6 zákona. Z nich se pak zásada přiměřenosti a zákazu diskriminace nejvíce uplatňují právě při vymezení podmínek účasti, a to právě i při stanovení podmínek kvalifikace.

171.     K požadavkům na technickou kvalifikaci Úřad v obecné rovině uvádí, že při posuzování takových požadavků zadavatele je třeba vycházet z jejich účelu, kterým je objektivním, transparentním a nediskriminačním způsobem zajistit, aby zadavatel vybíral dodavatele veřejné zakázky pouze z okruhu subjektů, jež poskytují záruky o své schopnosti veřejnou zakázku řádně, včas a v odpovídající kvalitě realizovat. Adekvátně nastavená kritéria technické kvalifikace jsou tedy „sítem“, které má zamezit účasti subjektů neschopných danou veřejnou zakázku řádně splnit. K účelu stanovení technických kvalifikačních předpokladů uvedl Krajský soud v Brně již v rozsudku č. j. 62 Ca 15/2009-71 ze dne 10. 3. 2011, že „směřuje k zajištění faktické realizace veřejné zakázky toliko takovými dodavateli, kteří k tomu prokazatelně mají dostatečnou technickou způsobilost. Tím je minimalizováno zadavatelovo riziko, že dojde ke zmaření primárního účelu zadávacího řízení, kterým je řádná a efektivní realizace plnění, jež je veřejnou zakázkou. Zadavatelem uplatněné požadavky na splnění technických kvalifikačních požadavků tedy mají zajistit, aby se o přidělení veřejné zakázky účinně ucházeli pouze ti dodavatelé, kteří jsou ve skutečnosti schopni po stránce technické a materiální tuto zakázku v případě jejich úspěchu v zadávacím řízení po přidělení veřejné zakázky též plnit“.

172.     Zadavatel však také může vymezením kritérií technické kvalifikace, zejména stanovením příliš přísných kritérií prokázání způsobilosti dodavatele, výrazným způsobem ovlivnit okruh dodavatelů, mezi jejichž nabídkami bude v závěrečné fázi zadávacího řízení vybírat. Stanovení konkrétních kritérií technické kvalifikace je tak sice plně v gesci zadavatele, ten je však při jejich výběru nucen respektovat jednotlivá zákonná ustanovení, v nichž se zároveň odráží i základní zásady postupu zadavatele uvedené v § 6 zákona. Pokud by požadavky zadavatele vybočovaly z jeho oprávněných potřeb ve vztahu k dané veřejné zakázce, porušil by zadavatel jednu ze zásad postupu zadavatele vymezených v § 6 odst. 1 zákona, a sice zásadu přiměřenosti, přičemž takovým postupem by mohlo zároveň dojít i k porušení zásady zákazu diskriminace (§ 6 odst. 2 zákona), protože takové excesivní stanovení požadavků na technickou kvalifikaci by mohlo nedůvodně omezit okruh dodavatelů, kteří by se mohli zadávacího řízení zúčastnit. Zadavatel je s ohledem na dodržení základních zásad zadávacího řízení povinen stanovit kritéria technické kvalifikace takovým způsobem, aby zajistil rovné příležitosti všem dodavatelům, kteří jsou objektivně schopni předmětnou zakázku plnit.

173.     K samotné zásadě přiměřenosti (proporcionality) stanovené v § 6 odst. 1 zákona Úřad nejprve uvádí, že tato základní zásada byla do zákona přejata z nových evropských zadávacích směrnic v souvislosti s přijetím „nového“ zákona o zadávání veřejných zakázek, kde je tato zásada výslovně uvedena. Úřad podotýká, že dodržování této zásady vyplývalo i ze zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů, ačkoliv zde zásada přiměřenosti nebyla výslovně uvedena (zadavatelé však měli povinnost vymezit minimální úroveň požadavků na kvalifikaci ve vztahu k druhu, rozsahu a složitosti předmětu plnění veřejné zakázky). Explicitní zakotvení zásady přiměřenosti do zákona vychází ze skutečnosti, že zákon ponechává zadavatelům značnou míru diskrece ohledně volby konkrétního postupu v zadávacím řízení. V zadávacím řízení se přitom z povahy věci střetávají dva protichůdné principy, totiž omezení dodavatelů (způsobené zejména nastavením zadávacích podmínek zadavatelem, zejména ve vztahu k podmínkám účasti) mezi nimiž může proběhnout soutěž o nejvhodnější nabídku, pouze na ty, kteří splňují podmínky zadavatele, a u nichž je tak dán předpoklad kvalitního plnění v budoucnu, a na druhé straně obecný zájem na co nejširším zachování hospodářské soutěže. Postup v souladu se zásadou přiměřenosti tedy primárně (nikoli však výlučně) spočívá v tom, že na jedné straně zadavateli poskytuje dostatečné záruky výběru dodavatele, který skutečně bude schopen veřejnou zakázku kvalitně a v požadovaných termínech realizovat, na druhou stranu se bude jednat o postup, který nad rámec garance výše uvedeného cíle nebude dále nedůvodně omezovat hospodářskou soutěž. Jedná se tak o zásadu, kterou by se měl zadavatel řídit ve všech fázích zadávacího řízení. Úřad uvádí, že tato zásada se však nejvíce uplatňuje při stanovení podmínek účasti v zadávacím řízení, typicky u podmínek kvalifikace, které přímo determinují okruh potenciálních dodavatelů, kteří by se mohli zúčastnit zadávacího řízení.

174.     Úřad v rámci obecných východisek dále uvádí, že se zásadou přiměřenosti je úzce spjata zásada zákazu diskriminace. Porušení zásady zákazu diskriminace pak nelze vztahovat jen na diskriminaci zjevnou (přímou), tedy případ, kdy zadavatel otevřeně postupuje jinak vůči jednotlivému dodavateli a jinak vůči dalším dodavatelům, ale též na diskriminaci skrytou (nepřímou). V tomto ohledu je možno odkázat na rozsudek Krajského soudu v Brně sp. zn. 62 Ca 9/2007 ze dne 11. 10. 2007 a následný rozsudek Nejvyššího správního soudu sp. zn. 1 Afs 20/2008 ze dne 5. 6. 2008, podle kterého „[z]a skrytou formu nepřípustné diskriminace je třeba považovat i takový postup, kterým zadavatel znemožní některým dodavatelům ucházet se o veřejnou zakázku nastavením technických kvalifikačních předpokladů zjevně nepřiměřených ve vztahu k velikosti, složitosti a technické náročnosti konkrétní veřejné zakázky, v důsledku čehož je zřejmé, že zakázku nemohou splnit někteří z potenciálních uchazečů, jež by jinak byli bývali k plnění předmětu veřejné zakázky objektivně způsobilými. (…) Klíčovým problémem takto pojaté skryté diskriminace je tedy ‚zjevná nepřiměřenost‘ kvalifikačních předpokladů ve vztahu ke konkrétní veřejné zakázce. Tato zjevná nepřiměřenost není vymezitelná žádnou obecnou floskulí, nýbrž je nutno ji vykládat vždy se zřetelem na individuální kauzu. (…) V každém případě musí správní soudy při aplikaci kritéria ‚zjevné nepřiměřenosti‘ poskytnout prostor pro legitimní ekonomickou úvahu zadavatele, a tedy shledání skryté diskriminace je přípustné tam, kde kvalifikační předpoklady jsou vskutku excesivní a jasně vybočují z oprávněných potřeb dané zakázky“. Pakliže zadavatel stanoví např. nepřiměřené podmínky kvalifikace, má tento postup zadavatele negativní dopad do okruhu potenciálních dodavatelů (zužuje jej), a tedy dochází k diskriminaci dodavatelů, kteří by byli, pakliže by zadavatel vymezil své požadavky v souladu se zásadou přiměřenosti, způsobilí ucházet se o veřejnou zakázku a následně veřejnou zakázku plnit, pakliže by jim však byla dána (přiměřeným nastavením požadavků zadavatele) možnost se zadávacího řízení účastnit, resp. podat žádost o účast, resp. nabídku. K problematice zásady zákazu diskriminace lze odkázat taktéž např. na rozsudek Krajského soudu v Brně, sp. zn. 62 Ca 29/2009 ze dne 16. 3. 2011 (na který odkazuje i navrhovatel), v němž jmenovaný soud mj. uvedl: „K porušení zásady zákazu diskriminace může dojít např. tehdy, pokud zadavatel stanoví zcela nepřiměřené požadavky na prokázání splnění kvalifikace, v důsledku čehož účelově a v rozporu se zákonem omezí účast určité skupiny dodavatelů. Zadavatel je oprávněn využít prostor daný zákonem a prostřednictvím stanovení úrovně ekonomických a finančních kvalifikačních předpokladů nebo technických kvalifikačních předpokladů znevýhodnit některé dodavatele, to však pouze za předpokladu, že je to odůvodněno objektivními okolnostmi a požadavky zadavatele nejsou nepřiměřené.“ Pro úplnost Úřad dodává, že přestože se závěry soudů učiněné ve výše uvedených rozsudcích vztahují k zákonu č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů, lze závěry soudů ohledně smyslu zásady zákazu diskriminace zcela jistě aplikovat rovněž i ve vztahu k zákonu, neboť princip zásady zákazu diskriminace zůstal i v souvislosti s nynější právní úpravou zachován, tedy nezměněn.

175.     Z výše uvedeného vyplývá, že stanovení požadavků na kvalifikaci, včetně jejich minimální úrovně, nemůže vést k bezdůvodnému omezení možnosti dodavatelů účastnit se zadávacího řízení, či k jakémukoliv zvýhodnění některého z potenciálních dodavatelů na úkor dodavatelů jiných, kteří by byli taktéž objektivně schopni danou veřejnou zakázku plnit. Naopak, pokud je účelem požadavků na kvalifikaci umožnění účasti pouze těm dodavatelům, kteří jsou zakázku objektivně způsobilí plnit, musí být nastaveny tak, aby umožňovaly účast opravdu všem takto objektivně způsobilým dodavatelům. Nastavení takových kvalifikačních kritérií, která nemají vazbu na předmět veřejné zakázky nebo která jsou ve vztahu k tomuto předmětu zjevně nepřiměřená (byť k němu určitý vztah mají), tedy která ve výsledku pouze znemožní některým dodavatelům se o veřejnou zakázku ucházet, lze považovat za formu nepřípustné diskriminace v zadávacím řízení.

176.     K samotnému významu kvalifikace, resp. kritérií kvalifikace Úřad uvádí, že tyto jsou „podmnožinou“ podmínek účasti, které je zadavatel oprávněn (či v některých případech povinen) stanovit. Kvalifikace umožňuje zadavateli ověřit si na základě vlastností vážících se k osobě dodavatele, zda bude tento dodavatel schopen s vyšší mírou pravděpodobnosti plnit závazky plynoucí z realizace předmětu veřejné zakázky. Zadavatel tedy získává určitou míru jistoty, že s dodavatelem, který požadovanou kvalifikaci splnil, a který je tedy kvalifikovaný pro plnění veřejné zakázky, může uzavřít smlouvu na plnění předmětu veřejné zakázky bez větších pochybností o způsobilosti takového dodavatele splnit své závazky. Platí přitom, že povinností zadavatele je vždy stanovit kvalifikaci tak, aby požadavky na prokázání splnění kvalifikace byly odůvodněny předmětem plnění veřejné zakázky. Způsob nastavení kvalifikace zadavatelem je tedy v maximální možné míře způsobilý omezit okruh potenciálních dodavatelů (tedy omezit hospodářskou soutěž jako takovou), kteří mohou podat svoji nabídku v rámci zadávacího řízení, a proto kvalifikace musí být stanovena přiměřeně k předmětu veřejné zakázky. To, že mají být požadavky k prokázání kvalifikace nastaveny přiměřeně, vyplývá nejen ze samotných základních zásad vyjádřených v ustanovení § 6 odst. 1 zákona, ale např. ve vztahu k požadavkům zadavatele na technickou kvalifikaci je toto výslovně stanoveno i v § 73 odst. 6 zákona, kde je konkrétně uvedeno: „Pokud zadavatel požaduje prokázání ekonomické nebo technické kvalifikace, musí v zadávací dokumentaci přiměřeně vzhledem ke složitosti a rozsahu předmětu veřejné zakázky stanovit (…) minimální úroveň pro jejich splnění.“ Z právě uvedeného je tak evidentní, že zákonodárce kladl důraz na to, aby požadavky zadavatelů stanovené ve vztahu k požadavkům na prokázání technické kvalifikace dle § 79 zákona byly stanoveny způsobem, který nebude hospodářskou soutěž omezovat více než je nutné. Ustanovení § 73 odst. 6 zákona tak přímo odkazuje na výše popsanou základní zásadu – zásadu přiměřenosti.

177.     Požadavky na technickou kvalifikaci, které jsou dle zadavatele podmínkou účasti v zadávacím řízení, jsou zadávacími podmínkami dle § 28 odst. 1 písm. a) bod 2 zákona. Z ustanovení § 36 odst. 1 zákona výslovně plyne, že zadávací podmínky nesmí být stanoveny tak, aby určitým dodavatelům bezdůvodně přímo nebo nepřímo zaručovaly konkurenční výhodu nebo vytvářely bezdůvodné překážky hospodářské soutěže. Toto ustanovení tak jednak umožňuje zadavateli požadovat v zadávacím řízení plnění způsobilé naplnit potřeby zadavatele, které jsou sledovány realizací zadávacího řízení, na druhé straně chrání férovou soutěž o veřejnou zakázku. Je nepochybné, že po zadavateli nelze požadovat, aby stanovené zadávací podmínky měly na všechny dodavatele stejný dopad. Přesto případné omezení musí být vždy odůvodnitelné oprávněnými potřebami zadavatele.

178.     Úřad tedy shrnuje, že účelem požadavků na prokázání kvalifikace je objektivním, přiměřeným, transparentním a nediskriminačním způsobem zajistit, aby zadavatel vybíral dodavatele veřejné zakázky pouze z okruhu subjektů, jež poskytují záruky o své schopnosti veřejnou zakázku řádně, včas a v odpovídající kvalitě realizovat. Zadavatel však nemůže vymezením kvalifikačních kritérií, zejména stanovením nepřiměřeně přísných kritérií prokázání způsobilosti dodavatele, ovlivnit okruh dodavatelů tak, že se zadávacího řízení z důvodu nepřiměřeně a diskriminačně nastavených kritérií kvalifikace nebude moci účastnit dodavatel, který by jinak byl objektivně způsobilý veřejnou zakázku realizovat. Zadavatel se tedy musí zdržet stanovení zadávacích podmínek, které bezdůvodně omezují hospodářskou soutěž, tj. takových které nemají oporu v legitimních (odůvodněných) potřebách a očekáváních zadavatele. Případnou bezdůvodnost omezování hospodářské soutěže je nutné zkoumat zejména právě z pohledu předmětu veřejné zakázky (z pohledu existence vazby omezujících zadávacích podmínek na předmět zakázky a z pohledu jejich přiměřenosti velikosti, složitosti a technické náročnosti předmět zakázky) a z něj vyplývajících oprávněných požadavků zadavatele.

179.     Úřad se se zřetelem ke shora uvedeným obecným východiskům ve smyslu naplnění požadavků zákona co do zásady přiměřenosti a zákazu diskriminace v šetřené věci zabýval posouzením požadavků na prokázání splnění kritéria technické kvalifikace dle § 79 odst. 2 písm. d) zákona stanovených v čl. 2.5.2 „Technická kvalifikace dle § 79 odst. 2 písm. c) a d) ZZVZ“ přílohy č. 4 zadávací dokumentace, a to v intencích návrhu, konkrétně tedy požadavků zadavatele na reference účasti na projektu obdobné velikosti a zaměření v případě členů realizačního týmu na pozicích hlavní architekt, databázový specialista, specialista UI/UIX v příslušné roli (viz bod 143 odůvodnění tohoto rozhodnutí).

180.     Navrhovatel spatřuje nepřiměřenost a z toho plynoucí diskriminační charakter v požadavku na referenci účasti na projektu obdobné velikosti a zaměření u členů na shora uvedených pozicích v realizačním týmu (v případě pozice hlavního architekta jde o požadavek účasti na dvou takových projektech), a to vzhledem k tomu, jak zadavatel projekt obdobné velikosti a zaměření vymezil, resp. k jeho velikosti a vzhledem k předmětu veřejné zakázky. 

181.     Projekt obdobné velikosti a zaměření zadavatel definoval s využitím jím stanovené definice významné dodávky/služby, a to ve dvou variantách (viz body 138 a 144 odůvodnění tohoto rozhodnutí). Z uvedeného plyne, že shora uvedení tři členové týmu musí mít po jedné a hlavní architekt po dvou účastech v příslušné roli na projektu, který zahrnuje realizaci informačního systému pro správu a oběh dokumentů a splňuje níže uvedené požadavky a) až d), NEBO zahrnuje podporu a rozvoj informačního systému pro správu a oběh dokumentů a splňuje níže uvedené požadavky c) a e):

a)           Významná dodávka/služba spočívající v realizaci informačního systému pro správu               a oběh dokumentů (dále jen „Informační systém“);

b)           Předmět významné služby musel spočívat v zajištění následujících činností:

              i)          analýza (zejména procesní analýza a návrh uživatelského rozhraní),

              ii)         zpracování detailního implementačního plánu Informačního systému,

              iii)        implementace, integrace a konfigurace Informačního systému,

              iv)        pilotní provoz (tj. provoz před spuštěním běžného provozu realizovaný                           v rozsahu běžného provozu, běžnými uživateli s reálnými / ostrými daty),                          proces             akceptačního testování (testování v testovacím prostředí                                        prostřednictvím testerů s testovacími daty) a předávání Informačního                                        systému do běžného provozu,

              v)         zpracování uživatelské, provozní, architektonické a technické dokumentace                      Informačního systému,

c)           Informační systém, který byl předmětem významné služby, musel dále splňovat                          následující kritéria:

              i)          Informační systém obsahoval integrační vazby na jiné informační systémy,

              ii)         objednatelem požadovaný počet spravovaných dokumentů byl min 400.000,

              iii)        požadovaný počet pravidelně přistupujících unikátních uživatelů byl dle                            objednatele měsíčně min 300,

              iv)        3 vrstvá architektura (obsahující prezenční, aplikační a databázovou vrstvu                           s přístupem pomocí webového klienta).

d)           hodnota významné dodávky/služby za plnění definované pod písm. a) až c) výše               musela činit minimálně 30 mil. Kč bez DPH, a současně

e)           součástí významné dodávky/služby muselo být také kontinuální poskytování služeb           podpory a rozvoje Informačního systému po dobu minimálně 12 měsíců, přičemž                      hodnota podpory a rozvoje Informačního systému musela činit minimálně 6                                   mil. Kč bez DPH za   těchto 12 měsíců (do této hodnoty se nezapočítává případná                    cena potřebných licencí pro poskytování služeb podpory).

182.     V zadávací dokumentaci je uvedeno, že zadavatel není objektivně schopen vymezit veškeré technické podmínky a další požadavky na plnění veřejné zakázky. Je však schopen definovat účel plnění veřejné zakázky (vytvoření informačního systému elSIR, nasazení tohoto systému do prostředí justice, zajištění provozu, podpory a rozvoje vytvořeného informačního sytému). V zadávací dokumentaci a jejích přílohách, zejména v příloze č. 2 – v projektovém záměru zadavatel poskytl dodavatelům informace o své představě o předpokládaném budoucím předmětu plnění. 

183.     Úřad na tomto místě uvádí stručný a rámcový popis záměru zadavatele a cíle soutěžního dialogu, resp. popis předpokládaného předmětu veřejné zakázky, jak plyne ze zadávací dokumentace a jejích příloh. V podrobnostech Úřad odkazuje na část odůvodnění tohoto rozhodnutí, ve které uvádí zjištěné skutečnosti. Ucelený a podrobný popis je obsažen právě v zadávací dokumentaci a jejích přílohách, které tvoří součást spisového materiálu tohoto správního řízení.  

184.     Obecným záměrem zadavatele je vytvoření nového informačního systému justičního elektronického spisu a jeho nástavby pro agendu insolvenčního řízení (dále též jen „elSIR"), nasazení tohoto systému do prostředí justice a zajištění provozu, podpory a rozvoje vytvořeného informačního sytému. Zadání této veřejné zakázky směřuje k tomu, aby bylo nalezeno řešení informačního systému elSIR, které by odpovídalo představám zadavatele a respektovalo všechny jeho požadavky, jakož i požadavky kladené na činnost zadavatele a veškeré právní předpisy.

185.     Předmětná veřejná zakázka „Vývoj a implementace eISIR a společných částí“ je součástí projektu eJustice 2020 – část eISIR[4]. Zadavatel má za cíl tímto projektem vybudovat technologicky moderní systém (souhrnně označovaný „Systém eISIR“) splňující legislativní požadavky, dále požadavky na způsob evidence spisů a bezpečnost dat.

186.     Předmětem veřejné zakázky je návrh, implementace, nasazení a provoz:

  - elektronického insolvenčního rejstříku eISIR,

  - sdílených služeb pro práci s dokumenty eSPIS,

  - nového systému elektronické spisové služby splňujícího národní standard,

  - dalších sdílených podpůrných služeb aplikací zahrnujících Registr jmen, Číselníky, Rozvrh       práce a Centrální tvorbu dokumentů (centrální sdílené aplikace, souhrnně označovány jako      „Centrum justice“).

187.     Cílem veřejné zakázky je rovněž vytvoření sdílených služeb pro práci s dokumenty eSPIS (eSPIS je modulární informační systém pro správu dokumentů a spisů v rezortu justice, přičemž součástí dodávky eSPIS je dodání elektronické spisové služby). Tyto služby budou integrovány se spisovou službou („eSSL“) s využitím webových služeb definovaných v Národním standardu elektronických systémů spisových služeb („NSESSS“). eSPIS tak bude splňovat podmínky stanovené zákonem č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů, ve znění pozdějších předpisů, prováděcích předpisů k zákonu a bude v souladu s Národním standardem pro elektronické systémy spisové služby. Mezi zásadní funkce eSPISu patří:

  - zajištění správy dokumentů a vedení spisového materiálu,

  - odesílání a příjem dokumentů, integrace s elektronickou podatelnou,

  - vzdálené nahlížení do spisu přes internet pro oprávněné osoby,

  - napojení na základní registry, rejstříky a evidence,

  - práce se spisem,

  - pomocné administrativní funkce pro rozhodovací činnost (chytré vypořádání námitek,            vyznačování poznámek v textu aj.),

  - prezenční režim spisového materiálu,

  - digitální archivace a skartační řízení dokumentů.

Dále je cílem zakázky vytvoření nadstavbového Systému eISIR pro agendu insolvenční.

188.     Celý Systém eISIR musí být vytvořen jako procesně orientovaný. eSPIS musí umožnit modulární napojení dalších nadstavbových aplikací prostřednictvím webových služeb splňujících integrační standardy MSp. Součástí integrace jsou dále napojení na zásadní prvky eGovermentu, jako je Národní identitní autorita – NIA, Informační systém datových schránek – ISDS,integrace se základními registry ROS, ROB, RÚIAN, propojeného datového fondu prostřednictvím eGON Service Bus – eGSB, Jednotný identitní prostor a katalog autentizačních a autorizačních služeb („JIP/KAAS“), Národní katalog otevřených dat („NKOD“) a dále pak možnost nahlížení do spisu na Portálu občana.

189.     Podpůrné části – aplikace Centra Justice – představují množinu aplikačních komponent a systémů, které budou do budoucna využívány alespoň dvěma různými agendovými informačními systémy („AIS“) justice. Tento koncept má za úkol eliminovat do budoucna duplicitní ukládání záznamů a vznik duplicitních nástrojů a spojů mezi jednotlivými systémy justice. Dvě komponenty v rámci Centra justice a programu eJustice 2020 jsou již vytvořeny či ve vývoji, jedná se o Registr justičních činitelů („ReJČ“) a Generátor přidělování („eGP“) – nástroj pro přidělování soudních věcí s prvkem náhody. Tyto obě komponenty budou integrovány do Systému eISIR resp. eSPIS.

190.     Jednotlivé komponenty řešení budou implementovány jako samostatné služby (či mikroslužby – microservices) vzájemně propojené prostřednictvím jasně definovaného standardního API zadavatele, tedy využitím webových služeb, integrační platformy či message brokeru.

191.     Součástí předmětu plnění jsou analytické práce, vývoj, implementace a integrace celého Systému eISIR do prostředí zadavatele, migrace definovaných dat, pilot Systému eISIR a zajištění provozu, podpory a rozvoje vytvořeného Systému eISIR po dobu pěti let.

192.     Součástí předmětu plnění je i integrace řady stávajících nebo budoucích systémů a aplikací, které samotné nejsou součástí dodávky (blíže viz bod 108 odůvodnění tohoto rozhodnutí).

193.     Zadavatel předpokládá využití řady technologií a technologických standardů vyjmenovaných v projektovém záměru, které musí dodavatel prokazatelně ovládat pro řádné plnění veřejné zakázky (blíže viz bod 124 odůvodnění tohoto rozhodnutí).

194.     V rámci dodávky Systému eISIR zadavatel požaduje 3 kompletní prostředí (vývojové, testovací a produkční prostředí).

195.     Pokud jde o „Požadavky na front-end Systému eISIR“, zadavatel stanovil požadavky na uživatelské rozhraní, konkrétně na personifikaci uživatelského rozhraní, interní rozhraní a přístupnost Systému eISIR (blíže viz body 130 a 131 odůvodnění tohoto rozhodnutí). V této souvislosti zadavatel stanovil mimo jiné, že rozhraní Systému eISIR musí být v souladu s § 4 a § 5 zákona č. 99/2019Sb., o přístupnosti internetových stránek a mobilních aplikací a o změně zákona č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů.

196.     Součástí dodávky je rovněž dokumentace (technická, provozní, uživatelská, bezpečnostní, programátorská, analytická a model architektury systému eISIR a jeho okolí). Jako součásti uživatelské dokumentace zadavatel požaduje administrátorskou dokumentaci, detailní instalační příručku, seznam standardních provozních úkonů a pracovních postupů, detailní popis správy uživatelů a rolí, detailní uživatelskou příručku, jednoduchou uživatelskou příručku pro externí uživatele (dostupnou z webu) a uživatelské testovací scénáře.

197.     Součástí technické dokumentace k Systému eISIR bude také detailní popis architektury Systému eISIR v přehledných schématech včetně uvedení relací mezi komponentami, popis high level architektury na třech vrstvách architektury (byznys vrstva, aplikační vrstva, technologická vrstva), detailní popis databázového schématu včetně relací.

198.     Zadavatel stanovil následující odhad hlavních entit Systému eISIR (dále též jen „vytíženost“):

  - 200 tis. aktivních spisů,

  - 23 až 32 tis. roční přírůstek spisů,

  - 120 tis. přijatých elektronických podání za rok,

  - 10 mil. dokumentů v rámci insolvenčního řízení,

  - 2000 uživatelů typu administrativní pracovníci (intenzivně pracují se Systémem eISIR většinu pracovní doby, zpracovávají úkoly, vkládá informace, apod.),

  - 700 uživatelů typu soudci a referenti (využívají Systém eISIR více staticky, čtou a vytváří         dokumenty, vytváří úkoly, apod.),

  - 100 uživatelů typu správci a administrátoři (Systém eISIR zatěžují minimálně),

  - návštěvnost veřejného insolvenčního rejstříku 15 tis. přístupů denně.

199.     Předpokládaná hodnota veřejné zakázky (tedy bez podpory a servisu) činí přes 158 mil. Kč bez DPH.

200.     Systém eISIR bude provozován na všech insolvenčních soudech a jejich pobočkách a na Ministerstvu spravedlnosti. Část Systému eISIR (veřejný insolvenční rejstřík) bude veřejně přístupná a bude od zbytku eISIRu oddělena a provozována ve speciálním režimu, přičemž jsou do ní eISIRem přenášena data z jeho interních komponent.

201.     V zadávací dokumentaci je rovněž popsána předpokládaná aplikační architektura Systému eISIR, základní principy integrace služeb informačních systémů, základní principy návrhu uživatelských rozhraní a základní principy práce s dokumenty a spisy (viz bod 119123 odůvodnění tohoto rozhodnutí).

202.     Dále jsou v zadávací dokumentaci uvedeny informace o odezvách Systému eISIR na typizované uživatelské dotazy, dostupnosti Systému eISIR, odhadu hlavních entit Systému eISIR a škálovatelnosti (blíže viz body 125126 odůvodnění tohoto rozhodnutí) a rovněž informace o kritické infrastruktuře, provozu veřejné části eISIRu na oddělené infrastruktuře, autentizaci a autorizaci, Syslogu, dalším logování, SSO v rámci všech komponent Systému eISIR a o provozní monitoringu (blíže viz body 127129 odůvodnění tohoto rozhodnutí).

203.     Systém eISIR je součástí kritické informační infrastruktury dle zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti), ve znění pozdějších předpisů.

204.     Systém eISIR nebo jeho části musí být také v souladu s

  - interními bezpečnostními instrukcemi a politikami Ministerstva spravedlnosti,

  - zákonem č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů,   ve znění pozdějších předpisů,

  - Národním standardem pro elektronické systémy spisové služby,

  - zákonem č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů,

  - zákonem č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací   a o změně zákona č. 365/2000 Sb., o informačních systémech veřejné správy a o změně           některých dalších zákonů, ve znění pozdějších předpisů.

205.     Na základě popisu předpokládaného předmětu veřejné zakázky, požadavků zadavatele plynoucích z jeho potřeb, resp. z funkcí a účelu, ke kterému má Systém eISIR sloužit (jak plyne ze zadávací dokumentace veřejné zakázky a jejích příloh) a s přihlédnutím ke skutečnostem, které uvedl k Systému eISIR zadavatel ve svém vyjádření k návrhu a v rozhodnutí o námitkách (viz body 24 a 25 odůvodnění tohoto rozhodnutí), je dle Úřadu patrné, že předmětem veřejné zakázky je vyvinutí, implementace, nasazení, provoz a několikaletá podpora a rozvoj značně rozsáhlého, složitého a technicky náročného a sofistikovaného systému veřejné správy. Dle Úřadu tedy lze považovat za legitimní a přiměřené, aby si zadavatel nechal prokázat odbornou kvalifikaci (konkrétně zkušenost) osob, které se budou podílet na plnění veřejné zakázky na pozicích, které jsou pro řádné plnění veřejné zakázky zásadní, a to mimo jiné předložením reference účasti těchto osob na jiném projektu (nebudou-li požadavky na tento jiný projekt nepřiměřené vzhledem k předmětu zadávané veřejné zakázky).

206.     Za takové zásadní pozice lze nepochybně považovat i pozice hlavního architekta, databázového specialisty a specialisty UI/UIX (jako odborníka na uživatelské rozhraní/prostředí a použitelnost systému), a to z důvodu činnosti těchto členů realizačního týmu ajejich odpovědnosti, která je spjata s těmito pozicemi jak obecně, tak i v případě plnění předmětné veřejné zakázky, tj. vzhledem k zamýšlenému Systému eISIR (jeho již shora popsané a zhodnocené povaze) jako takovému – konkrétně tedy mj. k jeho předpokládané architektuře, databázím a dalším komponentům (vč. elektronické spisové služby a elektronického insolvenčního rejstříku), vazbám a funkcionalitám, k potřebě provedení migrace dat ze stávajícího systému do nového systému, k vysokým nárokům na ukládání množství dat, na přístup k nim a manipulaci s nimi, a na bezpečnost, efektivitu, funkčnost a front-end systému,uživatelské rozhraní a prostředí systému (sloužící množství uživatelů vč. veřejnosti), tedy na samotnou použitelnost a přístupnost systému dle potřeb zadavatele, potažmo uživatelů a dle legislativních požadavků – a dále také vzhledem k potřebě zajištění následné podpory a rozvoje tohoto systému. V této souvislosti lze také odkázat na stanovení výslovného požadavku zadavatele na využití relevantních technologií a technologických standardů, které musí dodavatel dle zadávací dokumentace prokazatelně ovládat pro řádné plnění veřejné zakázky, kdy se jedná mimo jiné o architekturu aplikací využitím vzorů MVC, MVVC či obdobných, architektonický návrh v notacích ArchiMate, UML a BPMN, webové, desktop a mobilní uživatelské rozhraní, principy UX/UIX (User/InterfaceExperience), SPA (Single pageapplication), Databáze, SQL.

207.     Důvodnost a přiměřenost požadavku zadavatele na reference účasti těchto osob na jiném projektu je v šetřeném případě podtržena i účelem, ke kterému má zamýšlený Systém eISIR sloužit, a tedy i skutečností, že půjde o systém veřejné správy a součástkritické informační infrastruktury, z čehož plyne, že bude muset splňovat navíc požadavky vyplývající z příslušných právních předpisů, mj. zákona č. 365/2000 Sb., o informačních systémech veřejné správy a o změně souvisejících některých dalších zákonů a zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti), ve znění pozdějších předpisů.

208.     Ke skutečnosti, že zadavatel v případě pozice hlavního architekta stanovil vyšší úroveň zkušeností člena realizačního týmu na této pozici, když požaduje referenci účasti na minimálně dvou projektech obdobné velikosti a zaměření v dané roli (oproti účasti na jednom projektu v případě pozic databázového specialisty a specialisty UI/UIX), Úřad uvádí následující.

209.     Pozici hlavního architekta, resp. architekta systému lze považovat za stěžejní roli při návrhu, realizaci a dalším rozvoji informačního systému jako celku, resp. v celém životním cyklu informačního systému.

210.     Člen realizačního týmu na této pozici navrhuje a zastřešuje základní koncept a strukturu systému jako celku s ohledem na jeho účel, kapacitu, současné i možné budoucí požadavky uživatelů/zadavatele, nachází optimální řešení mezi potřebami uživatelů/zadavatele a technickými možnostmi. Architektura systému musí vyhovovat současným i budoucím známým nebo předvídatelným funkčním, informačním, kvalitativním a ekonomickým požadavkům.

211.     Na pozici architekta systému jsou kladeny značné nároky, má-li být schopen zpracovat návrh architektury systému řádně, resp. co nejlépe (při daných požadavcích, technických a ekonomických možnostech, předpokladu dalšího vývoje apod.), pokud jde o veškeré parametry návrhu, jako jsou vyhovění požadavkům zadavatele/uživatelů, vyhodnotit užitečnost jednotlivých požadavků, nalézt za tímto účelem vhodná a ekonomická řešení, předvídat další vývoj systému a s ohledem na to jej navrhovat, zajistit dostatečnou a správnou míru flexibility systému, škálovatelnost, provozovatelnost, dostupnost, stabilitu, otevřenost (schopnost kooperace nebo integrace systému s jinými systémy) a v neposlední řadě rovněž bezpečnost systému. 

212.     Pro zpracování návrhu architektury a řízení architektury systému musí mít architekt schopnost užívat na potřebné úrovni odpovídající nástroje a prostředky, být schopen pochopit situaci, podmínky a potřeby, predikovat vývoj potřeb a systému, znát technologie, nalézat řešení a komunikovat jej vůči zadavateli a ostatním členům realizačního týmu odpovídajícím způsobem (pravidly, standardy, osobně), kontrolovat a korigovat vývoj systému. Činnost architekta má i manažerskou složku. Architekt tedy musí mít i určité manažerské dovednosti, být schopen plánovat, organizovat, ovlivňovat atd. Pro uvedené znalosti, schopnosti a dovednosti, které mohou mít značný dopad na výsledek činnosti celého realizačního týmu, tedy informační systém jako celek, jeho použitelnost a budoucnost, má velký význam osobní zkušenost s činností na této pozici. S rolí hlavního architekta je tedy spojena i značná míra odpovědnosti za činnost realizačního týmu, resp. jeho výsledky a vyšší míra odpovědnosti za projekt jako takový.

213.     Vzhledem k uvedenému má zkušenost hlavního architekta s jinými projekty v odpovídající roli značný význam i pro řádné a včasné plnění předmětu šetřené veřejné zakázky. Vyšší požadavek v podobě reference účasti na minimálně dvou projektech obdobné velikosti a zaměření je tedy v případě pozice hlavního architekta důvodný a nelze jej považovat bez dalšího za zjevně excesivní.

214.     Úřad nepřehlíží, že v první (kvalifikační) fázi zadávacího řízení se soutěžním dialogem není zcela úplný, podrobný a především definitivní popis předmětu veřejné zakázky znám, neboť ten bude znám až v návaznosti na jednání s účastníky zadávacího řízení s ohledem na technická řešení nalezená v další fázi zadávacího řízení (tj. ve fázi soutěžního dialogu). Tato skutečnost nicméně obecně a ani konkrétně v šetřeném případě nebrání tomu, aby zadavatel stanovil kritéria technické kvalifikace dodavatelů a minimální úrovně pro jejich splnění, které budou přiměřené předmětu veřejné zakázky, jak je znám v dané fázi zadávacího řízení. V šetřeném případě Úřad neshledává nedostatek informací o předmětu plnění veřejné zakázky, který by znemožnil stanovit požadavky na prokázání splnění kritéria technické kvalifikace dle § 79 odst. 2 písm. d) zákona stanovením požadavku na předložení reference účasti na obdobném projektu (se současným definováním obdobného projektu) v příslušné roli pro pozice hlavního architekta, databázového specialisty a specialisty UI/UIX.

215.     Vzhledem k tomu, že zadavatel nestanovil v případě uvedených tří pozic v realizačním týmu požadavek na reference účasti na libovolném projektu v příslušné roli, nýbrž na projektu obdobné velikosti a zaměření, přičemž definoval, co se tímto projektem obdobné velikosti a zaměření rozumí, Úřad se zabýval přiměřeností takto definovaného projektu předmětu veřejné zakázky.

216.     Úřad uvádí, že navrhovatel výslovně nerozporuje žádné konkrétní parametry projektu obdobné velikosti a zaměření a neuvádí, jaké by případně mohly nebo měly být, aby bylo možné nastavení projektu obdobné velikosti a zaměření považovat za přiměřené a nediskriminační.

217.     Zadavatel stanovil dvě částečně se překrývající varianty projektu obdobné velikosti a zaměření. Jedna varianta spočívá v projektu, který zahrnoval realizaci informačního systému pro správu a oběh dokumentů a splňuje další zadavatelem stanovené požadavky [shora pod písm. b) až d)] týkající se činností, které měly být v rámci dodání systému vykonávány nebo stanovených parametrů systému, dále „vytíženosti“ informačního systému (počet spravovaných dokumentů a počet pravidelně přistupujících unikátních uživatelů) a hodnoty zakázky na dodání systému (viz bod 181 odůvodnění tohoto rozhodnutí). 

218.     Druhá varianta spočívá v projektu, který zahrnoval podporu a rozvoj informačního systému pro správu a oběh dokumentů a splňuje zadavatelem dále [shora pod písm. c) a e)] stanovené požadavky týkající se stanovených parametrů systému, dále „vytíženosti“ informačního systému (počet spravovaných dokumentů a počet pravidelně přistupujících unikátních uživatelů), minimální doby kontinuálního poskytování těchto služeb a hodnoty těchto služeb za danou dobu (viz bod 181 odůvodnění tohoto rozhodnutí). Tato varianta ve srovnání s předchozí nezahrnuje hodnotu dodání vlastního informačního systému, zajištění činností, které měly být v rámci dodání systému vykonávány a hodnotu zakázky na dodání systému. Tato varianta se tedy zaměřuje především na poskytování služeb podpory a rozvoje informačního systému, který má stanovené parametry a na hodnotu této služby.

219.     Úřad uvádí, že požadavky na předmět plnění projektu obdobné velikosti a zaměření a činnosti v rámci tohoto projektu realizované (stanovené v rámci jedné nebo i obou variant projektu obdobné velikosti a zaměření) reflektují předmět šetřené veřejné zakázky, resp. činnosti předpokládané v rámci plnění šetřené veřejné zakázky, event. dílčí výsledky plnění šetřené veřejné zakázky.  Jedná se navíc o obecně vymezené činnosti a požadavky na informační systém (např. implementace, integrace a konfigurace informačního systému, požadavek na integrační vazby na jiné informační systémy, kontinuální poskytování služeb podpory a rozvoje informačního systému atd.), které nejsou specifické a běžně se uplatní v projektech na komplexní realizaci informačních systémů a jejich podporu a rozvoj od analýzy, přes uvedení do provozu až po poskytování služeb podpory a rozvoje, a to i v podobě kombinace těchto jednotlivých činností a požadavků a nejen v oblasti veřejné správy.

220.     Pro úplnost se Úřad vyjádří i ke skutečnosti, že požadavky na předmět plnění projektu obdobné velikosti a zaměření a na činnosti v rámci tohoto projektu realizované (stanovené v rámci jedné nebo i obou variant projektu obdobné velikosti a zaměření) nespočívají výlučně v činnostech, jejichž zajištění pro plnění předmětné veřejné zakázky lze očekávat od hlavního architekta, databázového specialisty a specialisty UI/UIX, nebo nespočívají ve výsledcích činnosti výlučně těchto členů realizačního týmu. Tato skutečnost nečiní požadavek na referenci účasti na projektu obdobného velikosti a zaměření v příslušné roli v případě uvedených členů realizačního týmu bezdůvodným a zjevně excesivním. Tato skutečnost pouze reflektuje předmět veřejné zakázky včetně jeho rozsahu, složitosti, technické náročnosti a komplexnosti činností zajišťovaných při jeho plnění (širšího spektra činností neomezujícímu se na činnosti předmětných tří členů týmu) a rovněž včetně provázanosti jak těchto činností, tak dílčích částí Systému eISIR. Z uvedeného jasně plyne, že požadavek účasti člena realizačního týmu v příslušné roli na „projektu obdobné velikosti a zaměření“ (tedy projektu o určitém zadávané zakázce odpovídajícím minimálním předmětu, velikosti a složitosti) nesouvisí pouze se samotnou náplní práce daného člena realizačního týmu, ale také s jeho schopností koordinovat svou činnost v rámci rozsáhlého projektu s ostatními členy realizačního týmu a orientovat se napříč celým projektem tak, aby bylo možné zajistit a garantovat fungování realizačního týmu jako celku (na což ostatně poukazuje i zadavatel ve svém vyjádření).

221.     Pokud jde o zbývající požadavky, které se týkají „vytíženosti“ informačního systému (počet spravovaných dokumentů a počet pravidelně přistupujících unikátních uživatelů), hodnoty dodávky systému a služby podpory a rozvoje a délky jejího poskytování, Úřad nejprve konstatuje, že již vzhledem k samotnému faktu absence konkrétní argumentace navrhovatele ve vztahu k těmto požadavkům (např. že požadavkem zadavatele dojde k „udušení“ trhu, neboť týmem s požadovanými zkušenostmi disponuje toliko jeden dodavatel apod.) nelze považovat nastavení projektu obdobné velikosti a zaměření za zjevně excesivní z důvodu těchto požadavků.

222.     Pro úplnost však Úřad uvádí, že pokud jde o minimální požadavky na počet spravovaných dokumentů (400 tis.), počet pravidelně přistupujících uživatelů (300), které zadavatel stanovil v rámci obou variant projektu obdobné velikosti a zaměření, a hodnotu projektu bez ceny za podporu a rozvoj (30 mil.), kterou zadavatel stanovil v rámci jedné z variant projektu obdobné velikosti a zaměření [písm. c) a d)], tyto hodnoty mohou vypovídat o kvalifikaci pro řádné plnění mnohem většího projektu a současně při jejich srovnání s relevantními hodnotami předpokládanými v šetřené zakázce (10 mil. dokumentů, 2 800 uživatelů, předpokládaná hodnota přes 158 mil. Kč) je patrné, že jsou výrazně nižší. Tyto požadavky tedy ve vztahu k odhadované „vytíženosti“ zamýšleného Systému eISIR nelze považovat za jakkoli přemrštěné a nebudí podezření na jejich zevně excesivní nastavení, které by se mohlo vymykat legitimní potřebě zodpovědného zadavatele z objektivních důvodů ověřit kvalifikaci dodavatele, který by měl být schopen řádně a včas plnit veřejnou zakázku o mnohonásobně (až řádově) větší „vytíženosti“ a hodnotě, než kterou zadavatel stanovil pro projekt obdobné velikosti a zaměření.   

223.     Minimální požadovaná délka poskytování služeb podpory a rozvoje (12 měs.), kterou zadavatel stanovil v rámci jedné varianty projektu obdobné velikosti a zaměření, je relativně běžnou (minimální) délkou poskytování podpory a rozvoje informačního systému, která může vypovídat o kvalifikaci dodavatele – jeho zkušenostech při podpoře a rozvoji v návaznosti na množství a spektrum potřeb a situací, které mohou v daném období nastat a které si poskytnutí služeb podpory a rozvoje vyžádají. Při srovnání s délkou poskytování těchto služeb v rámci šetřené zakázky (5 let) rovněž tento požadavek nelze považovat za jakkoli přemrštěný a nebudí podezření na jejich zevně excesivní nastavení, a to zejména vezmeme-li v potaz značnou velikost, složitost a technickou náročnost, množství uživatelů, spravovaných dokumentů, integrační vazby na jiné informační systémy (požadované i v rámci projektu obdobné velikosti a zaměření) apod., které se mohou projevit v podobě potřeby podpory a rozvoje systému již během relativně krátkého období jednoho roku. Uvedené lze vztáhnout i na požadavek na minimální hodnotu těchto služeb (6 mil/ 12 měs.).

224.     Úřad tedy shrnuje, že uvedené dvě varianty projektu obdobné velikosti a zaměření mají vazbu na předpokládaný předmět veřejné zakázky a s ohledem na shora uvedené je nelze v kontextu šetřené veřejné zakázky považovat za zjevně excesivní, potažmo nepřiměřené a nepřípustně diskriminační a vytvářející bezdůvodné překážky hospodářské soutěže, a to ani vzhledem ke skutečnosti, že stanovené požadavky je třeba v rámci jednotlivé varianty projektu splnit všechny.  

225.     Pokud jde o názor navrhovatele, že pozici databázového specialisty a specialisty UI/UIX může na projektu zastávat jakýkoli osoba s uvedenou kvalifikací, neboť se jedná o obecné role, u níž není kvalita jejich výkonu podmíněna tím, že se tito členové realizačního týmu podíleli na realizaci jiné obdobné zakázky, neboť úkoly, které tyto osoby vykonávají, jsou dle názoru navrhovatele obdobné bez ohledu na velikost realizované zakázky, Úřad tento názor nesdílí a uvádí k tomu následující. Přistoupení na tuto argumentaci by znamenalo, že by z hlediska záruky řádného a včasného plnění bylo irelevantní, zda členové realizačního týmu mají na těchto pozicích vůbec nějakou zkušenost v dané roli, což však vzhledem k zásadnímu významu těchto pozic jak obecně, tak i pro realizaci předmětné veřejné zakázky (zejména s přihlédnutím k její povaze co do velikosti, složitosti a technické náročnosti) není namístě. Ve svém důsledku by se zadavatel (pokud by rezignoval na ověření určité minimální zkušenosti těchto členů realizačního týmu získané účastí na jiném projektu) vystavoval riziku, že dojde ke zmaření účelu zadávacího řízení, kterým je řádná a efektivní realizace předmětu veřejné zakázky. Nelze po zadavateli požadovat, aby takové riziko podstupoval. V této souvislosti lze dále poukázat na význam účasti zásadních členů realizačního týmu v jiném projektu, resp. projektu obdobné velikosti a zaměření i z pohledu nezbytnosti určité zkušenosti těchto členů týmu s orientací v rozsáhlém projektu a s kooperací s ostatními členy realizačního týmu v rámci takového projektu, jak o tom Úřad pojednal již shora v odůvodnění tohoto rozhodnutí.

226.     Úřad také zohlednil skutečnost, že zadavatel stanovil dvě varianty projektu obdobné velikosti a významu, čímž do jisté míry rozšířil okruh možných osob, kteří by byli kvalifikovaní pro dané pozice v realizačním týmu (v tom smyslu, že daný člen realizačního týmu má více možností, jak může tento požadavek splnit, tj. v případě, že nesplňuje požadavek na účast v jedné variantě projektu, může jej splnit prostřednictvím účasti v druhé variantě projektu). Zadavatel tím pádem rozšířil i okruh možných dodavatelů, kteří by požadovaná kritéria technické kvalifikace podle § 79 odst. 2 písm. c) a d) zákona.

227.     S ohledem na shora uvedené Úřad neshledává předmětný požadavek na referenci účasti členů realizačního týmu na pozicích hlavní architekt, databázový specialista, specialista UI/UIX v příslušné roli na jiném projektu, v podobě jaké jej coby „projekt obdobné velikosti a zaměření“ definoval dokonce ve dvou variantách zadavatel, za stanovený v rozporu se zásadou přiměřenosti, zásadou zákazu diskriminace, za vytvářející bezdůvodné překážky hospodářské soutěže či za jinak odporující zákonu. Uvedené platí o kombinaci požadavků na zkušenost těchto tří členů týmu (neboť se budou podílet všichni na plnění šetřené veřejné zakázky).

228.     Nad rámec Úřad uvádí, že o skutečnosti, že předmětný požadavek neměl za následek bezdůvodné omezení hospodářské soutěže, může svědčit i skutečnost, že i přes stanovení tohoto požadavku a přes značnou velikost, složitost a technickou náročnost předmětu veřejné zakázky žádost o účast v tomto zadávacím řízení podali celkem čtyři dodavatelé a dle obsahu dokumentace o zadávacím řízení tito účastníci splnili podmínky účasti v předmětném zadávacím řízení.

229.     S ohledem na výše uvedené skutečnosti Úřad rozhodl o zamítnutí návrhu navrhovatele dle ustanovení § 265 písm. a) zákona v části týkající se požadavků zadavatele na reference účasti na projektu obdobné velikosti a zaměření v případě členů realizačního týmu (techniků, kteří se budou podílet na plnění veřejné zakázky) na pozici hlavní architekt, databázový specialista a specialista UI/UIX, neboťnebyly zjištěny důvody pro uložení nápravného opatření.Z tohoto důvodu Úřad rozhodl tak, jak je uvedeno ve výroku II. tohoto rozhodnutí.

K výroku III. tohoto rozhodnutí

230.     Dále se Úřad zabýval částí návrhu, která se týká postupu zadavatele při poskytnutí části zadávací dokumentace dodavatelům, a to obrázku 1 „Schéma předpokládané aplikační architektury projektu“ (dále též jen „obrázek architektury“ nebo „schéma architektury“) poskytnutého dodavatelům v kapitole 5.1 „Předpokládaná aplikační architektura Systému eISIR“ projektového záměru. V této části návrh směřuje konkrétně proti tomu, že zadavatel údajně poskytl obrázek architektury po nedostatečnou dobu v čitelné podobě, když jej nejdříve poskytl v nečitelné podobě a následně neprodloužil lhůtu pro podání žádostí o účast v návaznosti na poskytnutí tohoto obrázku v čitelné podobě s vysvětlením zadávací dokumentace č. 2 ze dne 19. 2. 2020.

231.     Podle navrhovatele zadavatel tímto postupem zkrátil dodavatelům lhůtu pro posouzení zadávací dokumentace, čímž nepřiměřeným způsobem omezil možný okruh dodavatelů, resp. množství dodavatelů, kteří by jinak mohli podat žádost o účast.

232.     Úřad uvádí, že schéma architektury označené „Obrázek 1 - Schéma předpokládané aplikační architektury projektu“ v podobě, která je dle navrhovatele nečitelná, bylo v rámci zadávací dokumentace uveřejněno na profilu zadavatele od 3. 2. 2020, 14:07 hod. (dále též jen „původně uveřejněné schéma architektury“). Od téhož dne byla na profilu zadavatele uveřejněna celá zadávací dokumentace vč. jejích příloh.

233.     V souvislosti se schématem architektury bylo v zadávací dokumentaci uvedeno, že dané schéma „znázorňuje logickou strukturu aplikací a jejich vazeb (notace ArchiMate 3.0). Pro zamezení nejasností se uvádí, že se nejedná o finální návrh, diagram má sloužit výhradně pro jednodušší orientaci dodavatele v řešené problematice.“

234.     Zadavatel následně dne 19. 2. 2020 v 15:57 hod. na žádost navrhovatele uveřejnil na profilu zadavatele jako přílohu vysvětlení zadávací dokumentace č. 2 totéž schéma architektury (dále též jen „nově uveřejněné schéma architektury“ nebo „schéma architektury v podobě čitelné bez obtíží v celém rozsahu“). Lhůta pro podání žádostí o účast skončila dne 3. 3. 2020 v 10:00 hod.

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

236.     Úřad v obecné rovině nejprve uvádí, že z ustanovení § 99 odst. 1 zákona vyplývá, že zadavatel je oprávněn změnit či doplnit zadávací podmínky obsažené v zadávací dokumentaci, a to za předpokladu, že ještě nedošlo k uplynutí lhůty pro podání žádostí o účast, předběžných nabídek nebo nabídek, přičemž za zadávací podmínky je podle § 28 odst. 1 písm. a) zákona třeba považovat veškeré podmínky stanovené zadavatelem týkající se průběhu zadávacího řízení, účasti v zadávacím řízení, dále zadavatelem stanovená pravidla pro snížení počtu účastníků zadávacího řízení nebo snížení počtu předběžných nabídek nebo řešení a pravidla pro hodnocení nabídek, stejně jako další podmínky pro uzavření smlouvy na veřejnou zakázku. Takovou změnu je pak zadavatel vždy povinen uveřejnit nebo oznámit dodavatelům stejným způsobem jako původní (tj. doplňovanou, měněnou) zadávací podmínku.

237.     Podle § 37 odst. 1 písm. b) zákona podmínky účasti v zadávacím řízení může zadavatel stanovit mimo jiné jako technické podmínky vymezující předmět veřejné zakázky včetně podmínek nakládání s právy k průmyslovému nebo duševnímu vlastnictví vzniklými v souvislosti s plněním smlouvy na veřejnou zakázku.

238.     Podle § 89 odst. 1 písm. a) zákona jsou technické podmínky požadavky na vlastnosti předmětu veřejné zakázky, které zadavatel stanoví mimo jiné prostřednictvím parametrů vyjadřujících požadavky na výkon nebo funkci, popisu účelu nebo potřeb, které mají být naplněny.

239.     Z dikce ustanovení § 99 odst. 2 zákona, věty první, pak dále vyplývá, že zadavatel prodlouží lhůtu pro podání žádostí o účast, předběžných nabídek nebo nabídek, a to za předpokladu, že změnil nebo doplnil zadávací podmínky a povaha této změny nebo doplnění prodloužení těchto lhůt vyžaduje. Je na zadavateli, jakou změnu provede, zákon v této souvislosti ale předpokládá jednoznačný následek, co má být dále učiněno. Lze potvrdit, že ne každá změna či doplnění zadávacích podmínek vyžaduje dle nyní platné a účinné právní úpravy prodloužení zadavatelem stanovených lhůt. Na druhé straně lze mimo jiné s ohledem na dodržení základních zásad zadávacího řízení konstatovat, že zadavatel je povinen k takovému posouzení přistupovat nanejvýš odpovědně; je povinen řádně, objektivně a komplexně posoudit povahu provedené změny. Pokud pak změna či doplnění zadávacích podmínek objektivně vyžaduje přiměřené prodloužení lhůty pro podání nabídek, předběžných nabídek či žádostí o účast, je nezbytné, aby tak zadavatel učinil a tuto lhůtu přiměřeně prodloužil.

240.     V první (kvalifikační) fázi zadávacího řízení se soutěžním dialogem není zcela úplný, podrobný a především definitivní popis předmětu veřejné zakázky znám, neboť ten bude znám až v návaznosti na jednání s účastníky zadávacího řízení s ohledem na technická řešení nalezená v další fázi zadávacího řízení (tj. ve fázi soutěžního dialogu).

241.     Jak uvedl zadavatel v zadávací dokumentaci, v úvodu zadávacího řízení (v kvalifikační fázi) dodavatelé podávají pouze žádost o účast, přičemž v této fázi zadávacího řízení slouží zadávací dokumentace dodavatelům k získání rámcové představy o předmětu plnění a hodnotících kritériích. Zadavatel dále v zadávací dokumentaci uvedl, že informace uvedené v této zadávací dokumentaci „mají dodavatelům umožnit kvalifikovanou účast v soutěžním dialogu a přípravu reakce na požadavky zadavatele tak, jak je uvedeno v této zadávací dokumentaci, jako podkladu pro vedení soutěžního dialogu mezi zadavatelem a jednotlivými účastníky soutěžního dialogu. Tato zadávací dokumentace nepředstavuje podklad pro zpracování nabídky a neobsahuje podrobné údaje nezbytné pro zpracování nabídky.“

242.     Nabídky na plnění veřejné zakázky budou podávány účastníky zadávacího řízení až po stanovení konečných zadávacích podmínek v rozsahu a podrobnostech umožňujících účastníkům zadávacího řízení podat nabídky, tedy až ve fázi nabídkové po ukončení předchozí fáze soutěžního dialogu.   

243.     Zadávací dokumentace v kvalifikační fázi zadávacího řízení musí být zpracována a poskytnuta dodavatelům v podrobnostech nezbytných pro účast dodavatele v zadávacím řízení, což v úvodní fázi zadávacího řízení se soutěžním dialogem znamená v podrobnostech nezbytných pro podání žádostí o účast, nikoli ještě pro podání nabídek. Dodavatel se v první fázi zadávacího řízení se soutěžním dialogem na základě zadávacích podmínek rozhoduje, zda podá žádost o účast a s podáním žádosti o účast prokazuje svoji kvalifikaci. Na popis předmětu plnění veřejné zakázky v zadávacích podmínkách stanovených pro podání žádosti o účast jsou tedy nižší nároky než v případě, slouží-li zadávací podmínky pro podání nabídek. 

244.     Úřad se v šetřeném případě tedy nejprve zabýval nezbytností poskytnutí schématu architektury v podobě čitelné bez obtíží v celém rozsahu pro podání žádostí o účast.

245.     V šetřeném případě schéma architektury zobrazuje jednotlivé části požadovaného systému, rozčleněné do určitých skupin a případně i podskupin a dále vazby mezi těmito částmi. Ve schématu jsou jednotlivé části také barevně odlišeny podle toho, zda se jedná o stávávající prvek nebo v rámci tohoto projektu vytvářený.

246.     Veškeré popisky, struktury a vazby v nově uveřejněném schématu jsou při dostatečném zvětšení schématu zřetelně a bez obtíží čitelné.

247.     Při zobrazení původně uveřejněného schématu architektury v jeho původní velikosti je toto schéma vč. popisků nečitelné, nicméně při dostatečném zvětšení tohoto schématu jsou:

- popis „Pohled na strukturu aplikací, komponent a jejich rozhraní. Zakresleny jsou také vazbana aplikační služby implementované projektem eISIR a využití centrálních prvků           eGovermentu a jejich služeb jednotlivými systémy a jejich komponentami.“ zřetelně (bez           výraznějších obtíží) čitelný,

- legenda: „Stávající prvek“ a „Projektem budovaný prvek“ zřetelně (bez výraznějších obtíží) čitelná,

- struktura aplikací, komponent a jejich rozhraní zřetelně (bez výraznějších obtíží) čitelná,

- vazby zřetelně (bez výraznějších obtíží) čitelné,

- popisky jednotlivých skupin a podskupin aplikací, komponent, systémů, prvků, služeb     apod. jsou obtížněji čitelné a některé nečitelné; Úřad však zjistil, že většinu těchto popisků lze při podrobné znalosti obsahu zadávací dokumentace a terminologii v ní použité (zejména projektového záměru) přečíst, resp. určit,

- popisky jednotlivých konkrétních aplikací, komponent, systémů, prvků, služeb apod. jsou obtížněji čitelné a některé nečitelné; většinu těchto popisků však lze při podrobné znalosti obsahu zadávací dokumentace (zejména projektového záměru, viz např. obsah jednotlivých kapitol v rámci kapitoly 2 „Součást dodávky“ projektového záměru, blíže viz body 106, 107 a 108 odůvodnění tohoto rozhodnutí) a terminologii v ní použité, včetně názvů a zkratek pro jednotlivé aplikace, systémy apod., přečíst, resp. určit; uvedené se týká zejména projektem budovaných prvků v částech Justiční aplikace a komponenty, Elektronický spis, Komunikační rozhraní centrálních aplikací, Podpůrné justiční systémy.

248.     Většinu těch popisků jednotlivých skupin a podskupin aplikací, popisků konkrétních aplikací, komponent, systémů, prvků, služeb apod., které jsou v původně uveřejněném schématu obtížněji čitelné a které představují značnou část popisů v daném schématu (jedná se přitom především o popisky těch částí Systému eISIR, které mají být dodány v rámci plnění předmětné veřejné zakázky), lze při dostatečném zvětšení schématu a podrobné znalosti obsahu zadávací dokumentace (zejména projektového záměru) a terminologii v ní použité přečíst, resp. alespoň určit/dovodit.

249.     Podstatné informace o Systému eISIR, především o těch částech, vazbách mezi nimi a dalších aspektech systému, které mají být dodány v rámci předmětné veřejné zakázky, jsou obsaženy ve zbývajících zejména textových, ale i obrazových částech zadávací dokumentace a jejích příloh (např. informace v kapitolách 1, 2 a 5 projektového záměru). Jedná se i o informace vypovídající o architektuře Systému eISIR, resp. o předpokládané architektuře tohoto systému si lze učinit představu i na základě informací, které zadavatel dodavatelům poskytl mimo samotné schéma architektury. V projektové dokumentaci jsou uvedeny rovněž stávající nebo budoucí části, systémy a aplikace, které sice samotné nejsou součástí předmětu zakázky, ale mají být v rámci plnění zakázky do zamýšleného Systému eISIR integrovány.

250.     Úřad dospěl k závěru, že nebylo zcela nezbytné, aby dodavatelé měli pro podání žádostí o účast k dispozici schéma architektury v perfektní a zcela komfortní podobě (v podobě čitelné bez obtíží v celém rozsahu). Na dané schéma se nedá pohlížet tak, že jej dodavatelé neměli vůbec k dispozici a že by schéma nebylo použitelné z důvodu, že bylo poskytnuto v méně komfortní podobě (obtížněji čitelné). Jak plyne ze shora uvedených zjištění, značnou část obsahu schématu architektury lze z původně uveřejněného schématu architektury přečíst nebo dovodit (i při laickém zvětšení), přičemž podstatné informace o Systému a jeho architektuře plynou i z dalších částí zadávací dokumentace a jejích příloh, ze kterých dodavatelé měli možnost rovněž vycházet (v tomto ohledu má tedy schéma architektury pro popis předmětu veřejné zakázky prakticky navíc spíše doplňkový, pomocný význam). Znalost obsahu schématu architektury ani není třeba pro samotnou přípravu a podání žádostí o účast – veškerých dokladů prokazujících kvalifikaci dodavatele (ani pro to, aby dodavatelé mohli sami posoudit, zda splňují požadovanou kvalifikaci), neboť schéma architektury v tomto směru neobsahuje žádné relevantní informace.

251.     Schéma architektury v podobě čitelné bez obtíží v celém rozsahu měli dodavatelé k dispozici po téměř 13 dní, tj. téměř polovinu lhůty pro podání žádostí o účast, což dodavatelům umožnilo seznámit se přímo prostřednictvím schématu i s těmi dílčími informacemi, které by případně nedokázali z původně uveřejněného schématu architektury dovodit.   

252.     Za daných okolností mělo poskytnutí schématu architektury v podobě čitelné bez obtíží v celém rozsahu pouze marginální význam a nelze na něj proto pohlížet jako na doplnění, jehož povaha by vyžadovala prodloužení lhůty pro podání žádostí o účast. 

253.     Úřad neshledal, že by zadávací dokumentace nebyla z důvodu spočívajícího v čitelnosti a délce poskytnutí schématu architektury poskytnuta dodavatelům v podobnostech nezbytných pro podání žádostí o účast a po nezbytnou dobu, resp. že by zadavatel byl povinen přiměřeně prodloužit lhůtu pro podání žádostí o účast v návaznosti na poskytnutí schématu architektury s vysvětlením zadávací dokumentace č. 2 ze dne 19. 2. 2020 a že by postup zadavatele mohl vést k tomu, že se někteří dodavatelé zadávacího řízení nezúčastní.

254.     Nad rámec výše uvedeného Úřad uvádí, že o skutečnosti, že postup zadavatele spočívající v tom, že po část lhůty pro podání žádostí o účast bylo schéma architektury poskytnuto v obtížněji čitelné podobě a dále v tom, že nebyla prodloužena lhůta pro podání žádosti o účast v návaznosti na následné poskytnutí téhož schématu v podobě čitelné bez obtíží v celém rozsahu, nemělo za následek, že by se dodavatelé nemohli zadávacího řízení zúčastnit, svědčí i skutečnost, že i přes tento postup zadavatele, resp. po určitý čas obtížněji čitelné schéma architektury, podali žádost o účast v tomto zadávacím řízení celkem čtyři dodavatelé a dle obsahu dokumentace o zadávacím řízení tito účastníci splnili podmínky účasti v předmětném zadávacím řízení. 

255.     V případě, že by byly naplněny podmínky stanovené v § 263 odst. 2, resp. 3 zákona, Úřad by k dosažení nápravy protiprávního stavu nemohl uložit jiné nápravné opatření, než nápravné opatření spočívající ve zrušení zadávacího řízení. V šetřeném případě však tyto podmínky nejsou naplněny, neboť Úřad neshledal, že by zadavatel stanovil zadávací podmínky v rozporu se zákonem, resp. svým postupem nedodržel pravidla stanovená pro zadání veřejné zakázky. Nadto je Úřad názoru, že zrušení předmětného zadávací řízení by vzhledem k uvedeným okolnostem případu (poskytnutí informací ve zbývajících částech zadávací dokumentace a prakticky doplňkový význam schématu architektury pro účely podání žádostí o účast) bylo nepřiměřeným opatřením.

256.     S ohledem na výše uvedené skutečnosti Úřad rozhodl o zamítnutí návrhu navrhovatele dle ustanovení § 265 písm. a) zákona v části týkající se postupu zadavatele při poskytnutí části zadávací dokumentace dodavatelům – obrázku 1 „Schéma předpokládané aplikační architektury projektu“ v kapitole 5.1 „Předpokládaná aplikační architektura Systému eISIR“ přílohy č. 2 zadávací dokumentace, konkrétně údajně nedostatečné doby poskytnutí tohoto obrázku v čitelné podobě, resp. neprodloužení lhůty pro podání žádostí o účast v návaznosti na poskytnutí tohoto obrázku dodavatelům s vysvětlením zadávací dokumentace č. 2 ze dne 19. 2. 2020,neboť nebyly zjištěny důvody pro uložení nápravného opatření. Z tohoto důvodu Úřad rozhodl tak, jak je uvedeno ve výroku III. tohoto rozhodnutí.

 

Poučení

 

Proti tomuto rozhodnutí lze do 15 dnů ode dne jeho doručení podat rozklad k předsedovi Úřadu pro ochranu hospodářské soutěže, a to prostřednictvím Úřadu pro ochranu hospodářské soutěže – Sekce veřejných zakázek, třída Kpt. Jaroše 1926/7, Černá Pole, 604 55 Brno.

 

Včas podaný rozklad proti výroku I. tohoto rozhodnutí nemá podle § 76 odst. 5 správního řádu odkladný účinek. Včas podaný rozklad proti výrokům II. a III. tohoto rozhodnutí má odkladný účinek.

 

Rozklad a další podání účastníků učiněná v řízení o rozkladu se podle § 261 odst. 1 písm. b) zákona činí výhradně prostřednictvím datové schránky nebo jako datová zpráva podepsaná uznávaným elektronickým podpisem.

 

 

otisk úředního razítka

 

 

JUDr. Eva Kubišová

místopředsedkyně

 

 

 

 

Obdrží:

1. Česká republika – Ministerstvo spravedlnosti, Vyšehradská 427/16, 128 00 Praha – Nové Město

2. DXC Technology Czech Republic s.r.o., Pikrtova 1737/1a, Nusle, 140 00 Praha 4

 

Vypraveno dne

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

 

 



[1] Pokud je v tomto usnesení uveden odkaz na zákon, jedná se vždy, není-li uvedeno jinak, o znění účinné ke dni zahájení šetřeného zadávacího řízení, tj. ke dni 31. 1. 2020.

[2] dostupný na https://nen.nipez.cz//profil/profilMsp

[3] Zadavatel v tomto vysvětlení zadávací dokumentace nesprávně – zřejmě omylem – uvedl, že prodlužuje „lhůtu pro podání nabídek“. 

[4] V zadávací dokumentaci je v této souvislosti uvedeno: „Pojem elektronizace justice, ve zkratce eJustice, lze definovat jako využití informačních a komunikačních technologií v justici s cílem podpořit spravedlivé, zákonné a rychlé rozhodování organizačních složek resortu justice a jejich efektivní hospodárné a transparentní fungování.“

vyhledávání ve sbírkách rozhodnutí

cs | en
+420 542 167 111 · posta@uohs.cz