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 119–123 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 125–126 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 127–129 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í.“