číslo jednací: 15367/2023/500
spisová značka: S0105/2023/VZ

Úř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ů, v řízení o přezkoumání úkonů zadavatele vedeném pod sp. zn. ÚOHS-S0105/2023/VZ, jež bylo zahájeno dne 10. 2. 2023 na návrh z téhož dne, jehož účastníky jsou

• zadavatel – Masarykova univerzita, IČO 00216224, se dílem Žerotínovo náměstí 617/9, 602 00 Brno,
• navrhovatel – MAGION system, a.s., IČO 25872818, se sídlem Jiráskova 1252, 755 01 Vsetín, ve správním řízení zastoupen na základě plné moci ze dne 12. 1. 2023 Mgr. Markem Šimkou, advokátem, ev. č. ČAK 14811, se sídlem Šumavská 519/35, 602 00 Brno

ve věci veřejné zakázky „Otevřený informační systém pro Masarykovu univerzitu“ zadávané v řízení se soutěžním dialogem, jehož oznámení bylo odesláno k uveřejnění dne 29. 4. 2021 a uveřejněno ve Věstníku veřejných zakázek dne 3. 5. 2021 pod ev. č. Z2019-004453, ve znění pozdějších oprav a v Úředním věstníku Evropské unie dne 4. 5. 2021 pod ev. č. 2021/S 086-222638, ve znění pozdějších oprav,

rozhodl takto:

Návrh navrhovatele – MAGION system, a.s., IČO 25872818, se sídlem Jiráskova 1252, 755 01 Vsetín, ve správním řízení zastoupen na základě plné moci ze dne 12. 1. 2023 Mgr. Markem Šimkou, advokátem, ev. č. ČAK 14811, se sídlem Šumavská 519/35, 602 00 Brno – ze dne 10. 2. 2023 na zahájení správního řízení o přezkoumání úkonů zadavatele – Masarykova univerzita, IČO 00216224, se dílem Žerotínovo náměstí 617/9, 602 00 Brno – učiněných při zadávání veřejné zakázky „Otevřený informační systém pro Masarykovu univerzitu“ v řízení se soutěžním dialogem, jehož oznámení bylo odesláno k uveřejnění dne 29. 4. 2021 a uveřejněno ve Věstníku veřejných zakázek dne 3. 5. 2021 pod ev. č. Z2019-004453, ve znění pozdějších oprav a v Úředním věstníku Evropské unie dne 4. 5. 2021 pod ev. č. 2021/S 086-222638, ve znění pozdějších oprav, se podle ustanovení § 265 písm. a) zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, zamítá, neboť nebyly zjištěny důvody pro uložení nápravného opatření.

 

Odůvodnění

I.               ZADÁVACÍ ŘÍZENÍ

1.             Zadavatel – Masarykova univerzita, IČO 00216224, se sídlem Žerotínovo náměstí 617/9,
602 00 Brno (dále jen „zadavatel“) – zahájil podle zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „zákon“), dne 29. 4. 2021 odesláním oznámení o zahájení zadávacího řízení „Otevřený informační systém pro Masarykovu univerzitu“ zadávané v řízení se soutěžním dialogem, přičemž oznámení bylo uveřejněno ve Věstníku veřejných zakázek dne 3. 5. 2021 pod ev. č. Z2019-004453, ve znění pozdějších oprav a v Úředním věstníku Evropské unie dne 4. 5. 2021 pod ev. č. 2021/S 086-222638, ve znění pozdějších oprav (dále jen „veřejná zakázka“ nebo „zadávací řízení“) k uveřejnění.

2.             V rámci zadávacího řízení obdržel zadavatel žádost o účast mimo jiné společnosti MAGION system, a.s., IČO 25872818, se sídlem Jiráskova 1252, 755 01 Vsetín, ve správním řízení zastoupena na základě plné moci ze dne 12. 1. 2023 Mgr. Markem Šimkou, advokátem, ev. č. ČAK 14811, se sídlem Šumavská 519/35, 602 00 Brno (dále jen „navrhovatel“).

3.             Dne 30. 12. 2022 odeslal zadavatel rozhodnutí o vyloučení navrhovatele z účasti v zadávacím řízení z téhož dne (dále jen „rozhodnutí o vyloučení“).

4.             Dne 16. 1. 2023 byly zadavateli doručeny námitky navrhovatele proti rozhodnutí o vyloučení a současně proti volbě druhu zadávacího řízení z téhož dne (dále jen „námitky“).

5.             Dne 31. 1. 2023 bylo navrhovateli doručeno rozhodnutí zadavatele o námitkách z téhož dne (dále jen „rozhodnutí o námitkách“), kterým zadavatel námitky navrhovatele odmítl.

6.             Dne 10. 2. 2023 podal navrhovatel návrh na zahájení správního řízení o přezkoumání úkonů zadavatele z téhož dne Úřadu pro ochranu hospodářské soutěže (dále jen „Úřad“).

II.             OBSAH NÁVRHU

7.             Na úvod Úřad uvádí, že podání navrhovatele z 10. 2. 2023, které bylo Úřadu doručeno prostřednictvím datové schránky téhož dne, obsahovalo dva návrhy. První návrh směřoval proti rozhodnutí o vyloučení navrhovatele a je předmětem správního řízení, které Úřad vede pod spis. zn. ÚOHS-S0105/2023/VZ, a o němž je rozhodnuto tímto rozhodnutím (dále jen „návrh“). Druhý návrh směroval proti volbě druhu zadávacího řízení a bylo na základě něj zahájeno samostatné správní řízení, které Úřad vede pod spis. zn. ÚOHS-S0106/2023/VZ (dále také jako „návrh č. 2“).

8.             Návrh směřuje proti rozhodnutí zadavatele o vyloučení navrhovatele ze zadávacího řízení ze dne 30. 12. 2022 (dále jen „rozhodnutí o vyloučení“). Navrhovatel obecně k vadám rozhodnutí o vyloučení uvádí, že zadavatel při formulování důvodů pro vyloučení navrhovatele vychází z nepravdivých a neoprávněných úvah a východisek, v důsledku čehož dochází k nesprávným závěrům.

9.             Navrhovatel v návrhu tvrdí, že zadavateli zatím ze strany navrhovatele nebylo předloženo žádné ucelené řešení, ani k tomu nebyl navrhovatel zadavatelem vyzván a v rámci soutěžního dialogu tedy nedošlo zatím ze strany navrhovatele k finální specifikaci předloženého řešení. Dle navrhovatele je předložení řešení předpokladem pro postup dle § 69 odst. 5 zákona, jehož aplikaci zadavatel sdělil v rozhodnutí o vyloučení.

10.         Navrhovatel dále napadá skutečnost, že zadavatel v rámci rozhodnutí o vyloučení nesprávně hodnotí stávající ekonomicko-informační systém, který provozuje navrhovatel. K tomu uvádí, že „[z]adavatel tak ignoruje, že navrhovatel zamýšlí (v budoucnu, až k tomu bude vyzván) nabídnout jiné než stávající řešení.“ Navrhovatel tvrdí, že rozhodnutí o vyloučení je formulováno na základě skutečností, které nejsou ze strany navrhovatele zadavateli nabízeny.

11.         Dle navrhovatele je rozhodnutí dále vadné z důvodu opakovaných výtek zadavatele, že navrhovatel nic nevyvíjí a nijak nevylepšil své stávající řešení. Dle navrhovatele to svědčí o „zásadním nepochopení smyslu soutěžního dialogu či obecně jakéhokoliv zadávacího řízení dle ZZVZ,“ když tvrdí, že „[ž]ádný dodavatel není povinen v době probíhajícího zadávacího řízení již pracovat na budoucím předmětu plnění.“

12.         Nedodržení zákona spatřuje navrhovatel dále v opakovaném odmítání řešení „na míru“ ze strany zadavatele, kdy zadavatel v rozhodnutí o vyloučení uvedl, že „…je zadavatelem poptáván takový dodavatel, jehož systém je dlouhodobě aktivně rozvíjen bez ohledu na konkrétní poptávku, a jehož otevřenost je garantována všem zákazníkům…“ K tomu navrhovatel uvádí, že „neexistuje žádný univerzální důvod, pro který by všechny průběžně aktivně rozvíjené systémy měly být vhodnější než systém nějakou dobu již nerozvíjený.“ Podle navrhovatele „zadavatel definuje kritérium, které nic přímo nevypovídá o kvalitě a vhodnosti budoucího řešení, a tedy o ekonomické výhodnosti budoucí nabídky.“

13.         Navrhovatel dále uvádí, že mu zadavatel v rámci rozhodnutí o vyloučení opakovaně vytýká, že se v případě jeho stávajícího řešení nejedná o „otevřený systém“. Navrhovatel dle svých slov jako odborník na softwarové systémy prohlašuje, že „absolutně otevřený systém na trhu neexistuje.“ Příslušná část rozhodnutí o vyloučení a rozhodnutí zadavatele o námitkách je tudíž dle navrhovatele netransparentní a nesmyslná, když dle navrhovatele zadavatel nepředložil žádnou definici, co má na mysli pod pojmem „otevřený systém“.

14.         Navrhovatel dále brojí proti nezákonnému vedení soutěžního dialogu, když namítá, že § 69 odst. 5 zákona je aplikován zadavatelem nesprávně, což dokládá odkazem na články 30 a 65 směrnice Evropského parlamentu a Rady č. 2014/24/EU ze dne 26. 2. 2014 o zadávání veřejných zakázek a o zrušení směrnice 2004/18/ES (dále jen „směrnice“). Podle navrhovatele nemůže v průběhu soutěžního dialogu dojít svévolně k vyloučení účastníků a je to možné pouze za předpokladu, že si to zadavatel předem vyhradil a je splněna podmínka stanovení objektivních a nediskriminačních kritérií či pravidel. Dle navrhovatele je zadavatel povinen dle článku 30 směrnic a § 69 odst. 5 zákona vyzvat k podání konečných nabídek či řešení každého účastníka. Navrhovatel také poukazuje na to, že zadavatel v bodě 1.11 písm. c) dokumentu „Dokumentace řízení se soutěžním dialogem“ (dále jen „zadávací podmínky“) vyloučil možnost snížení počtu účastníků.

15.         Navrhovatel tedy shledává své vyloučení jako diskriminační, když mu ze strany zadavatele nebylo umožněno v soutěžním dialogu předložit řešení, neboť k tomu nebyl vyzván. Výroky zadavatele, kdy hodnotil řešení formulacemi „řešení je zadavateli dobře známo“ či „dlouhodobě mu nevyhovuje“ považuje navrhovatel za porušení principu rovného zacházení dle § 6 odst. 2 zákona a také za porušení principu, že nabídky jsou posuzovány a hodnoceny podle informací, které jsou v nich obsaženy.

16.         Navrhovatel dále v návrhu rozporuje některé technické aspekty řešení, které zadavatel uvádí jako důvody pro nevhodnost řešení a vyloučení navrhovatele, a to konkrétně následující důvody:

• absence rozsáhlého otevřeného API
• nenabízení dostupného řešení všem
• vývoj API jen dle požadavků zadavatele a možnosti zpřístupnění dalším veřejným vysokým školám
• uživatelské rozhraní řešení
• zkušenost navrhovatele s provozováním řešení v cloudu
• integrační platforma (ESB)
• absence specifické funkce pro automatizaci digitalizace a individualizaci agend samostatnými uživateli.

17.         Navrhovatel navrhuje, aby Úřad jako opatření k nápravě zrušil napadené rozhodnutí o vyloučení navrhovatele a veškeré navazující úkony.

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

18.         Úřad obdržel návrh navrhovatele dne 10. 2. 2023 a tímto dnem bylo podle § 249 zákona ve spojení s ustanovením § 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í ve věci přezkoumání úkonů zadavatele.

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

• zadavatel,
• navrhovatel.

20.         Zahájení správního řízení oznámil Úřad jeho účastníkům přípisem ze dne 17. 2. 2023.

21.         Dne 20. 2. 2023 Úřad obdržel od zadavatele prostřednictvím datové schránky vyjádření k návrhu z téhož dne (dále jen „vyjádření zadavatele“) a na technických nosičích dat byla téhož dne doručena dokumentace o zadávacím řízení.

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

22.         Zadavatel se v rámci svého vyjádření v úvodu vyjadřuje k obsahu návrhu č. 2, které je předmětem samostatného správního řízení.

23.         Dále zadavatel tvrdí, že navrhovatel je již 25 let dodavatelem informačního systému zadavatele a nastiňuje své důvody a potřeby pro obměnu informačního systému za nový, tedy důvody, které jej vedly k zahájení zadávacího řízení. Zadavatel uvádí, že „Za tuto dobu [doba využívání stávajícího informačního systému od navrhovatele] se výrazně změnily potřeby univerzity. Vzniklo mnoho dalších IT systémů, které jsou navázány na ERP systém a potřebují si s ním vyměňovat informace. Se současným dodavatelem systému, který je zároveň v pozici navrhovatele, na začátku spolupráce probíhal intenzivní vývoj ERP systému dle potřeb univerzity. Intenzita vývoje se v posledních letech zpomalila, stále větší rozsah funkcionality univerzita řeší v nadstavbě, interně označené “INET”, vyvíjené vlastními silami a rozvoj základního systému zaostává. Univerzita proto dospěla k závěru, že nastal čas na generační obměnu ERP systému. Motivací pro ni je udržet si pozici lídra mezi veřejnými vysokými školami v oblasti elektronizace a digitalizace, jak vyplývá ze Strategického záměru univerzity.“

24.         Mezi hlavní důvody pro potřebu nového informačního systému zadavatel uvádí:

• současný informační systém je uzavřený a je obtížné či nemožné jej napojit na ostatní IT systémy univerzity,
• současný systém je technicky zastaralý, když stojí na využívání tzv. tlustých klientů (dedikovaných desktopových aplikací),
• inovace současného systému probíhají většinou na základě požadavku zadavatele.

25.         Zadavatel dále tvrdí, že zadávacímu řízení předcházely předběžné tržní konzultace, které byly zahájeny dne 7. 2. 2019 uveřejněním předběžného oznámení. V období od 13. 3. 2019 do 26. 6. 2019 proběhla setkání s 12 různými dodavateli. Dále zadavatel dodává, že se mělo konat druhé kolo předběžných tržních konzultací, když zadavatel dne 23. 12. 2019 uveřejnil výzvu k účasti na druhém kole předběžných tržních konzultací. Následně zadavatel od druhého kola předběžných tržních konzultací upustil v souvislosti s opatřeními souvisejícími s pandemií viru SARS-CoV-2.

26.         Dle zadavatele byly v rámci předběžných tržních konzultací potvrzeny předpoklady zadavatele o nových možnostech na trhu dostupných systémů. Dle zadavatele byla vybrána forma zadávacího řízení s ohledem na tyto důvody:

• žádný ERP systém není možné nasadit u zadavatele jako otevřený systém bez úpravy na trhu dostupných plnění, zároveň na trhu dle předběžných tržních konzultací neexistuje produkt, který by bez výhrad uspokojoval potřebu zadavatele,
• vzhledem k nutnosti integrovat ERP systém do komplexního prostředí IT systémů zadavatele a nutnost dodržet směrnici Evropského parlamentu a Rady 2016/1148 o opatřeních k zajištění vysoké společné úrovně bezpečnosti sítí a informačních systémů v Unii a s ohledem na v té době očekávanou směrnici Evropského parlamentu a Rady 2022/2555 o opatřeních k zajištění vysoké společné úrovně kybernetické bezpečnosti v Unii a o změně nařízení (EU) č. 910/2014 a směrnice (EU) 2018/1972 a o zrušení směrnice (EU) 2016/1148  a požadavků na významné informační systémy je nutné, aby každé řešení bylo inovativní, zároveň zadavatel po celou dobu prezentoval záměr pořídit otevřený systém a zájem o tvorbu dalších napojených řešení, v tomto ohledu není podle zadavatele na trhu srovnatelný otevřený informační systém pro řešení v oblasti veřejných vysokých škol,
• zakázka dle zadavatele naplňuje všechny znaky uvedené v § 60 odst. 1 písm. c) zákona
• nelze stanovit technické podmínky odkazem na technické dokumenty.

27.         Následně zadavatel uvádí, že formálně zahájil řízení se soutěžním dialogem dne 29. 4. 2021, do kterého se přihlásilo 7 uchazečů. Dle slov zadavatele bylo u všech shledáno splnění podmínek účasti v řízení a dne 26. 7. 2021 byla těmto dodavatelům rozeslána výzva k účasti v soutěžním dialogu. V rámci výzvy požádal zadavatel o předložení architektonického návrhu/koncepce řešení. Zadavatel k tomuto dokumentu uvádí, že „stanovil, že tento návrh bude základem pro další jednání s jednotlivými dodavateli v rámci soutěžního dialogu.“ Tuto koncepci/návrh řešení předložili 4 dodavatelé. Následně přistoupil zadavatel k jednáním o předložených návrzích.

28.         Zadavatel uvádí, že v rámci soutěžního dialogu proběhlo s každým z účastníků zadávacího řízení sedm schůzek, a to

• dvě technologicko-architektonické schůzky dne 1. 12. 2021 a 28. 1. 2022,
• schůzka z ekonomického pohledu dne 16. 12. 2021,
• schůzka z personálního pohledu dne 10. 12. 2021,
• schůzka zaměřená na projektový přístup dne 30. 8. 2022 a
• dvě schůzky zaměřené na oblast licenční, cenové a partnerské politiky dne

28. 6. 2022 a 17. 10. 2022.

29.         Následně po vyhodnocení jednotlivých řešení se zadavatel dostal do fáze dle § 69 odst. 5 zákona, kdy informoval jednotlivé dodavatele o vhodnosti či nevhodnosti jejich řešení.

30.         Navrhovatel byl dle zadavatele vyloučen na základě proběhnuvších jednání a po vyhodnocení dostupných informací.

31.         V rámci vyjádření se zadavatel následně vyjadřuje k jednotlivým důvodům vyloučení.

K argumentu navrhovatele, že zadavatel zatím od něj neobdržel žádné řešení

32.         K tomuto zadavatel uvádí, že „již ve výzvě k účasti v soutěžním dialogu dne 26. 7. 2021 požádal dodavatele o zpracování a předložení architektonického návrhu / koncepce a v příloze č. 1 stanovil svá očekávání na podobu takto předkládaného návrhu. Zároveň ve výzvě uvedl, že předložený návrh bude základem pro další jednání, a že povede s účastníky zadávacího řízení soutěžní dialog s cílem nalézt řešení způsobilé splnit potřeby zadavatele.“ Navrhovatel předložil architektonický návrh/koncepci řešení o 121 stranách, na základě kterého byla vedena jednotlivá jednání, která trvala více než rok. Zadavatel uvádí, že neměl pochybnosti o tom, že informace navrhovatele jsou předkládaným řešením. Zadavatel dodává, že dle jeho názoru je hledání řešení ve smyslu § 69 odst. 5 zákona zřejmou náplní a smyslem celého soutěžního dialogu.

33.         Dle zadavatele je tento argument navrhovatele o nepředložení řešení a čekání na výzvu k jeho předložení čistě účelový. 

 

K argumentu navrhovatele, že zadavatel nesprávně hodnotí stávající řešení navrhovatele

34.         Zadavatel uvádí, že při soutěžním dialogu vycházel z informací, které mu byly předloženy navrhovatelem, tj. z architektonického návrhu/koncepce řešení a z následných jednání.

35.         Zadavatel současné řešení navrhovatele zná a nevyhovuje jeho potřebám. Z toho důvodu usiloval v rámci soutěžního dialogu o ujištění, že navrhovatel předkládá jiné řešení.

36.         Zadavatel dodává, že architektonické řešení předložené navrhovatelem je postaveno na stávajícím řešení s indikacemi možných úprav nových technologií, které by mohl nasadit, což je dle zadavatele nevhodné.

K argumentu navrhovatele, že je navrhovateli ze strany zadavatele opakovaně vytýkáno, že nic nevyvíjí

37.         K tomuto zadavatel uvádí, že „nezpochybňuje schopnost navrhovatele dále vyvíjet existující řešení, na druhé straně však v rámci soutěžního dialogu opakovaně upozorňoval na skutečnost, že slibovaný vývoj směrem ke generačně novému systému nevidí a ani mu nejsou předložena fakta, která by nasvědčovala opaku. Zadavatel na základě výše uvedeného dospěl k závěru, že nabízené řešení navrhovatele není vyvíjeno, a tedy zůstává vysoká pravděpodobnost, že skutečně realizovatelné řešení nebude vhodné, neboť nepřinese zadavateli očekávanou změnu.“

38.         Tento důvod vyloučení zadavatel odůvodňuje potřebou péče řádného hospodáře, kdy nemůže schválit jako vhodné řešení to, které přináší reálná rizika.

K argumentu navrhovatele, že odmítá řešení „na míru“ a současně očekává inovativní řešení

39.         Zadavatel dle vyjádření nemůže riskovat řešení, které nemají trhem prověřenou funkční a moderní architekturu (příkladmo zadavatel zmiňuje otevřené API či prvky pro automatizaci). Zároveň se zadavatel na předběžných tržních konzultacích přesvědčil, že neexistuje na trhu řešení, které by plně saturovalo potřebu zadavatele. Na základě toho zadavatel akceptuje, že jakékoliv řešení bude potřeba nadále upravovat. Zadavatel rozlišuje, zda bude upravováno jádro a základní architektura či sekundární specifické funkcionality, proto požadoval po dodavatelích předložení architektonického návrhu řešení.

K argumentu navrhovatele ohledně údajně netransparentního odkazu na „otevřený systém“

40.         Zadavatel trvá na tom, že již od začátku sděloval, co rozumí pod označením „otevřený systém.“ První vymezení poskytl zadavatel dle svých slov spolu s uveřejněním předběžného oznámení. Zároveň v třístránkovém dokumentu došlo dle zadavatele k vymezení okruhu otázek, kterým se hodlá zadavatel věnovat na předběžných tržních konzultacích. Zadavatel dodává, že těchto konzultací se účastnil i navrhovatel.

41.         Výklad sousloví „otevřený systém“ byl dle zadavatele obsažen i v dokumentaci se soutěžním dialogem a ve výzvě k účasti v soutěžním dialogu, kdy byla navíc celá příloha č. 1 k této výzvě věnována požadavkům na předkládaná řešení.

42.         Zadavatel argumentaci k tomuto bodu uzavírá tím, že se mu „nejeví jako reálné, že by odborně způsobilému dodavateli takto dlouhodobě konzistentně prezentovaný termín (který je přímo v názvu zadávacího řízení), s kterým žádný z ostatních dodavatelů neměl problém, mohl být stále nejasný, a ani se na něj v rámci jednání více nedotázal.“

K argumentu navrhovatele ohledně údajně nezákonného vedení soutěžního dialogu

43.         Zadavatel uvádí, že postupoval v souladu s § 69 odst. 5 zákona, když vyloučil navrhovatele pro nevhodnost řešení.

44.         Zároveň zadavatel odmítá argumentaci vadného použití evropské legislativy, když má za to, že jako zadavatel není adresátem navrhovatelem zmiňované směrnice, kterým je Česká republika, která odpovídá za implementaci do českého právního řádu.

45.         Dle zadavatele vyplývá z formulace § 69 odst. 5 zákona povinnost vyloučit dodavatele, jehož řešení shledá zadavatel nevhodným a neexistuje možnost tento krok neaplikovat. Zadavatel dodává, že vyloučení pro nevhodnost dle § 69 odst. 5 zákona je zcela odlišným institutem od snížení počtu účastníků zadávacího řízení ve smyslu § 111 zákona.

K argumentu navrhovatele ohledně údajně diskriminačního vyloučení

46.         Zadavatel opakuje, že důvodem pro vyloučení navrhovatele byla nevhodnost předloženého řešení, nikoliv skutečnost, že se jedná o dodavatele současného informačního systému

47.         Dle zadavatele není diskriminací, když je někdo z dodavatelů vyloučen pro nevhodné řešení, které neodpovídá potřebám zadavatele, a odkazuje na rozhodnutí Úřadu ze dne 2. 5. 2012, č. j. ÚOHS-S326/2011/VZ-2436/2012/50/SWa.

K argumentu absence rozsáhlého otevřeného API v řešení navrhovatele

48.         Zadavatel konstatuje, že navrhovatelem „navrhované řešení, jehož podstata stojí na vývoji dnes minimálního API, pro něj není přijatelné, neboť neúměrně prodlužuje dobu implementace – místo integrace na existující API dodavatele by v případě využití navrhovaného řešení navrhovatelem musel zadavatel nejprve specifikovat, jak má dané rozhraní vypadat, počkat na jeho implementaci, a teprve poté přistoupit k integraci pomocí API do ostatních IT systémů. Je zjevné, že tento postup je značně pomalejší a náročnější než možnost okamžitě využít existujících API, zejména když je toto možné a standardem u ostatních řešení na trhu.“

49.         K námitce posuzování stávajícího řešení a absence vývoje na straně navrhovatele zadavatel dodává, že „[n]ení pravda, že zadavatel posuzuje stávající řešení navrhovatele, a nevytýká navrhovateli, že API sám nerozvíjí proto, že by očekával, že navrhovatel bude vyvíjet předmět zakázky. Tato skutečnost ale potvrzuje závěr, ke kterému zadavatel dospěl v průběhu soutěžního dialogu na základě diskuse o navrhovaném řešení, a to, že navrhovatel neudělal žádnou změnu vývoje a obchodního modelu.“ Zadavatel dále uvádí, že navrhovatel ve fázi soutěžního dialogu nenavrhl jasnou a podloženou koncepci otevření svého systému prostřednictvím API.

K argumentu, že navrhovatel nenabízí všem dostupné rozhraní

50.         Dle zadavatele by přechod na strategii otevření API ze strany navrhovatele vyžadoval obrovské úsilí a čas, které by bylo delší než u ostatních navrhovaných řešení. A to vzhledem k tomu, že navrhovatel v současnosti provozuje pouze velmi úzkou sadu specificky vyvinutých rozhraní na míru u svých zákazníků. Zadavatel nepovažuje za vhodné řešení založené na již několik let navrhovatelem uváděné ambici přechodu na otevřený systém včetně webových služeb, bez reálně již existující implementace.

 

K argumentu zpřístupnění API dalším veřejným vysokým školám

51.         Zadavatel předně nesouhlasí s tvrzením navrhovatele, že nebyla vypořádána námitka hrozícího zneužití dominantního postavení zadavatele mezi českými vysokými školami, z čehož navrhovatel vyvozuje porušení zákonné povinnosti řádně vypořádat námitky. Zadavatel je přesvědčen, že takto formulovaná námitka v podaných námitkách navrhovatele obsažena není. Zadavatel uvádí, že „[o]bsahově se tomu nejvíce blížily body 2.40, 2.41, 2.56, 2.57 námitek, k těm všem se však zadavatel řádně vyjádřil a toto vyjádření jednoznačně označil číselným odkazem na uvedené body. Zadavatel upozorňuje, že dle ustanovení § 251 odst. 4 by neměl k těmto v návrhu uváděným tvrzením ÚOHS vůbec přihlížet, jelikož je navrhovatel neuplatnil již v námitkách podaných zadavateli, ačkoliv tak učinit mohl.“

52.         K tomuto dále zadavatel uvádí, že „v tuto chvíli žádnou nástavbu nad ERP systém komerčně neprodává a nemůže mít dominantní postavení na trhu, na kterém vůbec není přítomen. Navíc záměr zadavatele je prodávat nástavbu nad ERP systémy, nikoliv ERP nahradit. Obvinění je absurdní a bezpředmětné. Zadavatel se na jiných trzích pohybuje v rámci své doplňkové činnosti, se kterou má dlouholetou zkušenost a nikdy nebylo shledáno pochybení ze strany kontrolních orgánů z pohledu hospodářské činnosti a souladu s legislativu týkající se hospodářské soutěže.“

K argumentu, že v oblasti uživatelského rozhraní navrhovatel nenabízí to, co konkurence

53.         Zadavatel konstatuje, že navrhovatel v současné době nabízí řešení založené na tzv. tlustém klientovi (část funkcionality je závislá na instalaci softwaru na koncových stanicích uživatelů). Navrhovatel v rámci soutěžního dialogu deklaroval, že vyvíjí řešení pro webového klienta, ale jeho funkčnost a kvalitu nebylo ze strany zadavatele v rámci soutěžního dialogu možné posoudit. Zadavatel dodává, že nabídku samostatných verzí pro mobilní zařízení nebo platformy, které by zadavatel mohl svými silami rozvíjet, navrhovatel nepředstavil.

K argumentu, že navrhovatel nemá dostatečnou zkušenost s provozováním svého řešení v cloudu

54.         Zadavatel uvádí, že ze strany navrhovatele bylo představeno řešení s hostingem (provozováním mimo vlastní infrastrukturu zákazníka), nikoliv plnohodnotným cloudovým řešením. Hostingové řešení není podle zadavatele pro něj vhodné, protože si jej umí zajistit sám a nevidí přidanou hodnotu navrhovatele.

K argumentu, že navrhovatel nenabízí integrační platformu ESB

55.         Zadavatel uvádí, že navrhovatel sám přiznal, že žádnou integrační platformu neprovozuje a řešení této potřeby nenabídl. Dále zadavatel odkazuje na své rozhodnutí o námitkách.

K argumentu, že navrhovatel nenabízí specifické funkce pro automatizaci digitalizace a individualizaci agend samotnými uživateli

56.         Navrhovatel dle zadavatele v rámci soutěžního dialogu nepředložil žádný podpůrný argument, že by tyto funkce byly součástí nabízeného řešení.

57.         Zadavatel své vyjádření uzavírá s tím, že úkony zadavatele jsou plně v souladu s právní úpravou a byly splněny všechny zákonné i faktické požadavky pro vedení zadávacího řízení se soutěžním dialogem, který byl veden v souladu s právní úpravou při zachování všech zásad, jako je zejména transparentnost a rovný přístup, proto navrhuje, aby Úřad návrh dle § 265 písm. a) zákona zamítl, jelikož nebyly zjištěny důvody pro uložení nápravného opatření.

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

58.         Usnesením ze dne 23. 2. 2023, č. j. ÚOHS-07842/2023/511, byla zadavateli stanovena lhůta pro provedení úkonu – podání informace Úřadu o dalších úkonech, které zadavatel provede v zadávacím řízení v průběhu správního řízení – a to nejpozději jeden den od provedení příslušného úkonu.

59.         Přípisem zadavatele ze dne 24. 2. 2023 bylo prostřednictvím datové schránky Úřadu téhož dne doručen dokument s označením „Podání informace“, kterým zadavatel podal informaci Úřadu o provedení úkonu v zadávacím řízení, kdy účastníkům zadávacího řízení odeslal v rámci elektronického nástroje zprávu s předmětem „Informace o zahájení řízení u ÚOHS“, jehož obsahem byla informace, že v rámci zadávacího řízení došlo k zahájení správního řízení před Úřadem a z principu opatrnosti zadavatel nebude do vydání prvostupňového rozhodnutí Úřadu v rámci zadávacího řízení dělat další kroky.

60.         Dne 22. 3. 2023 vydal Úřad rozhodnutí o nařízení předběžného opatření z moci úřední, č. j. ÚOHS-11430/2023/500, spočívajícího v zákazu uzavření smlouvy na veřejnou zakázku, a to až do pravomocného skončení správního řízení vedeného Úřadem, které bylo účastníkům správního řízení doručeno téhož dne.

61.         Dne 31. 3. 2023 byl Úřadu prostřednictvím datové schránky doručen přípis navrhovatele označený jako „Replika k vyjádření zadavatele ze dne 20. 2. 2023“ z téhož dne (dále jen „replika“).

Replika k vyjádření zadavatele ze dne 31. 3. 2023

62.         Navrhovatel se ve své replice vyjadřuje k jednotlivým bodům vyjádření zadavatele.

K (ne)existenci řešení navrhovatele

63.         Navrhovatel nesouhlasí s tím, že zadavatel od navrhovatele obdržel řešení, kterým byl architektonický návrh/koncepce ze dne 26. 7. 2021. K tomu navrhovatel uvádí: „…požadavek na danou koncepci není samotným řešením, ani zadavatel jej tak neoznačil, zadavatel jej nedefinoval jako řešení ve smyslu § 69 odst. 1 ZZVZ a ani navrhovatel tuto koncepci nezamýšlel a nevnímal jako řešení ve smyslu § 69 odst. 1 ZZVZ. Tvrzení zadavatele tak jde v tomto smyslu proti všem dosavadním projevům vůle, a to jak zadavatele, tak i navrhovatele, jedná se tedy zjevně o výklad účelový.“ Dále navrhovatel dodává: „v průběhu soutěžního dialogu dosud v žádném případě nedocházelo k vysvětlování či upřesňování dříve předloženého řešení, ale docházelo a dochází k upřesňování představ zadavatele o vlastních potřebách a možnostech, přičemž dodavatelé včetně navrhovatele tak dostávají podrobnější popis požadavků zadavatele, aby na základě takto zpřesňovaného popisu mohli v budoucnu navrhnout pro zadavatele řešení ve smyslu § 69 odst. 1 ZZVZ.“

64.         Podle navrhovatele tedy nebylo předloženo žádné řešení, které by zadavatel mohl podle § 69 odst. 5 zákona odmítnout. Navrhovatel poukazuje také na skutečnost, že zadavatel v rámci rozhodnutí o vyloučení ani jednou nepoukázal na zmíněný architektonický návrh.

 

K hodnocení stávajícího řešení navrhovatele

65.         Navrhovatel má vyjádření zadavatele za naprosto zmatečné, když odmítá, že by hodnotil stávající řešení a na druhou stranu uvádí, že toto řešení dlouhodobě zná.

66.         Navrhovatel rozporuje, že by zadavatel hodnotil pouze koncepci, když na ni v rozhodnutí o vyloučení ani jednou neodkázal.

67.         Zadavatel dle navrhovatele ignoruje posun v úvahách navrhovatele o budoucím řešení, který nastal v průběhu jednání.

K výhradě o absenci vývoje na straně navrhovatele

68.         Navrhovatel konstatuje, že tvrzení zadavatele, že „…slibovaný vývoj směrem ke generačně novému systému nevidí“ a „dospěl k závěru, že nabízené řešení navrhovatele není vyvíjeno, a tedy zůstává vysoká pravděpodobnost, že skutečně realizovatelné řešení nebude vhodné, neboť nepřinese zadavateli očekávanou změnu“ a dále, že „zadavatel nemůže s péčí řádného hospodáře schválit jako vhodné řešení to, které přináší reálná rizika (…)“, jsou naprosto novými tvrzeními a navrhovatel nadále trvá na oprávněnosti návrhu, když tvrdí, že vyjádření zadavatele opětovně prohlubují netransparentnost a neoprávněnost rozhodnutí o vyloučení navrhovatele.

69.         Navrhovatel dodává, že „[n]ení účelem a smyslem soutěžního dialogu, aby zadavatel „viděl“ vývoj ke generačně novému systému, žádný požadavek na „vidění“ takové skutečnosti zadavatel v průběhu soutěžního dialogu nevyslovil, přičemž je velmi sporné, zda by něco podobného vůbec byl oprávněn požadovat.“

70.         Navrhovateli tato zadavatelova argumentace dokládá zadavatelovu snahu zbavit se navrhovatele za každou cenu.

K odmítání řešení „na míru“ při očekávání inovativního řešení

71.         K argumentu zadavatele, že potřebuje řešení prověřené trhem, navrhovatel uvádí, že není jasné, z jakého důvodu zadavatel usuzuje, že řešení navrhovatelem takto prověřené trhem není a zmiňuje, že je na trhu přítomný více než 20 let a provozuje informační systémy na řadě českých i zahraničních vysokých škol.

72.         Dle navrhovatele zadavatel dovozuje, že u navrhovatele nebude docházet ke změně jádra systému. Navrhovateli není jasné, z jakých podkladů toto zadavatel dovozuje. Argumentaci tedy navrhovatel považuje za nekonkrétní, neurčitou a irelevantní.

K termínu „otevřený systém“

73.         Navrhovatel upozorňuje na skutečnost, že byť zadavatel tvrdí, že termín „otevřený systém“ opakovaně vymezil, nebyl ve svém vyjádření schopen toto vymezení odcitovat či na něj odkázat.

74.         Dále navrhovatel odkazuje na zápis z jednání dne 17. 10. 2022, kterého se zúčastnili M. B., B. J., A. K., K. K., L. M., J. M. a J. N. za zadavatele a L. K., M. Š., Z. Š., Z. V., D. Z. a P. Ž. za navrhovatele (dále jen „jednání dne 17. 10. 2022“), ze kterého podle něj vyplývá, že se proti koncepčnímu vymezení v průběhu jednání několikrát ohrazoval.

 

K údajně nezákonnému způsobu vedení soutěžního dialogu

75.         Navrhovatel opakuje, že řízení se soutěžním dialogem nebylo vedeno v souladu se zákonem, když zadavatel dosud nevyzval k předložení řešení, která by mohl posoudit a následně odmítnout jako nevhodná.

76.         Navrhovatel odkazuje také na povinnost eurokonformního výkladu ustanovení zákona a namítá, že evropská norma je pro zadavatele do značné míry závazná.

K údajné diskriminaci navrhovatele

77.         K tomuto navrhovatel uvádí, že „[z]adavatel neuvádí žádné nové věcné argumenty, navrhovatel tak trvá na tvrzení o své diskriminaci z důvodů, které uvedl v návrhu.“

K argumentům ohledně API a rozhraní

78.         Navrhovatel upozorňuje, že „[z]adavatel setrvale nahrazuje vlastní péči o řádné a transparentní vymezení svých potřeb velmi extenzivním požadavkem na vysoký počet rozhraní budoucího řešení, kterémužto požadavku zadavatel říká otevřené řešení,“ a konstatuje, že absolutně „neomezeně“ otevřené řešení je nesmysl a neexistuje.

79.         Navrhovatel má tvrzení zadavatele o neúměrné délce implementace řešení za hrubě zavádějící, když zadavatel posouzení časových konsekvencí jednotlivých řešení neprovedl, ani nevyzval dodavatele, aby předložili harmonogram implementace jejich řešení. Zadavatel tak podle navrhovatele zohledňuje něco, co nebylo předmětem hodnocení a o čem zadavatel nemá žádné relevantní informace.

80.         K argumentu zadavatele o tom, že řešení navrhovatele neobsahuje webové služby, navrhovatel uvádí, že webové služby nabízí a v řadě případů je implementoval a poskytl i zadavateli, což navrhovatel dokazuje výčtem webových služeb, které poskytuje.

Ke údajnému zneužití dominantního postavení

81.         Navrhovatel uvádí, že v rámci námitek poukazoval na hrozící zneužití dominantního postavení zadavatele mezi českými veřejnými vysokými školami, když se zadavatel v případě využívání nového informačního systému na poskytování aplikací ostatním veřejným vysokým školám ocitne v přímé soutěži s dalšími poskytovateli softwaru pro veřejné vysoké školy.

82.         Navrhovatel zmiňuje, že zadavatel může mít dominantní postavení dle § 10 odst. 2 zákona č. 143/2001 Sb., o ochraně hospodářské soutěže, ve znění pozdějších předpisů, tedy na základě hospodářské a finanční síly spočívající ve vlastnictví určité značky, apod.

83.         Navrhovatel má stále za to, že se zadavatel k této námitce nevyjádřil, a to ani ve vyjádření zadavatele.

84.         Repliku navrhovatel uzavírá s tím, že setrvává na svém návrhu, aby Úřad uložil nápravné opatření spočívající ve zrušení napadaného rozhodnutí o vyloučení navrhovatele a veškerých navazujících úkonů.

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

85.         Usnesením ze dne 3. 4. 2023, č. j. ÚOHS-12953/2023/511, byla účastníkům stanovena lhůta 7 dnů pro vyjádření se k podkladům rozhodnutí. Zadavatel se ve stanovené lhůtě k podkladům rozhodnutí nevyjádřil.

Vyjádření navrhovatele k podkladům rozhodnutí ze dne 19. 4. 2023

86.         Úvodem navrhovatel shrnuje svá stanoviska. Navrhovatel opakovaně uvádí, že zadavatelův postup je vadný předně proto, že od navrhovatele dosud neobdržel žádné řešení, které by mohlo být posouzeno a případně odmítnuto zadavatelem. V tomto ohledu má navrhovatel rozhodnutí zadavatele o vyloučení navrhovatele za předčasné. Dle navrhovatele nedošlo ze strany zadavatele k finální formulaci jeho požadavků, na základě které by navrhovatel předložil řešení ve smyslu § 69 odst. 1 zákona. Navrhovatel upozorňuje, že pokud měl být arch. návrh řešením ve smyslu § 69 odst. 1 zákona, pak uvádí, že taková informace ze strany zadavatele nezazněla, a zároveň poukazuje na to, že toto údajné řešení bylo následně opakovaně v průběhu soutěžního dialogu modifikováno. Navrhovatel dodává, že řada konkrétních výhrad zadavatele vůči řešení byla nepravdivá a v přímém rozporu s výsledky a průběhem jednání. Dle navrhovatele ve vztahu k jednotlivým jednáním se zadavatelem platí, že se jednalo o diskuzi o možných budoucích potřebách zadavatele a nejednalo se o posuzování vhodnosti řešení.

87.         Navrhovatel znovu upozorňuje na to, že podle něj došlo ze strany zadavatele k pochybení, když fakticky posuzoval a „odmítl“ [pozn. uvozovky dle vyjádření navrhovatele] stávající řešení navrhovatele. Navrhovatel to považuje za netransparentní a diskriminační.

88.         Navrhovatel dále uvádí, že zadavatel nedodržel obvyklý způsob vedení soutěžního dialogu, kdy se požadavky zadavatele i návrhy řešení zachycují v písemné formě v nadepsaných, podepsaných a případně i verzovaných dokumentech s jasnou auditní stopou. Navrhovatel tvrdí, že zadavatel se rozhodl spoléhat na dokument vypracovaný „na slepo“ (arch. návrh) s minimálním zadáním navrhovatele, který byl následně modifikován hodinami audiozáznamů. Navrhovatel to považuje za chaotické a netransparentní. Navrhovatel upozorňuje, že některé požadavky, které zadavatel tvrdí v rozhodnutí o vyloučení, viděl navrhovatel na tomto místě poprvé.

89.         Navrhovatel dále upozorňuje na to, že zadání arch. návrhu v rámci výzvy k účasti mělo přibližně půl stránky a k samotným potřebám zadavatele se zadavatel odkázal na potřeby zadavatele uvedené v preambuli zadávací dokumentace. K jednotlivým požadavkům v zadávací dokumentaci se navrhovatel vyjadřuje v rámci přílohy vyjádření k podkladům označené jako „Komentáře navrhovatele k jednotlivým požadavkům mini katalogu.“ V tomto ohledu tvrdí navrhovatel následující.

90.         K požadavku zadavatele „vybudovat IT ekosystém nové generace s otevřenou architekturou (integrační platformu INET 2.0), který ulehčí a urychlí digitalizaci ekonomických a personálních agend,“ a má umožnit „větší míru vlastnictví a kontroly nad vyvíjenými agendami“ a požadavku na architekturu, která bude „primárně postavena na interním BPM pro definici a exekuci procesů napojeným na vrstvu business služeb komunikujících přes API s jednotlivými SW moduly“,navrhovatel uvádí: „MAGION nabídl dodání webových služeb, které umožní realizovat Architekturu primárně postavenou na interním BPM pro definici a exekuci procesů napojeným na vrstvu business služeb komunikujících přes API s jednotlivými SW moduly. MAGION nabídl dodávku integrační platformy dle požadavků zadavatele např. Microsoft Integration Services, zadavatel ale explicitně uvedl, že tento požadavek není vylučovací(!). K tomu viz záznam z jednání 17. 10. 2022 (čas 1:09:30), kdy MAGION dodávku nabídl. Viz záznam z jednání 17. 10. 2022 (čas 1:03:30 a 1:12:28), kdy zadavatel uvedl, že požadavek není vylučovací.“

91.         Navrhovatel k požadavku zadavatele na jednotný vizuální styl, definované rozhraní a scénáře interakce pro různé typy uživatelů, k požadavku na business logiku založenou na dobře definovaných business službách a procesech, které „obalí“ funkčnosti interních nebo externích SW modulů a k požadavku na oddělení rozhraní a implementaci funkčnosti/služeb, které mají dle zadavatele umožnit flexibilitu v implementaci procesů, které jsou ušité na míru individualizovaných agend a skládají se z funkčností napříč celou integrační platformou uvádí: „MAGION nabídl dodání webových služeb, které umožní realizovat jednotný vizuální styl ekosystému, definované rozhraní a scénáře interakce pro různé typy uživatelů tak, aby jednotlivé SW moduly byly pro uživatele transparentní. MAGION navíc uvažoval o dodání veškeré funkčnosti nabízeného systému v jednotném webovém prostředí. Viz dokument „Architektonický návrh/koncepce otevřeného informačního systému pro Masarykovu univerzitu“, kapitola 3. Koncepce EIS rozvoje API, odeslaném 9.9.2021 Masarykově univerzitě. A dále na jednání dne 17. 10. 2022 MAGION deklaroval, že se zaváže vyrobit webové služby, které pokryjí celý systém na úrovni úloh a REST API na úrovni číselníků, ponechá MU stávající služby a připraví rozhraní pro všechny úlohy, které v systému jsou a u nichž takové rozhraní dává smysl.“

92.         Obecně k těmto požadavkům zadavatele navrhovatel dodává, že tyto požadavky, dle svého názoru splňuje. Dále navrhovatel upozorňuje na to, že tyto požadavky nejsou reflektovány v rozhodnutí o vyloučení.

93.         Závěrem se navrhovatel vypořádává s požadavkem zadavatele na HW architekturu postavenou na principech vysoké dostupnosti a uvádí, že „nabídl, že dodané služby a celý systém bude možno provozovat v prostředí cloudu, díky čemuž bude HW architektura postavena na principech vysoké dostupnosti (HA – high availability). Viz zápis z jednání 17. 10. 2022 bod 5.“

94.         Ve svém vyjádření k podkladům navrhovatel k uvedeným požadavkům zadavatele, které byly obsaženy v zadávací dokumentaci uvádí, že se jednalo o jediné zadání, které navrhovatel pro zpracování arch. návrhu obdržel a arch. návrh navrhovatele byl tedy zpracován jako pouhá koncepce, naznačení přístupu, jakým tyto obecné potřeby zadavatele naplnit. Navrhovatel dodává, že až na základě této koncepce měl zadavatel identifikovat, co vše bude od nového informačního systému požadovat.

95.         Navrhovatel dále upozorňuje na to, že k jeho vyloučení došlo poté, kdy byl vyzván k předložení velmi přibližné představy o hodnotě svého řešení, přičemž navrhovatel ji formuloval na úrovni asi 10 000 000,- Kč, kterou navrhovatel považuje za naprosto realistickou. Navrhovatel vyvozuje, že byl vyloučen na základě toho, že tento jeho odhad je v příkrém rozporu s představou zadavatele, kterou dle vyjádření navrhovatele zadavatel prezentoval na úrovni 100 000 000,- Kč. Dle navrhovatele došlo k jeho vyloučení nikoliv na základě kvality, nýbrž proto, že v tomto ohledu je řešení navrhovatele cenově bezkonkurenční. K tomu navrhovatel také dodává, že zadavatelova „touha vynaložit větší částku“ byla motivací pro výběr druhu zadávacího řízení, a opakuje, že se ukazuje, že na předmět plnění bylo možné realizovat „běžné“ otevřené řízení.

96.         Tuto část vyjádření k podkladům navrhovatel uzavírá tím, že trvá na svém návrhu, tedy na tom, že k jeho vyloučení došlo nezákonně, a to ze všech uvedených důvodů.

97.         Následně se navrhovatel vyjadřuje k podkladům opatřeným v rámci nahlížení. K této části uvádí navrhovatel následující.

98.         Navrhovatel se vyjadřuje k okolnostem, o kterých se dozvěděl v rámci svého vzdáleného přístupu do spisu dne 3. 4. 2023, kdy mu bylo Úřadem vzdáleně zpřístupněno nahlédnutí do spisu, který je veden v rámci tohoto správního řízení (a současně do spisu, který byl veden pod spis. zn. ÚOHS-S0106/2023/VZ).

99.         Navrhovatel uvádí, že z dokumentů správního spisu je zřejmé, že zadavatel učinil rozhodnutí o vhodnosti řešení některých dalších účastníků zadávacího řízení. Následně navrhovatel uvádí, že z dokumentů spisu nevyplývá, že by zadavatel schválil řešení dodavatele [anonymizováno].

100.     Z této skutečnosti navrhovatel vyvozuje, že ostatním účastníkům na rozdíl od navrhovatele zadavatel umožnil předložit jejich řešení a že v případě dodavatele [anonymizováno] zadavatel s tímto dodavatelem stále vede jednání v rámci soutěžního dialogu.

101.     Závěrem navrhovatel navrhuje, aby Úřad zrušil rozhodnutí o vyloučení a veškeré navazující úkony pro jejich nezákonnost.

IV.          ZÁVĚRY ÚŘADU

102.     Úřad přezkoumal na základě § 248 a následujících ustanovení zákona případ ve všech vzájemných souvislostech a po zhodnocení všech podkladů, zejména relevantních částí dokumentace o zadávacím řízení a vyjádření předložených účastníky řízení rozhodl tak, že zamítl návrh navrhovatele, neboť nebyly zjištěny důvody pro uložení nápravného opatření. K tomu Úřad uvádí následující.

Relevantní ustanovení právních předpisů

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

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

105.     Dle § 68 odst. 1 zákona je zadavatel oprávněn použít řízení se soutěžním dialogem za splnění podmínek uvedených v § 60 zákona.

106.     Dle § 69 odst. 1 zákona vede zadavatel s účastníky zadávacího řízení soutěžní dialog s cílem nalézt řešení způsobilá splnit potřeby zadavatele.

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

108.     Ustanovení § 69 odst. 4 zákona stanoví, že soutěžní dialog může probíhat v postupných fázích s cílem snížit počet řešení, o nichž se bude jednat, podle § 112 zákona, pokud si tak zadavatel vyhradil v oznámení o zahájení zadávacího řízení.

109.     Dle § 69 odst. 5 zákona pokračuje zadavatel v soutěžním dialogu do doby, než rozhodne, zda předložená řešení jsou vhodná. Účastníka zadávacího řízení, jehož řešení není vhodné, ze zadávacího řízení vyloučí.

110.     Ustanovení § 60 zákona stanoví podmínky užití jednacího řízení s uveřejněním a ve spojení s § 68 odst. 1 zákona také pro řízení se soutěžním dialogem. Dle § 60 odst. 1 může zadavatel použít jednací řízení s uveřejněním, pokud:

a.             potřeby zadavatele nelze uspokojit bez úpravy na trhu dostupných plnění,

b.             součástí plnění veřejné zakázky je návrh řešení nebo inovativní řešení,

c.              veřejná zakázka nemůže být zadána bez předchozího jednání z důvodu zvláštních okolností vyplývajících z povahy, složitosti nebo právních a finančních podmínek spojených s předmětem veřejné zakázky, nebo

d.             nelze stanovit technické podmínky odkazem na technické dokumenty podle § 90 odst. 1 a 2 zákona.

111.     Dle článku 30 odst. 1 směrnice se dialogu mohou zúčastnit jen ty hospodářské subjekty, které k tomu byly veřejným zadavatelem vyzvány na základě posouzení předložených informací. Veřejní zadavatelé mohou v souladu s článkem 65 směrnice omezit počet vhodných zájemců, kteří budou vyzváni k účasti v zadávacím řízení. Veřejná zakázka se zadává výhradně na základě kritéria nejlepšího poměru mezi cenou a kvalitou v souladu s čl. 67 odst. 2 směrnice.

112.     Dle článku 30 odst. 4 směrnice se soutěžní dialog může konat v postupných fázích s cílem snížit počet řešení, jež budou během jednotlivých fází dialogu projednávána, za použití kritérií pro zadání veřejné zakázky stanovených v oznámení o zahájení zadávacího řízení nebo v popisné dokumentaci. Veřejný zadavatel v oznámení o zahájení zadávacího řízení nebo v popisné dokumentaci uvede, zda této možnosti využije.

113.     Směrnice dále v článku 30 odst. 5 stanoví, že veřejný zadavatel pokračuje v dialogu do té doby, než nalezne jedno nebo více řešení, která jsou způsobilá ke splnění jeho potřeby. Dále v odst. 6 ustanovení směrnice stanoví, že poté, co byl dialog prohlášen za ukončený, a poté, co o tom byli informováni zbývající účastníci, vyzve veřejný zadavatel každého z účastníků k podání jejich konečných nabídek na základě jednoho nebo více řešení předložených a upřesněných během dialogu. Tyto nabídky musí obsahovat všechny prvky, které jsou nezbytné a požadované pro realizaci projektu.

114.     Článek 65 směrnice upravuje snížení počtu jinak kvalifikovaných zájemců, kteří mají být vyzváni k účasti. V odst. 1 ustanovení směrnice stanoví, že v užších řízeních, jednacích řízeních, v soutěžním dialogu a inovačním partnerství mohou veřejní zadavatelé omezit počet zájemců splňujících kvalifikační kritéria pro výběr, které vyzvou k podání nabídky nebo k dialogu, za předpokladu, že je k dispozici minimální počet kvalifikovaných zájemců v souladu s odstavcem 2 ustanovení.

115.     Dle článek 65 v odst. 2 směrnice veřejní zadavatelé uvedou v oznámení o zahájení zadávacího řízení nebo ve výzvě k potvrzení zájmu objektivní a nediskriminační kritéria nebo pravidla, která mají v úmyslu použít, minimální počet zájemců, které mají v úmyslu vyzvat, a případně jejich maximální počet.

116.     Dle § 245 odst. 1 zákona zadavatel do 15 dnů od doručení námitek odešle rozhodnutí o námitkách stěžovateli. V rozhodnutí uvede, zda námitkám vyhovuje nebo je odmítá; součástí rozhodnutí musí být odůvodnění, ve kterém se zadavatel podrobně a srozumitelně vyjádří ke všem skutečnostem uvedeným stěžovatelem v námitkách. Pokud zadavatel námitkám vyhoví, sdělí v rozhodnutí současně, jaké provede opatření k nápravě.

Zjištěné skutečnosti

117.     Dne 29. 4. 2021 odeslal zadavatel Oznámení o zahájení zadávacího řízení do Věstníku veřejných zakázek pod ev. č. F2021-015549, které bylo ve Věstníku uveřejněno dne 3. 5. 2021 a dále dne 29. 4. 2021 odeslal Oznámení o zahájení zadávacího řízení do Úředního věstníku Evropské unie, které bylo v Úředním věstníku uveřejněno dne 4. 5. 2021 (dále jen „oznámení“).

118.     Dne 3. 5. 2021 zadavatel na svém profilu, který byl uveřejněn ve Věstníku veřejných zakázek dne 9. 11. 2010 formulářem s ev. č. 6005249452001 (dále jen „profil zadavatele“), uveřejnil dokument označený jako „Dokumentace řízení se soutěžním dialogem“ (dále jen „zadávací dokumentace“).

119.     Předmětem veřejné zakázky je podle bodu 2. zadávací dokumentace „…otevřený informační systém pro Masarykovu univerzitu, včetně modulů personalistika a mzdy a ekonomika, tedy ekonomicko-personálního informačního systému s otevřeným API, které umožní zákaznický vývoj a rozvoj procesů a funkčností pro Masarykovu univerzitu, jeho nasazení do provozu na všech fakultách a dalších součástech MU, podpora tohoto provozu a další rozvoj EPIS, a to dle požadavků, které budou finálně specifikovány v průběhu soutěžního dialogu.“ Dále v tomto bodě zadavatel konstatuje, že „…s ohledem na specifika předmětu veřejné zakázky považuje za nezbytné jednat s účastníky zadávacího řízení o bližším vymezení předmětu veřejné zakázky a o obchodních podmínkách budoucího závazkového smluvního vztahu. Cílem zadavatele je nalézt takovou podobu bližšího vymezení předmětu veřejné zakázky a obchodních podmínek (tj. takové řešení), která bude způsobilá splnit potřeby zadavatele. Zadavatel dále konstatuje, že výstupem soutěžního dialogu bude závazný vzor smlouvy nebo katalog závazných smluvních ustanovení, která se následně stanou nedílnou součástí zadávacích podmínek této veřejné zakázky. Zadavatel může během soutěžního dialogu projednat veřejnou zakázku ze všech hledisek (§ 69 odst. 2 ZZVZ).“

120.     V rámci zadávací dokumentace zadavatel nastínil výchozí stav v oblasti ekonomických informačních systémů u zadavatele, jeho motivaci pro pořízení nového ekonomického informačního systému a potřeby, které zadavatel považuje za důležité naplnit, když v bodě 1. 5 zadávací dokumentace stanovil, že „[p]ro dosažení cílů v oblasti elektronizace jednotlivých ekonomických a personálních agend stanovených ve Strategickém záměru MU jsou nutné tak rozsáhlé změny ve fungování ekonomického a personálního systému (EPIS), že se MU rozhodla přistoupit k jeho generační obměně a vypsat toto řízení. Stávající generace EPIS již nedostačuje požadavkům a potřebám univerzity po stránce dat a zpracovatelských funkcí, zejména po stránce integračních a komunikačních rozhraní. Cílem MU v rámci současného strategického rámce je vybudovat IT ekosystém nové generace s otevřenou architekturou (integrační platformu INET 2.0), který ulehčí a urychlí digitalizaci ekonomických a personálních agend. Současně umožní větší míru vlastnictví a kontroly nad vyvíjenými agendami.“ Zadavatel na tomto místě stanovil „Aktuální potřeby MU v kontextu řízení“:

• Architektura bude primárně postavena na interním BPM pro definici a exekuci procesů napojených na vrstvu business služeb komunikujících přes API s jednotlivými SW moduly.
• Bude mít jednotný vizuální styl, definované rozhraní a scénáře interakce pro různé typy uživatelů – jednotlivé SW moduly budou pro uživatele transparentní (nebude muset řešit, k jakému IT systému přistupuje).
• Business logika bude založena na dobře definovaných business službách a procesech, které “obalí” funkčnosti interních nebo externích SW modulů.
• Oddělení rozhraní a implementace funkčností/služeb umožní flexibilitu v implementaci procesů, které jsou ušité na míru individualizovaných agend a skládají se z funkčností napříč celou integrační platformou.
• HW architektura bude postavena na principech vysoké dostupnosti (HA – high availability).

121.     Zadavatel v bodě 3.2 zadávací dokumentace a shodně v bodě 4.2 dokumentu ze dne
26. 7. 2021 označeném jako „Výzva k účasti v soutěžním dialogu“ (dále jako „výzva k účasti“) stanovil předpokládaná kritéria pro určení ekonomické výhodnosti při hodnocení nabídek podaných po ukončení soutěžního dialogu, a to tato:

• navržená architektura, její moduly a použité technologie řešení,
• kvalita a funkčnost API pro rozšiřování řešení zákazníkem,
• navržený způsob integrace s externími systémy,
• ne-funkční specifikace řešení, jako např. výkonové parametry, doby odezvy, bezpečnost řešení apod.,
• řešení vysoké dostupnosti a jeho provozní nároky,
• funkční vlastnosti řešení,
• inovační aspekty,
• organizace, kvalifikace nebo zkušenost osob, které se mají přímo podílet na plnění veřejné zakázky,
• navržený projektový přístup implementace,
• úroveň servisních služeb včetně technické pomoci,
• licenční politika a model spolupráce,
• podmínky a lhůta dodání a dokončení plnění.

122.     V bodě 2.2. písm. a) výzvy k účasti zadavatel stanoví, že dodavatelé do 10. 9. 2021 do 10:00 hodin samostatně zpracují a zadavateli prostřednictvím systému E-ZAK (elektronický nástroj zadavatele) předloží architektonický návrh/koncepci (dále také jako „arch. návrh“). V příloze č. 1 k výzvě zadavatel stanoví doporučení na zpracování arch. návrhu.

123.     Dle bodu 2.2. písm. b) výzvy k účasti bude arch. návrh „základem pro další jednání s jednotlivými dodavateli v rámci 2. stage – technologické ověření a model spolupráce.“

124.     Dle bodu 2.22 písm. c) výzvy k účasti zadavatel povede s účastníky zadávacího řízení soutěžní dialog s cílem nalézt řešení způsobilé splnit potřeby zadavatele dle § 69 odst. 1 zákona. Dle písmena d) daného bodu výzvy k účasti pak zadavatel neprodleně informuje účastníky zadávacího řízení a vyzve každého z účastníků zadávacího řízení k podání nabídek na nalezené řešení podle § 69 odst. 6 zákona. Součástí výzvy k podání nabídky bude zadávací dokumentace zpracovaná mimo jiné na základě výsledků jednání v soutěžním dialogu.

125.     Zadavatel v bodě 3.2. výzvy k účasti konstatuje, že „ohledem na specifika předmětu veřejné zakázky považuje za nezbytné jednat s účastníky zadávacího řízení o bližším vymezení předmětu veřejné zakázky a o technických a obchodních podmínkách budoucího závazkového smluvního vztahu. Cílem zadavatele je nalézt takovou podobu bližšího vymezení předmětu veřejné zakázky, technických a obchodních podmínek (tj. takové řešení), která bude způsobilá splnit potřeby zadavatele na straně jedné, a na straně druhé bude v souladu s právním prostředím, v jehož rámci bude otevřený informační systém implementován a provozován.“

126.     Příloha č. 1 výzvy k účasti stanoví doporučení pro zpracování arch. návrhu. Zadavatel v něm uvádí, že „[a]rchitektonický koncept by měl primárně mířit nikoli na funkční stránku SW systémů, ale na jejich API a stránku architektonickou a technologickou: jakými API jsou tyto systémy vybaveny a jaké integrační a komunikační vazby umožňují budovat vlastními silami zákazníka, bez nutnosti součinnosti dodavatele.“ Dále konstatuje, že „[v] požadovaném konceptu by měla být dokumentována reálná možnost MU jako odběratele dále rozšiřovat a modifikovat dodané vybavení nezávisle na dodavateli systému tak, aby dosáhla vzájemného funkčního propojení s dalšími užívanými počítačovými programy či komponentami, a to ve všech uvažovaných úrovních (datové, aplikační logiky a uživatelského interface). To celé v souladu s požadavkem na vyřešení vzniku IT ekosystém nové generace s otevřenou architekturou (integrační platformu INET 2.0 vyvíjenou MU).“

127.     Dále příloha obsahuje oblasti, u kterých zadavatel preferuje podrobnější popis, a to následující oblasti:

• jak je řešena modularita a otevřenost s využitím API,
• jak je řešena integrace s externími systémy – obsahuje-li řešení např. samostatnou integrační vrstvu/modul,
• jaké typy datových úložišť řešení podporuje (relační, dokumentové apod.),
• jak je řešena oblast bezpečnosti, včetně autorizace a autentizace,
• jaké jsou způsoby provozování řešení (on premise nebo cloud a jejich kombinace),
• zda a v jaké podobě řešení obsahuje podporu pro uživatelský reporting a manažerské dashboardy.

128.     Navrhovatel zadavateli předložil dokument s označením „Architektonický návrh/koncepce otevřeného informačního systému pro Masarykovu univerzitu“ (dále jen „arch. návrh navrhovatele“), který byl do elektronického nástroje doručen dne 9. 9. 2021.

129.     V bodě 4.1 arch. návrhu navrhovatele (od s. 117) navrhovatel představuje koncepci modularity informačního systému a otevřenost systému s využitím API, když uvádí, že „[s]tandardní API systému EIS Magion je tvořeno standardně dodávanými webovými službami. Tyto služby lze použít jako základ pro vývoj vlastních webových aplikací, kdy webová aplikace zajišťuje vzhled, zobrazení a editaci dat a vrstva služeb se stará o business logiku aplikace a zajišťuje komunikaci s databází,“ dále navrhovatel uvádí, že „[s]oučástí dodávky EIS Magion bude sada standardních webových služeb, které budou pokrývat většinu základní funkcionalitu EIS Magion. Každá služba bude zahrnovat metody pro vytvoření, změnu, odstranění nebo storna a načítání entity, dále podle charakteru úlohy i specifické akce, kterými lze s danou entitou manipulovat. Toto API je členěné prostřednictvím jmenných prostorů služeb nejprve na základní okruhy úloh (Systém, Číselníky, Účetnictví, Ekonomika, Personalistika …) a dále uvnitř této vrstvy podle jednotlivých úloh (odpovídajících zhruba úlohám v desktopovém klientovi).

130.     Ke koncepci řešení integrace s externími systémy navrhovatel dále v bodě 4.2 arch. návrhu navrhovatele uvádí: „Pro integraci s externími systémy existuje zvláštní vrstva webových služeb. Služby pro integraci šířeji používaných systémů (např. kolejní a menzovní systém) jsou použitelné pro více zákazníků, ale v této vrstvě služeb se obecně počítá spíše s vývojem API podle zadání konkrétního zákazníka, které bude reflektovat specifika daného systému. Počítá se s obousměrným přenosem dat mezi externím systémem a EIS Magion (tedy zápis entit do EIS Magion i poskytnutí dat z EIS Magion do externího systému).

131.     V bodě 4.5 arch. návrhu navrhovatele se navrhovatel dále zabývá koncepcí provozování řešení, k čemuž uvádí: „IS Magion umožňuje kombinace případně jakoukoliv z variant aplikací, a to jak on premise, tak v cloudu. Konkrétní varianta vždy vychází z reálných potřeb zákazníka s ohledem na bezpečnost, rychlost, a vlastní IT infrastrukturu zákazníka.“

132.     Z dokumentace o zadávacím řízení Úřad zjistil, že v rámci soutěžního dialogu proběhly schůzky zástupců zadavatele se čtyřmi dodavateli (včetně navrhovatele), kteří podali žádost k účasti v soutěžním dialogu a splnili podmínky účasti. S navrhovatelem proběhlo celkem sedm schůzek, a to:

• dne 1. 12. 2021 (technicko-architektonické jednání),
• dne 10. 12. 2021 (personální jednání),
• dne 16. 12. 2021 (ekonomické jednání),
• dne 28. 1. 2022 (2. technologicko-architektonické jednání),
• dne 28. 6. 2022 (jednání v oblasti licenční, cenové a partnerské politiky),
• dne 30. 8. 2022 (jednání o projektovém přístupu pro EPIS a jeho provoz) a
• dne 17. 10. 2022 (2. jednání o projektovém přístupu pro EPIS a jeho provoz).

133.     Dne 30. 12. 2022 zadavatel navrhovatele svým rozhodnutím o vyloučení z téhož dne (dále jen „rozhodnutí o vyloučení“) vyloučil ze zadávacího řízení.

134.     Dle rozhodnutí o vyloučení byl navrhovatel vyloučen dle § 69 odst. 5 zákona, kdy zadavatel uvádí, že dle něj „má zadavatel povinnost účastníka, jehož řešení není vhodné, ze zadávacího řízení vyloučit.“

135.     Jako hlavní důvod pro vyloučení navrhovatele zadavatel uvádí rozpor mezi potřebami Masarykovy univerzity v oblasti integrace a vývoje funkčnosti nad ekonomicko-personálním systémem a nabízeným řešením, jeho celkovou koncepcí a vizí jeho vývoje do budoucna.

136.     Zadavatel uvádí v rozhodnutí o vyloučení konkrétní důvody, proč považuje řešení navrhovatele za nevhodné. Zadavatel uvádí následující důvody:

• „Navrhovatel v současné době nedisponuje rozsáhlým otevřeným API, které by umožňovalo přístup k datům a funkcím bez nutnosti zadavatelské objednávky a vývoje těchto rozhraní na klíč přímo od navrhovatele. Současně zadavatel uvádí, že seznam 60 metod v 16 oblastech, které v rámci soutěžního dialogu navrhovatel předložil, je oproti ostatním řešením na trhu značně omezený a pro potřeby zadavatele nepostačující.
• V průběhu soutěžního dialogu navrhovatel navrhoval vývoj a zpřístupnění strojově generovaných API, která by zadavatel umožnil zpřístupnit k jednotlivým položkám v podkladové bázi. Na rozdíl od API standardně a otevřeně nabízených všem zákazníkům u jiných dodavatelů je API navrhovatele zásadně omezeno, když umožňuje realizovat „atomické“ operace CRUD (Create, Read, Update, Delete) pouze nad konkrétními datovými položkami. Takové API má podle zadavatele nedostatky ve srovnání s plnohodnotným API, a to:

o   Veškerá logika daného procesu musí být vyvinuta na straně zadavatele a rozdělena potenciálně do mnoha atomických operací, které jsou pak volány jednotlivě ze strany zadavatele. Naproti tomu plnohodnotné API umožňuje jedno volání ze systému zadavatele a o rozpad požadavku na tyto atomické operace se stará dodavatelský systém.

o   Automaticky generované́ API je vystaveno riziku nekompatibility při jakékoliv změně datové struktury.

o   Zadavatel rozumí, že dodávka plnohodnotného API je ze strany Magion možná na základě objednávky, nacenění a vyčkání na realizaci, ale tento model je pro potřeby MU příliš nevhodný a omezující strategické ambice zadavatele.

• V průběhu soutěžního dialogu bylo API zadavateli představeno jakožto API realizované na základě požadavků zadavatele a pouze pro zadavatele. Podle zadavatele mu to znemožňuje realizovat vývoj řešení pro třetí strany, které by tato API využívaly, neboť hrozí riziko, že pokud by navrhovatel vnímal řešení nabízené zadavatelem ostatním veřejným vysokým školám jako konkurenční, nemusel by jim navrhovatel API zpřístupnit vůbec, popř. jen za komerčně nevýhodných podmínek.
• Navrhovatelem nabízené řešení má technologické omezení na úrovni frontendu, kdy se navrhovatel teprve chystá nasadit (nebo velmi nedávno nasadil) modernější verzi svého desktopového řešení, pořád ale založeného na technologii PowerBuilderu. Dalším důvodem je zatímní neexistence klientů pro mobilní zařízení, které zatím není v plánu. Konkurence dle zadavatele již nabízí jak plnohodnotné aplikace pro mobilní zařízení, tak platformy pro vývoj klientů pro tento typ zařízení.
• Zadavatel taktéž uvádí, že navrhovatel nemá dostatečnou zkušenost s provozováním svého řešení v cloudu. Zadavatel považuje za nerealistické cloudové řešení navrhovatele bez dostatečných praktických zkušeností s provozováním vlastního systému mohlo odpovídat jiným řešením, která jsou vyvíjena a umístěna v cloudu (v podobě SaaS – Software as a Service). Provoz řešení jako SaaS v cloudovém prostředí by dle zadavatele vyžadovalo změnu architektury navrhovatelova řešení, což kvůli časové náročnosti neodpovídá aktuálním potřebám zadavatele.
• Dále řešení navrhovatele nenabízí integrační platformu ESB (enterprise service bus) alespoň se základními funkcemi, která by umožnila jednoduchou integraci řešení navrhovatele s řešením zadavatele a řadou dalších systémů, které zadavatel v IT ekosystému provozuje. Neexistence této platformy by zadavateli též omezila možnost prodeje zadavatelem vyvinutého řešení a jeho integrace do IT prostředí jiných veřejných vysokých škol.
• Řešení navrhovatele také nenabízí další specifické funkce pro automatizaci digitalizace a individualizaci agend samotnými uživateli (skriptování, uživatelský reporting, chatboti, apod.). Zadavatel dodává, že v řadě řešení nabízených konkurenty se tyto možnosti vyskytují.“

137.     Zadavatel své rozhodnutí o vyloučení navrhovatele uzavírá shrnutím, že „…řešení dodávané dodavatelem pouze na míru (formou zakázkového vývoje) je pro MU nevhodné. Je to proto, že nutnost konzultovat zadání, vyčkat na jeho nacenění a implementaci, představuje zásadní zdržení a omezuje rychlost a flexibilitu vývoje MU. Závislost na ochotě dodavatele systému zpřístupnit některé části svého řešení (např. API) ostatním odběratelům může rovněž vést k omezení možnosti nabízet Masarykovou univerzitou vyvinutého řešení ostatním VVŠ v ČR. Zadavatel proto konstatuje, že dosavadní průběh soutěžního dialogu potvrdil, že nabízené řešení MAGION system, a.s., je technologicky nevhodné a neobsahuje řadu vlastností a funkcí, které pro strategický rozvoj ERP Masarykova univerzita požaduje. Navíc spousta i dodávaných nebo slibovaných funkcionalit je závislá na zakázkovém vývoji ze strany Magionu, aktuálně nejsou v systému obsaženy a Magion ani neplánuje jejich vývoj bez explicitního požadavku (a úhrady) ze strany MU,“ zadavatel zároveň dodává, že „[z]ároveň platí, že ani realizace všech Magionem navržených aspektů nevede ke vzniku systému, který by byl vhodný vzhledem k cílům a strategickým záměrům Masarykovy univerzity.“

138.     Dne 16. 1. 2023 podal navrhovatel proti rozhodnutí o vyloučení námitky a taktéž námitky proti volbě druhu zadávacího řízení z téhož dne (dále jen „námitky“).

139.     V bodě 2.40 námitek navrhovatel tvrdí, že je přesvědčen, že „důvodem pro vyloučení jakéhokoli dodavatele nemůže být obava z jeho konkurenčního vztahu k Ústavu a samotná skutečnost, že tu nějaký konkurenční vztah vzniká, je u veřejného zadavatele na pováženou.“ V závěru tohoto bodu navrhovatel dodává, že „[p]akliže navíc používá ÚVT veřejných prostředků na to, aby v nějakém ohledu konkuroval výrobcům a dodavatelům ekonomických informačních systémů, pak takový postup Ústavu může v krajním případě i naplnit aspekty nekalé soutěže a porušovat pravidla hospodářské soutěže (jak může stěžovatel nebo jiný dodavatel ekonomických informačních systémů pro VVŠ vůbec efektivně čelit konkurenci MU s jejím rozpočtem a možnostmi?). Stěžovatel v tuto chvíli nemá jasnou představu o tom, jak rozsáhlé a seriózní plány v tomto ohledu ÚVT má, neboť konečná specifikace předmětu veřejné zakázky dosud nebyla zadavatelem vytvořena. Nevylučuje však, že pakliže by to považoval za důvodné, obrátí se s případným podnětem v této věci i na sekci hospodářské soutěže Úřadu.“ V bodě 2.41 námitek pak citovaný bod navrhovatel shrnuje tak, že „[d]ůvod vyloučení tak je nejen v rozporu s reálným průběhem jednání a nepravdivý, ale je zde pravděpodobnost, že porušuje i další právní předpisy (předpisy na ochranu hospodářské soutěže a vysokoškolský zákon).“

140.     K bodu 2.40 a 2.41 námitek navrhovatele se zadavatel vyjadřuje na straně 10 a 11 rozhodnutí zadavatele o námitkách ze dne 31. 1. 2023 (dále jen „rozhodnutí o námitkách“). K daným bodům námitek uvádí zadavatel následující:

„Zadavatel nehodlá vyvíjet nadstavbu nad ERP systémem jako komerční činnost za účelem zisku. Hodlá však v souladu s 3E a povinnostmi řádného hospodáře s veřejnými prostředky co nejefektivněji naložit se softwarovým vývojem, který učiní pro svou potřebu. Zadavatel má i strategické cíle v oblasti rozvoje tohoto typu informačních systémů. Zamýšlí tedy řešení, které vytvoří primárně pro vlastní potřebu, nabídnout v konkrétních případech k užití i jiným VŠ, které budou mít kompatibilní ekonomický a personální systém, aby předešel tomu, že i jiné VŠ budou vynakládat další veřejné prostředky na opakování totožného vývoje, který již proběhne na MU. Z toho důvodu Zadavatel nepovažuje za vhodné vytvářet své nadstavby nad systémem, kde jeho přenositelnost k jinému veřejnému Zadavateli bude záviset čistě na vůli poskytovatele EPIS systému, za kolik a zda vůbec bude souhlasit s poskytnutím potřebné licence k API podkladového systému. Zadavatel považuje za transparentnější obchodní model s veřejnými ceníky, poskytující jistotu, že licenci bude možno pořídit maximálně za tuto cenu, nebo případně nižší.“

Zadavatel na témže místě dodává, že „…neshledal porušení jakýchkoliv právních předpisů. Zadavatel poukazuje na skutečnost, že tuzemské VVŠ běžně provozují obdobné činnosti. Zadavatel tak například činí dlouhodobě v oblasti studijní, kdy systém původně vyvinutý pro jeho potřeby nabízí ostatním VŠ v ČR, a stejně tak činí i některé jiné VŠ. Výsledkem je vysoce konkurenční prostředí.“ Danou část rozhodnutí o námitkách uzavírá zadavatel tak, že „trvá na důvodu vyloučení č. 3 a uvádí, že tento plně koresponduje s informacemi, které zazněly na jednáních v rámci soutěžního dialogu, je pravdivý. Tvrzený rozpor s právními předpisy, ať už předpisy na ochranu hospodářské soutěže či zákonem o vysokých školách, je nepravdivý a irelevantní.“

Právní posouzení

141.     Navrhovatel ve svém návrhu brojí proti rozhodnutí zadavatele o vyloučení navrhovatele ze zadávacího řízení ze dne 30. 12. 2022 (dále jen „rozhodnutí o vyloučení“). Navrhovatel obecně k vadám rozhodnutí o vyloučení uvádí, že zadavatel při formulování důvodů pro vyloučení navrhovatele vychází z nepravdivých a neoprávněných úvah a východisek, v důsledku čehož dochází k nesprávným závěrům. V návrhu navrhovatel dále podrobně rozebírá jednotlivé důvody jeho vyloučení tak, jak je zadavatel uvedl v rozhodnutí o vyloučení, a v rámci své argumentace je vyvrací.

142.     Na úvod považuje Úřad za nutné v obecné rovině konstatovat, jak přistupovat k přezkumu vyloučení dodavatele v rámci řízení se soutěžním dialogem, které je zadávacím řízením specifické povahy, což je nutno zohlednit při přezkumu úkonů zadavatele v tomto druhu zadávacího řízení. K tomuto uvádí Úřad následující.

143.     Řízení se soutěžním dialogem (dále také jako „ŘSSD“), v němž je šetřená veřejná zakázka zadávána, je specifickým druhem zadávacího řízení, které má umožnit zadavatelům efektivně pořídit taková plnění, u nichž nejsou na počátku (při zahájení zadávacího řízení) schopni přesně specifikovat jejich předmět či jiné záležitosti s plněním související tak, aby byly naplněny veškeré podmínky pro použití jiných druhů zadávacího řízení. Řízení se soutěžním dialogem tak do určité míry prolamuje obecnou zásadu platnou u ostatních druhů zadávacího řízení, podle které je zadavatel povinen ještě před zahájením zadávacího řízení podrobně specifikovat své požadavky, a vymezit tak předmět plnění veřejné zakázky.

144.     Úřad dále v obecnosti konstatuje, že řízení se soutěžním dialogem probíhá standardně ve třech fázích. První fází je zahájení zadávacího řízení – de facto výzva k podání žádostí o účast neomezenému okruhu dodavatelů, podávání žádostí o účast a posouzení kvalifikace. V druhé fázi zadavatel po případném snížení počtu účastníků zadávacího řízení podle § 111 zákona (pokud toto bylo zadavatelem vyhrazeno) vyzývá kvalifikované účastníky, tj. účastníky, kteří prokázali splnění kvalifikace, k účasti v soutěžním dialogu, tedy k jednáním, jejichž účelem je nalezení vhodného způsobu řešení veřejné zakázky. Po ukončení vlastního soutěžního dialogu (druhé fáze) pak zadavatel vyzývá doposud nevyloučené účastníky k podání nabídek a dále činí navazující úkony směřující k ukončení zadávacího řízení (třetí fáze).

145.     Řízení se soutěžním dialogem je nutné odlišit od jiného specifického druhu zadávacího řízení, kterým je jednací řízení s uveřejněním (dále jen „JŘSU“), se kterým sdílí mnohé podobnosti. Zásadním rozdílem je skutečnost, že „[p]ředmět jednání je limitován pouze základními zásadami a dále požadavkem na ochranu informací dle odstavce 3 [§ 69 zákona], popřípadě zadávacími podmínkami, které si zadavatel sám stanoví (§ 39 odst. 1 [zákona]). ŘSSD tedy nabízí širší možnost jednání než JŘSU, ve kterém zadavatel je dále limitován také požadavkem na zachování minimálních technických podmínek…“ (ŠEBESTA, Milan, NOVOTNÝ, Petr, MACHUREK, Tomáš, DVOŘÁK, David a kol. § 69 [Průběh soutěžního dialogu]. In: ŠEBESTA, Milan, NOVOTNÝ, Petr, MACHUREK, Tomáš, DVOŘÁK, David a kol. Zákon o zadávání veřejných zakázek. 2. vydání. Praha: C. H. Beck, 2022, s. 542.).

146.     Úřad konstatuje, že cílem jednací fáze ŘSSD, tedy soutěžního dialogu stricto sensu, je nalézt pro zadavatele vhodná řešení, která budou odpovídat jeho potřebám a která budou dostatečně konkretizována, aby mohlo ze strany dodavatelů dojít k podání nabídky po ukončení soutěžního dialogu.

147.     Úřad na tomto místě odkazuje taktéž na metodiku Ministerstva pro místní rozvoj, kterou vydalo pro jednací řízení s uveřejněním a řízení se soutěžním dialogem[1], ve které k soutěžnímu dialogu uvádí: „Zadávací řízení by mělo být využíváno pro takové zakázky, které jsou složité, kdy zadavatelé nejsou schopni popsat požadovaná řešení, předmět zakázky, technické podmínky, kdy potřebná řešení ani nemusí být dostupná na trhu. Na rozdíl od jednacího řízení s uveřejněním zadavatel v řízení se soutěžním dialogem spíše pracuje s řešeními jako takovými – zadavatel v průběhu soutěžního dialogu hledá všechna vhodná řešení, která naplní požadavky a potřeby zadavatele.“

148.     V citované metodice Ministerstvo pro místní rozvoj dále k průběhu řízení se soutěžním dialogem dodává: „Samotný průběh zadávacího řízení není nijak regulován, zadavatel je vázán základními zásadami zadávání. Komunikace probíhá v souladu s pravidly dle § 211. V průběhu zadávacího řízení vede zadavatel soutěžní dialog s účastníky zadávacího řízení s cílem nalézt řešení způsobilá splnit potřeby zadavatele. Zadavatel se snaží nalézt jedno nebo i více řešení, které naplňují požadavky a potřeby zadavatele. V rámci soutěžního dialogu může zadavatel projednat veřejnou zakázku ze všech hledisek. Také může postupně v jednotlivých fázích snižovat počet řešení (dle § 112), pokud si to zadavatel vyhradil v oznámení o zahájení zadávacího řízení. Snižování provádí na základě kritérií kvality. Tato kritéria musí stanovit zadavatel v zadávací dokumentaci k okamžiku zahájení zadávacího řízení. Zadavatel postupuje v soutěžním dialogu do doby, než rozhodne, která předložená řešení jsou vhodná pro uspokojení potřeb zadavatele. Pro snižování řešení a vylučování nevhodných řešení není jasně dané pořadí, zadavatel by měl ve svých postupech zohlednit požadavek na dodržení základních zásad zadávání. Lze doporučit postup, kdy zadavatel nejdříve vyřadí nevhodná řešení a poté, pokud bude mít stále ještě velký počet vhodných řešení, sníží jejich počet. Jednání s jednotlivými účastníky nad vhodností jednotlivých řešení mohou trvat rozdílnou dobu dle složitosti jejich řešení. Účastníka, jehož řešení není vhodné, ze zadávacího řízení vyloučí [pozn. zvýrazněno Úřadem].“ K nevhodnosti řešení se dále metodika vyjadřuje následovně: „Co se týká vhodnosti řešení, musí zadavatel zohlednit, že nevhodné řešení není takové, které se zadavateli „nelíbí“, ale pouze takové, které skutečně není vhodné a neřeší zadavatelovy potřeby. Důvody nevhodnosti je potřeba uvést v rámci odůvodnění vyloučení účastníka zadávacího řízení.“

149.     Úřad předně přistoupil k posouzení jednotlivých bodů návrhu, ve kterých navrhovatel namítá nezákonnost rozhodnutí o vyloučení, popř. nezákonnost vedení zadávacího řízení. K této části návrhu uvádí Úřad následující.

Ke způsobu vedení řízení se soutěžním dialogem a výkladu pojmu „řešení“

150.     Navrhovatel v návrhu předně tvrdí, že v rámci ŘSSD z jeho strany doposud nedošlo k předložení uceleného řešení a navrhovatel k tomu nebyl ani ze strany zadavatele vyzván. Navrhovatel má za to, že dosavadní jednání byla vedena k upřesnění požadavků a představ zadavatele, přičemž až následně mělo ze strany zadavatele dojít k finálnímu specifikování požadavků a výzvě k předložení řešení. Dle navrhovatele tedy nemohlo dojít k aplikaci § 69 odst. 5 zákona, které pojem „řešení“ užívá, a to v kontextu vhodnosti či nevhodnosti pro případné vyloučení, ke kterému došlo v tomto případě.

151.     Úřad považuje za nutné vyložit nejprve zákonný pojem „řešení“ a zjistit, zda v předmětném zadávacím řízení došlo ze strany navrhovatele k jeho předložení zadavateli, resp. zda navrhovatel disponoval „řešením“, které bylo možné ze strany zadavatele hodnotit ve smyslu § 69 odst. 5 zákona.

152.     Úřad konstatuje, že není možné se ztotožnit s argumentací navrhovatele, v rámci které tvrdí, že doposud nedošlo k předložení řešení. Navrhovatel byl již v rámci výzvy k účasti vyzván ke zpracování a předložení arch. návrhu, který dne 9. 9. 2021 také zadavateli předložil. V případě navrhovatele se jednalo o obsáhlý dokument, který na 121 stranách popisoval koncepci vývoje informačního systému pro zadavatele. Zadavatel v bodě 2.2 písm. b) výzvy k účasti zároveň stanovil, že tento dokument bude základem pro další jednání s jednotlivými dodavateli. Jak vyplývá z dokumentace o zadávacím řízení a jak bylo již uvedeno výše, v následné fázi po předložení arch. návrhu zadavateli proběhlo sedm tematických jednání, v rámci kterých byl arch. návrh navrhovatele dále diskutován, a to mezi zadavatelem a navrhovatelem.

153.     Za „řešení“, jehož nalezení je dle § 69 odst. 1 zákona cílem ŘSSD, je tedy dle Úřadu nutné považovat právě navrhovatelem předložený arch. návrh spolu se specifikací či modifikací některých aspektů, ke kterým došlo v rámci soutěžního dialogu při proběhnuvších jednáních.

154.     Zákon v tomto ohledu neobsahuje ustanovení, které by požadovalo po proběhnutí jednací fáze dialogu zpracovat řešení účastníků soutěžního dialogu do určité formální podoby, resp. které by požadovalo po zadavateli, aby po proběhnutí jednací fáze dialogu vyzýval ještě účastníky soutěžního dialogu k předložení řešení v určité formální podobě, jak vyplývá z argumentace navrhovatele.

155.     Úřad má za to, že v rámci ŘSSD by se podle nastíněné logiky navrhovatele naprosto stíral rozdíl mezi řešením a nabídkou, když navrhovatel předpokládá ze strany zadavatele nejprve finální specifikaci předmětu plnění a výzvu dodavatelům k předložení řešení. Zákon předpokládá formalizovanou výzvu až v rámci ustanovení § 69 odst. 6, kdy stanoví, že zadavatel po ukončení soutěžního dialogu vyzve každého účastníka k podání nabídek na nalezená řešení, kdy daná výzva musí dle zákona obsahovat náležitosti stanovené v příloze č. 6 zákona. Pokud by platilo tvrzení navrhovatele, že je zadavatel povinen vyzvat účastníky zadávacího řízení i k předložení řešení před hodnocením jejich vhodnosti či nevhodnosti, lze na základě argumentace per analogiam dojít k závěru, že by i k této výzvě zákonodárce stanovil, jaké náležitosti musí taková výzva splňovat, jako to učinil u výzvy k podání nabídek. Žádné takové požadavky však nelze v zákoně nalézt, pročež Úřad konstatuje, že v případě předložení řešení není zadavatel povinen po proběhnutí jednací fáze dialogu formálně vyzývat a pojem řešení je nutno chápat toliko v neformálním smyslu jako souhrn informací a prohlášení, která účastník v rámci jednací fáze ve vztahu k předpokládané podobě předmětu plnění veřejné zakázky deklaruje.

156.     Na základě výše zmíněného Úřad konstatuje, že v rámci zadávacího řízení existuje určité řešení předložené navrhovatelem, jehož vhodnost je způsobilá být ze strany zadavatele hodnocena ve smyslu § 69 odst. 5 zákona.

157.     Navrhovatel dále v bodech 1.26 až 1.35 návrhu brojí proti vedení ŘSSD ze strany zadavatele, kdy shledává jeho nezákonnost, která dle něj spočívá ve skutečnosti, že vyloučení navrhovatele nebylo předem vyhrazeno zadavatelem, a tedy neproběhlo v souladu se směrnicí a mělo tak netransparentní a diskriminační charakter.

158.     Úřad k argumentaci navrhovatele uvádí, že nesprávně odkazuje na články 30 a 65 směrnice. Předmětná ustanovení směrnice totiž stanovují pravidla pro vedení soutěžního dialogu v postupných fázích, kdy dochází k postupnému snižování počtu řešení v rámci jednací fáze ŘSSD. Úřad považuje za nutné uvést, že na pravidla stanovená v článku 65 směrnice je v rámci článku 30 směrnice výslovně odkázáno v odst. 1 ustanovení, který cílí na omezení počtu vhodných zájemců, kteří budou vyzváni k účasti v zadávacím řízení. Článek 65 odst. 1 směrnice pak samostatně stanoví pravidla pro snížení počtu jinak kvalifikovaných zájemců v rámci soutěžního dialogu, které zadavatel vyzve k podání nabídky nebo k dialogu. Toto ustanovení opět cílí na omezení počtu účastníků, a to pro případ výzvy k účasti v řízení, nebo pro případ podání nabídky. Úřad konstatuje, že toto ustanovení směrnice tedy zjevně nedopadá na případ vyloučení pro nevhodnost řešení ve smyslu § 69 odst. 5 zákona. K tomu Úřad dodává, že článek 65 směrnice je do českého právního řádu transponován v § 111 zákona, k čemuž je nutné uvést, že postup snížení počtu účastníků zadávacího řízení dle § 111 zákona zadavatel výslovně v rámci zadávací dokumentace v bodě 1.11 písm. c) vyloučil, a nadto zároveň platí, že vyloučení účastníka řízení dle § 69 odst. 5 zákona nelze považovat za snížení počtu účastníků dle § 111 zákona, když institut snížení počtu účastníků je institutem, který se uplatní, je-li takto předem vyhrazeno zadavatelem, a to pouze ve fázi posouzení technické kvalifikace účastníků zadávacího řízení. V tomto případě došlo k vyloučení účastníka dle § 69 odst. 5 zákona, které následovalo až po ověření kvalifikace účastníků, včetně navrhovatele, a jeho vyloučení se nezakládalo na posouzení jeho technické kvalifikace, nýbrž na předloženém řešení. Postup podle § 69 odst. 5 zákona na rozdíl od postupu podle § 111 zákona nevyžaduje předchozí vyhrazení této možnosti zadavatelem, když z dikce předmětného ustanovení vyplývá, že posouzení vhodnosti a vyloučení účastníka pro nevhodnost řešení je povinností zadavatele. Zadavatel tak neměl povinnost vyhradit si možnost vyloučení podle § 69 odst. 5 zákona v zadávací dokumentaci.

159.     S ohledem na právě uvedené tak Úřad odmítá argumentaci navrhovatele ohledně údajně nezákonného vedení ŘSSD ze strany zadavatele, resp. ohledně vyloučení navrhovatele údajně v rozporu se směrnicí, čímž mělo být netransparentní a diskriminační, jako nedůvodnou.

K namítanému hodnocení stávajícího systému navrhovatele a údajně diskriminační povaze vyloučení

160.     Navrhovatel je, jak vyplývá z vyjádření obou účastníků řízení, současným dodavatelem informačního systému zadavatele (dále tento provozovaný systém jako „současný systém“ či „současné řešení“), který má být plněním na předmětnou veřejnou zakázku nahrazen. Navrhovatel v bodech od 1.13 návrhu uvádí, že zadavatel opakovaně v rámci výhrad vůči řešení navrhovatele v rozhodnutí o vyloučení hodnotí současný systém [pozn. navrhovatel používá označení „řešení“ v uvozovkách zřejmě v ohledu na předchozí bod návrhu, kdy tvrdí, že z jeho strany k předložení řešení ve smyslu § 69 zákona nedošlo] a identifikuje jeho údajné vady. Navrhovatel uvádí, že hodlá předložit jiné řešení, rozdílné od současného systému, přičemž uvádí, že bude ze současného řešení z části vycházet a z části bude aktualizováno, upraveno a doplněno. Navrhovatel má za to, že zadavatel hodnotí skutečnosti, které nejsou ze strany navrhovatele nabízeny. Navrhovatel současně spatřuje své vyloučení jako diskriminační právě proto, že je dle jeho názoru hodnoceno řešení současného systému. Úřad k tomuto bodu návrhu uvádí následující.

161.     Úřad tedy v tomto smyslu předně posoudil obsah rozhodnutí o vyloučení, přičemž uvádí, že v úvodu rozhodnutí o vyloučení zadavatel uvádí, že „[v]ýběrové řízení bylo vypsáno z důvodu, že řešení účastníka je zadavateli dobře známo a dlouhodobě mu nevyhovuje.“ Na základě jazykového výkladu však Úřad chápe dané konstatování zadavatele, které navrhovatel zmiňuje i v návrhu, jako odůvodnění, proč se zadavatel rozhodl pro zahájení ŘSSD na nahrazení současného systému. Pokud jde o jednotlivé důvody vyloučení, zadavatel je uvádí na straně 3 rozhodnutí o vyloučení a dle posouzení Úřadu zadavatel jednoznačně vztahuje nedostatky řešení k „řešení navrženému a diskutovanému se zástupci firmy Magion.“ Z obsahu rozhodnutí o vyloučení tak dle Úřadu nevyplývá, že by zadavatel hodnotil současný systém.

162.     Úřad dále uvádí, že samotný arch. návrh navrhovatele věnuje značnou část (strany 3-36) současnému systému, kdy navrhovatel uvádí historii vývoje, současný funkční a technologický stav a stav otevřenosti současného systému. I na dalších místech, která popisují koncepci vývoje řešení prezentovaného navrhovatelem v rámci zadávacího řízení, arch. návrh navrhovatele obsahuje pasáže, které se odkazují na současný systém a je zřejmé, že řešení navrhovatele vychází z části ze současného systému. Například v kapitole „Koncepce vývoje otevřeného IS, technologický popis“ navrhovatel uvádí: „EIS Magion během svého vývoje podporoval různé databázové technologie jako Informix, Oracle, Sybase SQL Anywhere, Sybase ASE, Microsoft SQL Server. V současné době je EIS Magion provozován na dvou základních databázových platformách a to Microsoft SQL Server a Oracle Database. Vývoj na různých platformách s sebou ovšem přináší i komplikovanost v souvislosti s odlišnostmi obou technologií. Z toho důvodu vývoj jádra systému probíhá s použitím SQL standardů, vycházeje ze standardu SQL-92, čímž je zajištěn jednotný programový kód na straně samotné aplikace EIS Magion.“ Tuto skutečnost ostatně přiznává i sám navrhovatel, když v návrhu uvádí, že „[t]oto budoucí řešení bude samozřejmě částečně vycházet ze stávajícího produktu Magion, ale bude ve všech potřebných oblastech upgradováno, upraveno či doplněno tak, aby vyhovělo požadavkům zadavatele…“ Pokud tedy navržené řešení vychází ze současného systému, který navrhovatel u zadavatele provozuje, je dle Úřadu legitimní, pokud zadavatel v rámci soutěžního dialogu některé aspekty a zkušenosti, které má z minulosti se současným systémem, promítne do hodnocení řešení, zvláště pak, pokud u některých prvků shledal nedostatečný vývoj oproti současnému systému. Navíc Úřad opakovaně zdůrazňuje, že v rámci rozhodnutí o vyloučení nespatřuje hodnocení současného systému, jakožto hodnocení vhodnosti či nevhodnosti řešení navrhovatele. Zadavatelovo tvrzení, o nevyhovujícím současném systému, jak Úřad cituje v předcházejícím bodě odůvodnění tohoto rozhodnutí, chápe Úřad jako odůvodnění jeho motivace k pořízení nového informačního systému. Až následné pasáže na straně 3 rozhodnutí o vyloučení lze chápat jako konkrétní důvody pro vyloučení, které nicméně vycházejí z technických aspektů nabízeného řešení navrhovatele. Jednotlivé důvody vyloučení budou samostatně přezkoumány níže v tomto rozhodnutí.

163.     Pokud jde o tvrzení navrhovatele v rámci repliky k vyjádření zadavatele o tom, že zadavatel se v rámci rozhodnutí o vyloučení navrhovatele ani jednou neodkázal na arch. návrh navrhovatele, Úřad konstatuje, že toto tvrzení neshledal pravdivým, když zadavatel v úvodu rozhodnutí o vyloučení uvádí, že hlavním důvodem vyloučení je rozpor mezi potřebami zadavatele a „nabízeným řešením, jeho celkovou koncepcí a vizí jeho rozvoje do budoucna.“ Dále zadavatel v rámci rozhodnutí o vyloučení odkazuje zjevně na arch. návrh navrhovatele, když uvádí, že „MU je si vědoma seznamu, který byl účastníkem předložen v rámci soutěžního dialogu, který popisuje asi 60 metod v 16 oblastech (zejména finanční kontrola, cesťáky a rozpočty),“ kdy zadavatel zjevně odkazuje na přehled úloh, které jsou obsaženy v kapitole 3 arch. návrhu navrhovatele od strany 44 daného dokumentu. V rámci dalších důvodů vyloučení má Úřad za to, jak je zmíněno i výše, že zadavatel hodnotí řešení, kdy jej pojímá jako souhrn informací z arch. návrhu, které jsou doplněny či modifikovány v průběhu soutěžního dialogu.

164.     S ohledem na uvedené Úřad konstatuje, že neshledal, že by zadavatel hodnotil jiné než v rámci zadávacího řízení navrhovatelem předložené a v soutěžním dialogu diskutované řešení. Úřad dále ani neshledal, že by byl navrhovatel vyloučen diskriminačně v souvislosti s tím, že by byl hodnocen současný systém, když v předcházejících bodech odůvodnění tohoto rozhodnutí Úřad jasně dovodil, že zadavatel současný systém nehodnotil.

K výtce zadavatele, že navrhovatel nevyvíjí určité technologie

165.     Dále navrhovatel brojí proti tomu, že zadavatel v rámci rozhodnutí o vyloučení hodnotí skutečnost, že nijak nevylepšil a nevyvinul současný systém, aby odpovídal budoucím potřebám zadavatele.

166.     V této souvislosti Úřad v prvé řadě uvádí, že v rámci přezkoumávaného úkonu zadavatele, tedy rozhodnutí o vyloučení, nenašel, že by jedním z důvodů pro vyloučení navrhovatele ze zadávacího řízení byla skutečnost, že navrhovatel po dobu trvání zadávacího řízení nevyvíjí svůj systém, jak v návrhu navrhovatel tvrdí. Vyjádření zadavatele ke stavu vývoje řešení navrhovatele obsahuje rozhodnutí o námitkách, ve kterém se zadavatel vyjadřuje ke stavu vývoje jednotlivých technologií navrhovatelem. Konkrétně zadavatel na str. 7 rozhodnutí o námitkách k vývoji rozhraní API uvádí: „Stěžovatel na schůzce 17. 10. 2022 potvrdil hrubý odhad současného pokrytí funkčností svého EIS zhruba na 30 % a nedokázal specifikovat, v jakém časovém horizontu by se dostal vlastním vývojem na 70-80 %. To doplnil návrhem, že mu můžeme udělat frontu práce (čas 44:00 záznamu). Tento postup by znamenal, že teprve po podpisu smlouvy bychom se začali bavit o analýze chybějících rozhraní a implementace by tím byla opožděna oproti jiným dodavatelům, kteří API disponují, o měsíce až roky. Vzhledem k tomu, že na trhu existují řešení, která daná rozhraní již existují a ze své vůle aktivně rozvíjí (a mají systémově naplánovánu dostatečnou kapacitu na tuto činnost), která jsou navíc dostupná všem relevantním zákazníkům, je pro Zadavatele neefektivní věnovat vlastní kapacity na to, aby potřebná rozhraní a jejich rozvoj specifikoval, neboť to vyžaduje aktivně řešit danou oblast (což zahrnuje mimo jiné potřebu sledovat technologické trendy, připravovat zadání, revidovat kvalitu implementace, uhradit realizované úpravy).“ Dále lze odkázat např. na stranu 11 rozhodnutí o námitkách, kdy zadavatel uvádí: „Stěžovatel vyvíjí své řešení jako klient – server, určeného pro desktopové nasazení u uživatelů (tlustý klient). Stěžovatel na jednáních se Zadavatelem nepředložil žádnou strategii přechodu na tenkého klienta a v podstatě deklaroval, že existují tři cesty (využití MVC .NET, využití komponenty Blazer a migrace z prostředí PowerBuilder) – (viz např. čas 21:00 záznamu z 1.12. 2021 z 1. architektonicko-technické schůzky). Bohužel není jasné, jak daleko v těchto oblastech je a která z cest se bude jevit jako životaschopná a kdy bude mít Magion plnohodnotné řešení. Např. na jednání 1.12.2021 zaznělo, že technologii PowerBuilderu pro vygenerování tenkého klienta neznají a budou ji teprve zkoušet (verze 2021, Stěžovatel dnes používá verzi 2019) – (čas 13:35 a 18:50 záznamu z 1. 12. 2021). Podobně nemá zkušenost ani s vytvořením REST API z PowerBuilderu (čas 34:00 záznamu z 1. 12. 2021). Navíc Stěžovatel opakovaně deklaruje, že desktopová aplikace bude použita pro účetní a pracovnice mzdového oddělení (čas 27:40 záznamu z 1. 12. 2021), což by mimochodem naprosto znemožnilo provozovat řešení v cloudu. Dalším problémem je, že ani po roce jednání se Stěžovatel nikam neposunul v této oblasti. Na jednání 17.10.2022 Stěžovatel nebyl schopný dát jasnou odpověď na náš dotaz, jak daleko jsou s tvorbou tenkého rozhraní (čas 1:28:40 záznamu).“

167.     K tomuto bodu návrhu Úřad konstatuje, že neshledal pochybení ze strany zadavatele, když v rámci zhodnocení řešení hodnotil stav vývoje jednotlivých technologických prvků systému (rozhraní API, přechod na tenké klienty, apod.) a dodává, že ze zápisu z jednání dne 17. 10. 2022 nevyplývá, že by zadavatel hodnotil informační systém z hlediska vývoje jako takový, tzn. nehodnotil, zda dodavatelé již pracují na vývoji informačního systému, který nabízejí jako řešení v rámci zadávacího řízení, ale hodnotil úroveň vývoje jednotlivých technologií a zkušenost dodavatelů (tedy i navrhovatele) s poptávanými technologiemi, resp. také vývoj prvků systému do budoucna. Nutno podotknout, že v rámci rozhodnutí o námitkách zadavatel neuvádí pouze nedostatečný vývoj řešení, ale také skutečnost, že navrhovatel v rámci jednání nebyl schopen specifikovat časový horizont, za který by byl schopen dosáhnout zadavatelem požadované úrovně vývoje řešení. Úřad tedy shledává naprosto legitimním a logickým, pokud zadavatel v rámci hodnocení vhodnosti řešení přihlédl k tomu, jaké má navrhovatel zkušenosti s vývojem určitých prvků systému, popř. když hodnotí časové aspekty vývoje, když logicky platí, že zadavatel potřebuje mít jistotu, že jeho potřeby budou plně uspokojeny a také, že budou uspokojeny v určitém časovém horizontu.

K odmítání řešení „na míru“

168.     Navrhovatel v návrhu namítá, že zadavatel neoprávněně odmítá řešení, jak označuje navrhovatel, „na míru“ či „na zakázku“. Podle navrhovatele však takové tvrzení zadavatele zpochybňuje oprávněnost užití ŘSSD[2] a argumentaci zadavatele považuje za diskriminační a nesmyslnou. Úřad k tomuto uvádí následující.

169.     Zadavatel v rámci rozhodnutí o vyloučení navrhovatele na straně 3 uvádí, že „…je Zadavatelem poptáván takový dodavatel, jehož systém je dlouhodobě aktivně rozvíjen bez ohledu na konkrétní poptávku, a jehož otevřenost je garantována všem zákazníkům.“ K této argumentaci navrhovatel dodává, že „neexistuje žádný univerzální důvod, pro který by všechny průběžně aktivně rozvíjené systémy měly být vhodnější než systém nějakou dobu již nerozvíjený.“

170.     Z dokumentace o zadávacím řízení, konkrétně z vyjádření zadavatele vyplývá, že důvodem pro tento požadavek byla budoucí potřeba zadavatele informační systém v budoucnu dále upravovat, a to vyvíjením vlastních funkcionalit systému ze strany zadavatele (např. jednání dne 17. 10. 2022, kde zadavatel uvádí: „Od začátku počítáme s tím, že systémy mají silnější a slabší strany pokrytí funkcionalit. Počítáme s tím, že některé systémy mít pokryté konkrétní funkcionality nebudou a že chybějící dovyvineme. Pak je otevřenost, jestli je zpřístupněná vývojem na míru [pozn. Úřadu dále v rámci jednání je používán promiscue pojem „na zakázku“ či „zakázkovým vývojem“] nebo automaticky. Na základě toho doimplementujeme naše řešení.“).

171.     Na základě audiozáznamů jednání v rámci soutěžního dialogu mezi zadavatelem a navrhovatelem, popř. zápisů z těchto jednání, Úřad zjistil, že v průběhu soutěžního dialogu došlo k rozporu mezi představami zadavatele a navrhovatele o architektonickém přístupu k informačnímu systému, kdy zadavatel pro svůj systém požaduje otevřené rozhraní API (na jednání dne 28. 6. 2022, kterého se zúčastnili M. B., M. H., A. K., K. K., L. M., J. M., J. N. a M. V. za zadavatele a Z. V., L. K. a M. Š. za navrhovatele [dále jen „jednání dne 28. 6. 2022“], uvedl zadavatel k otevřenosti API následující: „Je to o výkladu, co je otevřené API. Pracujeme s představou, že otevřené API má k dispozici kterýkoliv zákazník vašeho systému, všechno ostatní je zavřené API.“ [pozn. zvýrazněno Úřadem]). Oproti tomu navrhovatel má odlišnou představu, když např. na jednání dne 17. 10. 2022 uvedl na otázku zadavatele, zda chtějí „…pokračovat zakázkovým vývojem i včetně RESP API?“, přičemž k tomu zadavatel dodává: Já otevřenost vnímám tak, že pokud budu chtít řešení oddělit, tak mi API zůstane nezávisle na tom řešení. Když něco změníme, tak to přestane fungovat, což ale popírá otevřenost API. U otevřeného API vidíte, jaká je implementace za tím.“, odpovídá navrhovatel konstatováním: „Magion zpřístupní webové služby a vyrobí funkcionality zakázkovým přístupem [pozn. zvýrazněno Úřadem], ale v obou případech je potřeba nějaký čas a peníze.“

172.     Z výše uvedeného dle Úřadu vyplývá, že v rámci této otázky o určité koncepční věci ve vztahu k předmětu plnění došlo k protichůdným představám mezi zadavatelem a navrhovatelem. V souvislosti s tím, že ŘSSD je specifickým druhem zadávacího řízení, který je relativně flexibilnější, co se týče požadavků na předmět veřejné zakázky, a Úřad uznává určitou větší míru diskrece zadavatele vyjádřit své potřeby a na základě nich a na základě jednání s účastníky postupně specifikovat předmět veřejné zakázky, musí Úřad konstatovat, že v požadavku zadavatele na řešení, kdy upřednostňuje systém s otevřeným rozhraním API pro budoucí vlastní vývoj funkcionalit systému, namísto zakázkového vývoje funkcionalit dodavatelem, neshledal nezákonnost, naopak jej považuje za legitimní požadavek na předmět plnění.

173.     V této souvislosti Úřad doplňuje, že je to právě zadavatel, který zná nejlépe své vlastní potřeby a je schopen je nejpřesněji a věcně nejlépe definovat. Není tedy na jednotlivých dodavatelích, aby jakkoliv zasahovali do toho, jakým způsobem zadavatel promítl své potřeby do požadavků na předmět veřejné zakázky. Úřad tedy ve vztahu k danému požadavku zadavatele posoudil pouze, zda je odůvodněn potřebami zadavatele a zda není v rozporu se základními zásadami zadávání veřejných zakázek, resp. v rozporu se zásadou zákazu diskriminace, jak namítá navrhovatel. Jak vyplývá z předchozích bodů odůvodnění tohoto rozhodnutí, zadavatel odůvodnil daný požadavek svými potřebami, konkrétně potřebou mít v budoucnu možnost vytvářet v rámci informačního systému funkcionality, které vytvoří sám zadavatel, tedy bez potřeby požadovat vytvoření nových funkcionalit po dodavateli informačního systému. Úřad dále neshledal daný požadavek zadavatele ani rozporným se základními zásadami, resp. zásadou zákazu diskriminace, přičemž v tomto ohledu Úřad zdůrazňuje, že navrhovatel netvrdí, že by daný požadavek byl schopen na trhu splnit např. jen jeden dodavatel, či že ho není schopen splnit ani on sám. Navrhovatel v podstatě pouze tvrdí, že má zadavatel požadovat i řešení „na míru“, resp. že není oprávněn odmítat řešení „na míru“. S ohledem na obecnost námitky navrhovatele Úřad tedy tuto námitku vypořádal ve stejné míře obecnosti.

174.     V souvislosti s tímto bodem návrhu Úřad tedy neshledal porušení zákona a nepovažuje požadavek či následnou argumentaci zadavatele za diskriminační či nezákonnou.

K transparentnosti pojmu „otevřený systém“

175.     Dle navrhovatele zadavatel také netransparentně používá pojmu „otevřený systém“. Navrhovatel brojí proti skutečnosti, že byť je mu zadavatelem v rozhodnutí o vyloučení vytýkána nedostatečná otevřenost jeho řešení, zadavatel nepředložil žádnou definici, co má na mysli pod pojmem „otevřený systém.“ K tomuto uvádí Úřad následující.

176.     Již v zadávací dokumentaci zadavatel stanovil v bodě 2. specifikaci předmětu plnění, kdy požaduje otevřenost systému. Doslova zadavatel uvádí, že „[p]ředmětem veřejné zakázky je otevřený informační systém pro Masarykovu univerzitu, včetně modulů personalistika a mzdy a ekonomiky, tedy ekonomicko-personálního informačního systému s otevřeným API, které umožní zákaznický vývoj a rozvoj procesů a funkčnosti pro Masarykovu univerzitu,….“ [pozn. zvýrazněno Úřadem].

177.     Dále zadavatel v rámci přílohy č. 1 výzvy k účasti stanovil oblasti, kterým by dodavatelé měli věnovat podrobnější popis v rámci požadovaného arch. návrhu, kdy zadavatel zmiňuje otázku „Jak je řešena jeho [navrhovaného řešení] modularita a otevřenost s využitím API?“

178.     Z výše uvedeného dle Úřadu jasně vyplývá, že „otevřeným systémem“ zadavatel odkazoval na míru otevřenosti jeho API rozhraní.

179.     Uvedený závěr Úřadu potvrzují i informace vyplývající ze zápisů jednotlivých jednání. Např. ze zápisu z jednání dne 28. 6. 2022 vyplývá, že zadavatel uvedl k otevřenosti API následující: „Je to o výkladu, co je otevřené API. Pracujeme s představou, že otevřené API má k dispozici kterýkoliv zákazník vašeho systému, všechno ostatní je zavřené API.“ Další informaci ohledně požadavku na otevřený systém zadavatel poskytl např. na jednání dne 17. 10. 2022. Zástupce zadavatele na něm uvádí: „Já otevřenost vnímám tak, že pokud budu chtít řešení oddělit, tak mi API zůstane nezávisle na tom řešení.“

180.     V rámci jednání dne 17. 10. 2022 s pojmem „otevřený systém“ operoval i sám navrhovatel v rámci diskuse nad tímto bodem (Otevřenost systému) se zadavatelem, kdy představil své pojetí otevřenosti systému následovně: „My jsme to otočili naruby a řekli jsme si, že chcete otevřený systém a začali jsme si říkat definici, co je otevřený systém a jak jej můžeme nejvíce otevřít. Tak ať přistupují do databáze a děláte si „co chcete“, ale to samozřejmě nejde, ale z některých stran se tomu blížíme.“

181.     Dle výše zmíněného lze konstatovat, že pojem byl ze strany zadavatele vyložen v rámci zadávací dokumentace a následně byla otevřenost systému jako zadavatelem požadovaná vlastnost předmětu plnění diskutována v rámci soutěžního dialogu, kdy ze zápisů z jednání vyplývá, že oba účastníci řízení s pojmem operovali a měli příležitost prezentovat své představy o míře otevřenosti systému jako klíčové vlastnosti předmětu plnění. Pokud tedy byl navrhovatel schopen v rámci daných jednání s uvedeným pojmem operovat a dokonce diskutovat míru jeho otevřenosti, je Úřad toho názoru, že daný pojem musel navrhovatel bez problémů chápat.

182.     Navíc otevřenosti systému se navrhovatel věnuje i v rámci jím vypracovaného arch. návrhu, kdy se nejprve v rámci podkapitoly zabývá současným stavem otevřenosti systému EIS a dále v podkapitole 4.1 nastiňuje koncepci modularity EIS Magion a otevřenost s využitím API, z čehož lze taktéž dovodit, že navrhovatel pojem otevřený systém plně chápe. Nadto Úřad upozorňuje na to, že navrhovatel jako společnost dlouhodobě se zabývající vývojem informačních systémů a tedy jako profesionál musí být s to vyložit si tento klíčový pojem.

183.     Úřad tedy odmítá argumentaci navrhovatele jako nedůvodnou, když neshledal, že by zadavatel porušil zásadu transparentnosti, když v průběhu zadávacího řízení operoval s pojmem „otevřený systém“ ve vztahu předmětu plnění.

K jednotlivým důvodům vyloučení vztahujícím se k technickým aspektům navrhovatelova řešení

184.     Ve vztahu k přezkoumávanému úkonu v tomto správním řízení, tedy rozhodnutí o vyloučení navrhovatele, Úřad s odkazem na obecné závěry vztahující se k přezkumu řízení se soutěžním dialogem uvedené v bodech 142. až 148. odůvodnění tohoto rozhodnutí konstatuje, že je dle jeho názoru oprávněn přezkoumat, zda byly dodrženy základní zásady stanovené zákonem, předně zásada transparentnosti, přiměřenosti, zákazu diskriminace a rovného zacházení. V tomto ohledu považuje Úřad za nutné přezkoumat, zda je napadený úkon zadavatele řádně odůvodněný, přezkoumatelný a zda jsou jednotlivé důvody vyloučení v souladu s deklarovanými potřebami zadavatele a zda byly technické aspekty řešení navrhovatele projednány v rámci soutěžního dialogu, tedy v rámci jednání, která se mezi navrhovatelem a zadavatelem uskutečnila.

185.     Úřad se necítí být v rámci přezkumu úkonů zadavatele v rámci ŘSSD oprávněn zkoumat jednotlivé potřeby zadavatele, které jsou promítnuty do představ zadavatele o technických náležitostech v rámci ŘSSD hledaného řešení. Nicméně dle Úřadu je nutné ověřit, zda byly potřeby zadavatele z jeho strany vůči navrhovateli deklarovány předem, popř. v průběhu soutěžního dialogu a zda jsou tyto potřeby promítnuty i v rozhodnutí o vyloučení v tom smyslu, že důvody pro vyloučení, předně v části, kdy zadavatel hodnotí jednotlivé technické parametry a technická řešení nabízeného řešení navrhovatele, jsou odrazem nemožnosti naplnění potřeb zadavatele, resp. zda některý z důvodů vyloučení není zjevný exces, kdy zadavatel vylučuje z důvodu, který nemá opodstatnění v deklarovaných potřebách zadavatele a v průběhu soutěžního dialogu.

186.     Z audionahrávek a zápisů z průběhu soutěžního dialogu mezi navrhovatelem a zadavatelem Úřad ověřil, že důvody vyloučení týkající se rozhraní API, tedy rozsáhlosti, zpřístupnění a možnosti využití API pro vývoj řešení pro třetí strany (důvody vyloučení 1, 2 a 3 na straně 3 rozhodnutí o vyloučení) mají základ jednak v potřebě zadavatele, aby nalezené řešení bylo otevřeným informačním systémem, jehož otevřenost jako základní vlastnost je zadavatelem vnímána rozsáhlostí otevřenosti rozhraní API (viz body 175. až 183. odůvodnění tohoto rozhodnutí) a zároveň v potřebě zadavatele mít obecně zpřístupněné API i pro všechny další zákazníky, nikoliv rozhraní API vyvinuté dodavatelem pouze pro zadavatele. Ke koncepci rozhraní API v rámci řešení na veřejnou zakázku byla vedena diskuse např. na jednáních dne 28. 6. 2022 nebo 17. 10. 2022. Úřad tímto odkazuje na předchozí právní posouzení v bodech 165. až 167. odůvodnění tohoto rozhodnutí.

187.     K požadavkům na rozhraní API Úřad konstatuje, že se jedná o legitimní požadavky zadavatele, které odráží potřebu zadavatele mít informační systém, v rámci kterého bude zadavatel moci vyvíjet vlastními silami další funkcionality, a ty dále poskytovat jiným subjektům, jak vyplývá z jednání dne 17. 10. 2022, kde zadavatel uvádí: „Od začátku počítáme s tím, že systémy mají silnější a slabší strany pokrytí funkcionalit. Počítáme s tím, že některé systémy mít pokryté konkrétní funkcionality nebudou a že chybějící dovyvineme. Pak je otevřenost, jestli je zpřístupněná vývojem na míru, nebo automaticky. Na základě toho doimplementujeme naše řešení.“ Potřeba otevřeného systému také byla ještě před soutěžním dialogem vyjádřena v rámci zadávací dokumentace v bodě 2., kdy zadavatel charakterizuje předmět veřejné zakázky, přičemž požaduje systém s otevřeným rozhraním API.

188.     V průběhu soutěžního dialogu vyplynulo, že navrhovatelem nabízené řešení nenaplňuje potřebu otevřenosti do takové míry, jakou zadavatel očekává, když navrhovatel počítá s rozhraním API vyvinutým přímo pro zadavatele, tedy takové které není přístupné ostatním zákazníkům, což navrhovatel tvrdil např. na jednání dne 17. 10. 2022, kdy k celkové otevřenosti systému uvedl: „My jsme to otočili naruby a řekli jsme si, že chcete otevřený systém a začali jsme si říkat definici, co je otevřený systém a jak jej můžeme nejvíce otevřít. Tak ať přistupují do databáze a děláte si „co chcete“, ale to samozřejmě nejde, ale z některých stran se tomu blížíme.“ K otevřenosti rozhraní API navrhovatel dále na jednání uvedl: „Nemáme takové REST API a webové služby, které by pokrývaly celý systém. Necháme vám služby, které již máte a uděláme rozhraní na všechny úlohy, které v systému jsou a u kterých to má smysl. Do jádra systému není možný přístup. Přidali bychom další metody validace.“

189.     K důvodům vyloučení týkajícím se rozhraní API tedy Úřad na základě výše uvedeného uvádí, že se vztahují k jasně stanoveným potřebám zadavatele, a to jak v zadávací dokumentaci, tak i v rámci jednotlivých jednání, a zároveň z daných jednání mezi zadavatelem a navrhovatelem vyplynulo, že navrhovatelovo řešení dané potřeby zadavatele nenaplňuje do míry požadované zadavatelem.

190.     Dalším důvodem vyloučení navrhovatele je pro zadavatele, že řešení navrhovatele využívá tzv. tlusté klienty a provozuje desktopové řešení založené na technologickém prostředí PowerBuilder. Dále zadavateli nevyhovuje, že navrhovatel nepočítá s vývojem klientů pro mobilní zařízení. Zadavatel na jednání dne 17. 10. 2022 tyto potřeby uvedl, když na jednání prezentoval svůj záměr „postupně se zbavovat tlustého řešení,“ v tomto smyslu dále na tomto jednání zadavatel např. uvedl: „Nechci, aby se vůbec pracovalo v desk top klientovi. Práce z pracoviště z desktopového klienta jsou 90. léta. Covid nás naučil, že to je jeden z problémů. Rád bych, aby budoucí rozhraní bylo jen webové. Může být povolené dávkové zpracování, ale potřebuji, aby lidé mohli pracovat z celého světa.“ Na jednání dále zadavatel uvedl, že „…požaduje podporu více typů zařízení.“

191.     Navrhovatel na jednání dne 1. 12. 2021, kterého se zúčastnili M. B., M. J., A. K., Z. M., J. M., J. N. a M. V. za zadavatele a Z. V., D. Z., R. F., M. G. a P. Ž. za navrhovatele, tvrdil, že vyvíjí kopie „toho samého“ na webu. Zároveň na dotaz zadavatele, kam směřuje vývoj, tvrdí, že pořád směřují vývoj v prostředí PowerBuilderu, že se postupně „na web“ dostanou (audiozáznam jednání od času 21:00). Následně pak na jednání dne 17. 10. 2022 uvádí, že vývoj migrace na tenké klienty v rámci PowerBuilderu zatím nedokončil a současně nenasadil ani u jiných zákazníků (audiozáznam jednání od času 1:28). Informaci o vývoji rozhraní pro mobilní zařízení Úřad nenašel ani v rámci arch. návrhu navrhovatele, ani v rámci zápisů ze soutěžního dialogu. To, že navrhovatel o vývoji řešení také pro mobilní zařízení v rámci soutěžního dialogu nehovořil, tvrdí v rozhodnutí o námitkách také zadavatel, což navrhovatel ve svém návrhu nerozporuje. Úřad tedy konstatuje, že ze strany navrhovatele vůči zadavateli nevzešla jednoznačná informace o vývoji funkcionalit systému na webové služby, ani nebyl zadavateli poskytnut časový odhad tohoto vývoje a přechodu z tzv. tlustých klientů na klienty tenké.

192.     K důvodům vyloučení týkajícím se využívání tzv. tlustých klientů a provozování desktopového řešení založeného na technologickém prostředí PowerBuilder tak Úřad ve světle výše uvedeného uvádí, že se vztahují k jasně stanoveným potřebám zadavatele, a to v rámci jednotlivých jednání mezi zadavatelem a navrhovatelem, přičemž z daných jednání také vyplynulo, že ani v tomto případě navrhovatelovo řešení dané potřeby zadavatele nenaplňuje do míry požadované zadavatelem.

193.     Dalším důvodem vyloučení je, že řešení navrhovatele neposkytuje takové cloudové řešení, jaké by si zadavatel představoval. Navrhovatel k otázce datového řešení systému ve svém arch. návrhu na straně 120 uvádí, že „IS Magion umožňuje kombinace případně jakoukoli z variant provozování aplikací, a to jak on premise, tak v cloudu. Konkrétní varianta vždy vychází z reálných potřeb zákazníka s ohledem na bezpečnost, rychlost a vlastní IT infrastrukturu zákazníka.“ Zadavatel na jednání s navrhovatelem dne 17. 10. 2022, jak vyplývá ze zápisu z tohoto jednání, sdělil svou potřebu ohledně cloudového řešení informačního systému. Zadavatel sdělil, že „[z]áměr MU je provozovat řešení v public cloudu,“ dále sdělil, že požaduje zkušenost dodavatele s provozováním řešení v cloudu, certifikaci datacentra (TIER I – IV). V rámci jednání zazněla ze strany zadavatele otázka: „…jak vy byste provozovali a jestli jste vůbec schopni provozovat a za jakých podmínek? A zda máte zkušenost.“ Navrhovatel následně zadavateli odpověděl: „Certifikace data centra nemáme, nemáme data centrum.“ V rámci jednání navrhovatel dále uvedl, že má zkušenost s cloudovým řešením, kdy zmiňuje cloudová řešení pro Akademii věd ČR s využitím cloudové platformy Microsoft Azure a na otázku cloudového řešení předkládaného řešení navrhovatele dále uvádí, že „[t]o znamená, že budeme muset jednat s Microsoftem o podmínkách využití Azuru a serveru. Byli jsme zvyklí na menší databáze.“

194.     Úřad konstatuje, že ze soutěžního dialogu vyplynulo, že navrhovatel není schopen nabídnout vlastní cloudové řešení, jelikož nedisponuje vlastním datovým centrem. V rámci dialogu zmiňuje zkušenost s poskytnutím cloudu jinému zákazníkovi, avšak prostřednictvím cloudové služby třetí strany, konkrétně platformy Microsoft Azure. Z rozhodnutí o vyloučení vyplývá, že zadavatel shledává zkušenost navrhovatele s provozováním svého řešení v cloudu za nedostatečnou. Dle zadavatele tak je nerealistické, že by navrhovatel bez zmíněných praktických zkušeností byl schopen provozovat cloudové řešení, které by odpovídalo jiným řešením, která jsou nativně vyvíjena a provozována v cloudu, např. v podobě SaaS [pozn. Software as a Service].

195.     Úřad tak k danému důvodu vyloučení s ohledem na výše uvedené uvádí, že se vztahuje k potřebám zadavatele, které byly vyjádřeny zadavatelem v rámci jednání mezi zadavatelem a navrhovatelem, přičemž z daných jednání vyplynulo, že navrhovatel doposud provozoval řešení pouze prostřednictvím cloudové platformy třetí strany a nedisponuje vlastním datovým centrem, což je v rozporu se zadavatelovými potřebami.

196.     Dále byl navrhovatel vyloučen kvůli tomu, že jeho řešení nedisponovalo integrační platformou ESB. K tomu Úřad uvádí, že již ze zadávací dokumentace, a to z bodu 3.2. vyplývá, že navržený způsob integrace s externími systémy je předpokládaným kritériem pro hodnocení nabídek v další fázi ŘSSD, tudíž Úřad uznává, že do hodnocení vhodnosti či nevhodnosti řešení bylo legitimní zahrnout i integrační platformu navrhovatelova řešení. K tomu Úřad dodává, že byť bylo toto hodnotící kritérium stanoveno v rámci zadávací dokumentace jako kritérium pro hodnocení nabídek, je podle Úřadu pochopitelné, že pokud platí, že nabídka logicky vychází z řešení nalezeného v průběhu soutěžního dialogu, může být hodnotící kritérium pro nabídku taktéž kritériem pro hodnocení vhodnosti nalezeného řešení. Současně Úřad dodává, že ani navrhovatel ve svém návrhu nerozporuje, že jeho řešení nedisponuje touto integrační platformou. Úřad tedy i k tomuto bodu vyloučení navrhovatele uvádí, že se vztahuje k předem definované potřebě zadavatele, a to v rámci zadávací dokumentace, a zároveň z dokumentace o zadávacím řízení nevyplývá, že by navrhovatel tento bod vyloučení jakkoli rozporoval, resp. že by tvrdil, že jeho řešení integrační platformou ESB disponuje. Současně není Úřad přesvědčen o tom, že by byl důvod, který byl navrhovateli sdělen v rámci rozhodnutí o námitkách, tedy že je pro zadavatele nevyhovující navrhovatelova okrajová zkušenost s implementací platformy, je „zcela mimo strukturu soutěžního dialogu“, vadný v tom smyslu, že by snad tímto zadavatel vracel zadávací řízení do fáze posouzení technické kvalifikace. V rámci rozhodnutí o námitkách zadavatel toto tvrzení zakládá na proběhlých jednáních v rámci soutěžního dialogu, ze kterých vyplynulo, že navrhovatel v současné době nedisponuje integrační platformou (zadavatel se odkazuje na jednání dne 17. 10. 2022 a na audiozáznam z tohoto jednání od času 1:00:30). Úřad v tomto ohledu neshledává jako odporující zákonu takové posouzení řešení v průběhu soutěžního dialogu, kdy zadavatel legitimně bere v úvahu současný stav zadavatele vzhledem k této konkrétní technologii, a to zjevně v souladu s potřebou propojit interní a externí systémy zadavatele, jak v rámci rozhodnutí o námitkách zadavatel uvádí.

197.     K dalšímu důvodu vyloučení, tj. absenci specifických funkcí pro automatizaci digitalizace a individualizace agend samotnými uživateli v řešení navrhovatele, Úřad konstatuje, že tuto potřebu zadavatel předem vyjádřil v bodě 1.5 zadávací dokumentace, když stanovil, že IT ekosystém bude obsahovat „oddělení rozhraní a implementace funkčností/služeb umožní flexibilitu v implementaci procesů, které jsou ušité na míru individualizovaných agend a skládají se z funkčností napříč celou integrační platformou.“ Stejně tak lze na stejném místě najít deklarovanou potřebu digitalizace v novém IT ekosystému, kdy zadavatel stanovil, že „[c]ílem MU v rámci současného strategického rámce je vybudovat IT ekosystém nové generace s otevřenou architekturou (integrační platformu INET 2.0), který ulehčí a urychlí digitalizaci ekonomických a personálních agend. Současně umožní větší míru vlastnictví a kontroly nad vyvíjenými agendami.“ Požadavek na automatizaci procesů byl také předmětem jednání dne 17. 10. 2022, kdy zadavatel sdělil své požadavky v oblasti automatizace procesů, kdy uvedl, že „podpora automatizace je pro MU důležitá, chce být lídrem v této oblasti,“.Jako další požadavky zadavatel uvedl potřebu „vytvářet aplikace uživatelům bez nutnosti programování“, podporu automatizace rutinních úkolů screenscapingu a podporu automatizačních procesů. Jak Úřad zjistil z dokumentace o zadávacím řízení, navrhovatel řešení těchto požadavků v rámci svého arch. návrhu nijak nezohlednil a v rámci soutěžního dialogu k těmto požadavkům pouze zmínil, že se zástupci navrhovatele setkali s automatem na České zemědělské univerzitě, který používal produkt Power Automate Microsoft a ze strany České zemědělské univerzity následně došlo k integraci tohoto produktu na informační systém navrhovatele. Úřad tedy uvádí, že hodnocení zadavatele v rámci rozhodnutí o vyloučení, kdy konstatoval, že „[ř]ešení Magionu nenabízí ani další specifické funkce pro automatizaci digitalizace a individualizaci agend samotnými uživatel,“ se zakládá na realitě, když tyto funkce nejsou obsaženy v arch. návrhu navrhovatele a v rámci soutěžního dialogu navrhovatel pouze zmínil produkt třetí strany, který však neintegroval do svého systému u jiného zákazníka navrhovatel, nýbrž tato instituce. Úřad s ohledem na uvedené shledává i ve vztahu k tomuto důvodu vyloučení, že ze strany zadavatele byla v zadávací dokumentaci předem deklarována potřeba automatizace procesů, což bylo upřesněno i v rámci soutěžního dialogu, a navrhovatel v rámci svého řešení neposkytl takové technické řešení, které by tuto potřebu naplnilo.

198.     Úřad konstatuje, že důvody vyloučení navrhovatele neshledává v rozporu s potřebami zadavatele, které před či v rámci soutěžního dialogu deklaroval. V této souvislosti Úřad taktéž nedošel k závěru, že by rozhodnutí o vyloučení odporovalo základním zásadám obsaženým v § 6 zákona, kdy má za to, že rozhodnutí je odůvodněné a přezkoumatelné, a tudíž transparentní, a zároveň rozhodnutí o vyloučení nemá dle Úřadu diskriminační charakter.

K namítanému nevypořádání námitky zadavatelem

199.     Vzhledem ke skutečnosti, že navrhovatel v rámci návrhu brojí též proti rozhodnutí o námitkách, přistoupil Úřad také k posouzení, zda je rozhodnutí o námitkách v částech napadených navrhovatelem učiněno v souladu se zákonem, tj. v souladu s § 245 odst. 1 zákona.

200.     Konkrétně navrhovatel namítá nevypořádání námitky hrozícího porušení pravidel hospodářské soutěže. V bodě 2.40 námitek k bodu vyloučení č. 3 navrhovatel uvádí, že „[c]o je zde však potřeba zdůraznit daleko více, je, že tzv. doplňková činnost MU jako veřejné vysoké školy má své zákonné limity, zejména musí navazovat na její vzdělávací a tvůrčí činnost nebo činnost sloužící k účinnějšímu využití lidských zdrojů a majetku. Je potřeba mít na paměti i to, že doplňková činnost nesmí ohrozit kvalitu, rozsah a dostupnost činností, k jejichž uskutečňování byla veřejná vysoká škola zřízena. Jelikož je na tuto doplňkovou činnost využíváno veřejných financí, je potom otázkou, zda finance MU, které ÚVT hodlá investovat na to, aby mohl realizovat komerční aktivity vůči dalším VVŠ, tj. vyvinout komerční produkt konkurující produktům jiných tržních subjektů, jsou využity v souladu s vysokoškolským zákonem, zásadou 3E a zda by nebylo jejich využití vhodnější na to, co je hlavní činností MU. Pakliže navíc používá ÚVT veřejných prostředků na to, aby v nějakém ohledu konkuroval výrobcům a dodavatelům ekonomických informačních systémů, pak takový postup Ústavu může v krajním případě i naplnit aspekty nekalé soutěže a porušovat pravidla hospodářské soutěže“ [pozn. zvýrazněno Úřadem]. Tento argument navrhovatel uzavírá s tím, že důvod vyloučení je nejen v rozporu s reálným průběhem jednání a nepravdivý, ale je zde pravděpodobnost, že porušuje i další právní předpisy, kdy navrhovatel zmiňuje „předpisy na ochranu hospodářské soutěže a vysokoškolský zákon.“ 

201.     Rozpor s „dalšími předpisy zakazujícími porušování hospodářské soutěže“ namítá navrhovatel také v bodě 2.57 námitek k důvodu vyloučení č. 6, tedy že navrhovatel nenabízí integrační platformu ESB, kdy zadavatel uvádí, že neexistence této platformy by též omezila možnosti prodeje zadavatelem vyvinutého řešení a jeho integrace do IT prostředí jiných veřejných vysokých škol.

202.     Úřad zdůrazňuje, že v rámci námitek navrhovatel nijak konkrétně nespecifikoval, jakým způsobem by mělo k porušení předpisů na ochranu hospodářské soutěže dojít, resp. k porušení jakých ustanovení daných předpisů mělo dojít. Kromě obecné formulace, že „[d]ůvod vyloučení je tak, rovněž v rozporu s dalšími právními předpisy zakazujícími porušování hospodářské soutěže,“ obsahuje bod 2.56 námitek formulaci, podle které „[d]ůraz, který ÚVT [zadavatel] klade na integrační platformu a její využití pro komercionalizaci poptávaného řešení, vyvolává určité pochybnosti o samotné oprávněnosti tohoto požadavku zadavatele. Pokud totiž je důvodem vyloučení řešení stěžovatele obava Ústavu o to, zda by na platformě stěžovatele byl schopen postavit konkurenceschopné a „prodatelné“ řešení, musí stěžovatel opakovaně zdůraznit, že důvodem vyloučení jakéhokoli dodavatele nemůže být obava z jeho konkurenčního vztahu k Ústavu. Rovněž platí, že veřejná zakázka a veřejné finance z principu nemohou být zneužívány k přípravě komerční aktivity Ústavu jako zadavatele, tedy k přípravě komerčního produktu.“

203.     K důvodu vyloučení č. 3, resp. bodům 2.41 a 2.42 námitek se zadavatel vyjádřil v rámci svého rozhodnutí o námitkách na straně 10, kdy uvedl, že „neshledal porušení jakýchkoliv právních předpisů. Zadavatel poukazuje na skutečnost, že tuzemské VVŠ běžně provozují obdobné činnosti. Zadavatel tak například činí dlouhodobě v oblasti studijní, kdy systém původně vyvinutý pro jeho potřeby nabízí ostatním VŠ v ČR, a stejně tak činí i některé jiné VŠ. Výsledkem je vysoce konkurenční prostředí.“ Ve stejném duchu svou argumentaci k daným bodům námitek uzavírá konstatováním v závěru této části rozhodnutí o námitkách, kdy dodává, že rozpor s předpisy na ochranu hospodářské soutěže či zákonem o vysokých školách je nepravdivý a irelevantní.

204.     K námitce k důvodu vyloučení č. 6 se vyjadřuje zadavatel v rozhodnutí o námitkách na straně 15, kdy opětovně konstatuje, že „trvá na důvodu vyloučení č. 6 a uvádí, že tento je plně v souladu s platnou legislativou.“

205.     S ohledem na výše uvedené Úřad k šetřenému shrnuje, že z rozhodnutí o námitkách je zřejmé, proč zadavatel považuje argumenty navrhovatele ohledně údajného hrozícího porušení pravidel hospodářské soutěže za liché. Úřad uznává, že odůvodnění této části námitek je relativně stručné, ovšem to je dle Úřadu dáno především tím, jak obecně byly ze strany navrhovatele námitky formulovány, když navrhovatel namítal pouze v obecné rovině, že postup zadavatele může v krajním případě naplnit aspekty nekalé soutěže a porušovat pravidla hospodářské soutěže, resp.že důvod vyloučení je tak rovněž v rozporu s dalšími právními předpisy zakazujícími porušování hospodářské soutěže, aniž by uvedl konkrétní rozhodné skutečnosti, které by zakládaly taková porušení, resp. navrhovatel neuvedl ani konkrétní ustanovení citovaných zákonů, jejichž porušení ze strany zadavatele by hrozilo. Úřad tak považuje dané pasáže odůvodnění rozhodnutí o námitkách s ohledem na specifika namítané skutečnosti za podrobné a srozumitelné.

206.     S ohledem na výše uvedené Úřad konstatuje, že odůvodnění námitek ve vztahu k bodům 2.41, 2.42, 2.56 a 2.57 námitek lze považovat za podrobné a srozumitelné, tedy nelze konstatovat, že by odůvodnění daných námitek bylo nepřezkoumatelné, nesrozumitelné či nedostatečně odůvodněné. Úřad tedy neshledal porušení § 245 odst. 1 zákona ze strany zadavatele.

K vyjádření k podkladům rozhodnutí

207.     Na tomto místě Úřad považuje za nutné vyjádřit se k argumentům obsaženým ve vyjádření navrhovatele k podkladům rozhodnutí. V tomto ohledu uvádí Úřad následující.

208.     K výhradě navrhovatele, že zadavatel nedodržel obvyklý postup řízení se soutěžním dialogem, když některé části zejména jednací části nebyly zachyceny v papírové formě, Úřad konstatuje, že, jak již bylo uvedeno výše, soutěžní dialog jako jednací část řízení se soutěžním dialogem nemá zákonem stanovenou formu a jednotnou zákonem předepsanou strukturu a způsob vedení je v tomto ohledu v diskreci zadavatele. Pro úplnost Úřad uvádí, že se jedná o tvrzení, které nebylo obsaženo v návrhu ani v námitkách navrhovatele, a přitom Úřad nemá za to, že by se jednalo o nové skutečnosti, které by navrhovatel nemohl tvrdit již vůči zadavateli v rámci námitek, tudíž dle § 251 odst. 4 zákona k takovým skutečnostem Úřad nepřihlíží. K tvrzení navrhovatele, že k vyloučení došlo poté, co byl zadavatelem vyzván k předložení ceny jeho plnění, a k následné konstrukci navrhovatele o tom, že zadavatel navrhovatele vyloučil kvůli „bezkonkurenční“ ceně plnění, Úřad uvádí, že se jedná ze strany navrhovatele o pouhé spekulace, jelikož daná tvrzení nedokládá žádnými důkazy a zároveň tato tvrzení navrhovatele nemají ani žádnou oporu v dokumentaci o zadávacím řízení. Úřad k tomuto doplňuje, že se i v tomto případě jedná o tvrzení, která nebyla obsažena v návrhu či námitkách navrhovatele, a přitom Úřad nemá za to, že by se jednalo o nové skutečnosti, které by navrhovatel nemohl tvrdit již vůči zadavateli v rámci námitek, tudíž dle § 251 odst. 4 zákona k takovým skutečnostem Úřad nepřihlíží.

209.     Pokud se jedná o navrhovatelova tvrzení ohledně skutečností, které pro navrhovatele vyplývají z dokumentů, které měl navrhovatel k dispozici v rámci vzdáleného přístupu ke spisu, Úřad konstatuje, že s ohledem na to, že se navrhovatel odkazuje na názvy položek spisu, které nejsou podkladem pro rozhodnutí, a současně navrhovatel do těchto dokumentů nenahlížel (pouze odkazuje na jejich názvy v rámci dokumentu s názvem „Obsah spisu“), a také s ohledem na to, že skutečnosti, které navrhovatel dovozuje z pouhých názvů daných položek spisu, nejsou předmětem tohoto řízení, odmítá Úřad daná tvrzení navrhovatele jako bezpředmětná. Pro úplnost Úřad uvádí, že dokumentace o zadávacím řízení obsahuje Rozhodnutí o schválení předloženého řešení elektronicky podepsané dne 30. 12. 2022, kterým zadavatel rozhodl, že řešení předložené účastníkem [anonymizováno] je vhodné. Dané rozhodnutí je elektronicky podepsáno ve stejný den jako rozhodnutí o schválení předložených řešení zbylých dvou účastníků zadávacího řízení a ve stejný den bylo elektronicky podepsáno i rozhodnutí o vyloučení navrhovatele. Není tedy pravdou, že by zadavatel stále jednal o vhodnosti řešení předloženého účastníkem [anonymizováno], jak tvrdí navrhovatel, a ze skutečností vyplývajících z dokumentace o zadávacím řízení zároveň vyplývá, že Úřadu není znám žádný důvod se domnívat, že by se všemi účastníky zadávacího řízení při posuzování vhodnosti předložených řešení nemělo být zacházeno stejně. K dalšímu tvrzení navrhovatele, že v podkladech pro rozhodnutí nenalezl rozhodnutí zadavatele o vhodnosti či nevhodnosti řešení navrhovatele, z čehož dovozuje porušení § 69 odst. 5 zákona, jelikož dle jeho názoru vyloučení navrhovatele mělo předcházet rozhodnutí o nevhodnosti řešení navrhovatele, Úřad uvádí, že z jazykového výkladu § 69 odst. 5 zákona jasně vyplývá, že účastníka, jehož řešení není vhodné, musí zadavatel ze zadávacího řízení vyloučit, přičemž o povinnosti zadavatele ještě před vyloučením rozhodnout o nevhodnosti řešení zákon nikde nehovoří. Lze tedy dovodit, že rozhodnutí o vyloučení lze chápat zároveň jako rozhodnutí o nevhodnosti řešení.

210.     V případě ostatních tvrzení obsažených ve vyjádření navrhovatele k podkladům rozhodnutí má Úřad za to, že nebyly prezentovány nové skutečnosti a tvrzení, které by již nezazněly v rámci návrhu či vyjádření navrhovatele v průběhu správního řízení. Z toho důvodu se Úřad za účelem vypořádání těchto ostatních bodů odkazuje na výše uvedené právní posouzení.

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

Poučení

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

otisk úředního razítka

 

 

 

Mgr. Markéta Dlouhá

místopředsedkyně

 

Obdrží

Masarykova univerzita, IČO 00216224, se dílem Žerotínovo náměstí 617/9, 602 00 Brno

Mgr. Marek Šimka, advokát, Šumavská 519/35, 602 00 Brno

 

Vypraveno dne

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