číslo jednací: 26818/2023/162
spisová značka: R0060/2023/VZ

Spisová značka:  ÚOHS-R0060/2023/VZ Číslo jednací:      ÚOHS-26818/2023/162

Brno 20. 7. 2023

 

Ve správním řízení o rozkladu ze dne 9. 5. 2023 doručeném Úřadu pro ochranu hospodářské soutěže téhož dne navrhovatelem –

• 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 Moravské náměstí 754/13, 60200 Brno,

proti rozhodnutí Úřadu pro ochranu hospodářské soutěže č. j. ÚOHS-15367/2023/500 ze dne 24. 4. 2023, vydanému ve správním řízení vedeném pod sp. zn. ÚOHS-S0105/2023/VZ ve věci přezkoumání úkonů zadavatele –

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

učiněných 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,

 

jsem podle § 152 odst. 6 písm. b) ve spojení s § 90 odst. 5 zákona č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů na základě návrhu rozkladové komise, jmenované podle § 152 odst. 3 téhož zákona, rozhodl takto:

 

Rozhodnutí Úřadu pro ochranu hospodářské soutěže sp. zn. ÚOHS-S0105/2023/VZ, č. j. ÚOHS-15367/2023/500 ze dne 24. 4. 2023,

 

p o t v r z u j i

 

a podaný rozklad

 

z a m í t á m.

 

Odůvodnění

I.               Zadávací řízení a správní řízení vedené Úřadem pro ochranu hospodářské soutěže

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ávací řízení se soutěžním dialogem (dále jen „ŘSSD“), 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 opravy k uveřejnění (dále jen „zadávací řízení“ či „veřejná zakázka“).

2.             V rámci zadávacího řízení obdržel zadavatel žádost o účast mimo jiné od 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 Moravské náměstí 754/13, 602 00 Brno (dále jen „navrhovatel“).

3.             Zadavatel dne 30. 12. 2022 odeslal rozhodnutí o vyloučení navrhovatele z účasti v zadávacím řízení z téhož dne (dále jen „rozhodnutí o vyloučení“). Proti tomuto rozhodnutí podal navrhovatel dne 16. 1. 2023 námitky a současně proti volbě druhu zadávacího řízení z téhož dne (dále jen „námitky“).

4.             Následně 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.

5.             Vzhledem k tomu, že navrhovatel nesouhlasil s vypořádáním svých námitek, podal dne 10. 2. 2023 k Úřadu pro ochranu hospodářské soutěže jakožto orgánu příslušnému podle § 248 zákona k výkonu dozoru nad dodržováním pravidel stanovených zákonem (dále jen „Úřad“) návrh z téhož dne.

6.             Podle § 249 zákona ve spojení s § 44 odst. 1 zákona č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů (dále jen „správní řád“) bylo zahájeno správní řízení o přezkoumání úkonů zadavatele dnem 10. 2. 2023, kdy Úřad obdržel prostřednictvím datové schránky dva návrhy. První návrh směřoval proti rozhodnutí o vyloučení a je předmětem správního řízení, které Úřad vede pod sp. zn. ÚOHS-S0105/2023/VZ a v němž je rozhodnuto nyní napadeným 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 sp. zn. ÚOHS-S0106/2023/VZ (dále také jako „návrh č. 2“).

7.             Navrhovatel v návrhu nesouhlasil s formulací důvodů pro svoje vyloučení, neboť má za to, že zadavatel vycházel z nepravdivých a neoprávněných úvah a východisek, v důsledku čehož dochází i k nesprávným závěrům.

8.             Navrhovatel v návrhu tvrdil, že z jeho strany nebylo předloženo žádné ucelené řešení v rámci ŘSSD a ani nebyl k tomu zadavatelem vyzván. Nedošlo tedy k finální specifikaci předloženého řešení. Dle navrhovatele zadavatel nesprávně aplikoval § 69 odst. 5 zákona, neboť dle předmětného ustanovení je zadavatel povinen vyzvat k podání konečných nabídek či řešení každého účastníka, což zadavatel neučinil. V podrobnostech lze odkázat na obsah návrhu uvedený v bodech 7–17 odůvodnění sp. zn. ÚOHS-S0105/2023/VZ, č. j. ÚOHS-15367/2023/500 (dále jen „napadené rozhodnutí“).

II.             Napadené rozhodnutí

9.             Dne 24. 4. 2023 vydal Úřad napadeného rozhodnutí, kterým návrh navrhovatele zamítl, neboť nebyly zjištěny důvody pro uložení nápravného opatření.

10.         Úřad se v úvodu odůvodnění napadeného rozhodnutí obecně vyjádřil k ŘSSD a současně uvedl, jak přistupovat k přezkumu vyloučení dodavatele v rámci ŘSSD, které je zadávacím řízením specifické povahy (viz body 142–148 odůvodnění napadeného rozhodnutí). Úřad zde konstatoval, že cílem jednací fáze ŘSSD je nalézt pro zadavatele vhodná řešení, která budou odpovídat potřebám zadavatele 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. Dle Úřadu je správný postup, pokud je ještě před podáním nabídky vyloučen ze zadávacího řízení takový účastník, který předložil nevhodné řešení. Ovšem důvody nevhodnosti řešení je třeba uvést v rámci odůvodnění vyloučení účastníka zadávacího řízení. Úřad vycházel mj. z metodiky Ministerstva pro místní rozvoj. Následně Úřad posoudil jednotlivé body návrhu, přičemž po posouzení všech argumentů navrhovatele nezjistil důvody pro uložení nápravného opatření.  Úřad neshledal důvody vyloučení navrhovatele 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. Dle Úřadu je rozhodnutí odůvodněné a přezkoumatelné, tudíž transparentní, a zároveň rozhodnutí o vyloučení nemá diskriminační charakter. Podrobně k posouzení jednotlivých okruhů námitek navrhovatele ze strany Úřadu lze odkázat na body 150–210 odůvodnění napadeného rozhodnutí.

III.           Rozklad navrhovatele

11.         Dne 9. 5. 2023 podal navrhovatel Úřadu blanketní rozklad z téhož dne proti napadenému rozhodnutí, který následně doplnil dne 18. 5. 2023. Ze správního spisu vyplývá, že napadené rozhodnutí bylo zástupci navrhovatele doručeno dne 24. 4. 2023. Rozklad byl podán v zákonné lhůtě.

Námitky rozkladu

12.         Navrhovatel rozklad rozdělil do 6 argumentačních okruhů, které dále v rozkladu podrobně rozebírá.

13.         Navrhovatel prvně v úvodní části rozkladu namítá své předčasné vyloučení z ŘSSD ze strany zadavatele, neboť ten od navrhovatele neobdržel žádné finální řešení, a nemohl tedy posuzovat soulad řešení navrhovatele se svými potřebami. Podle názoru navrhovatele Úřad nesprávně posoudil skutkový stav, pouze aplikoval obecná tvrzení, přičemž opomněl zohlednit podstatné skutkové okolnosti. Taktéž se podle navrhovatele Úřad nesprávně vypořádal s netransparentností vedení celého ŘSSD. Zadavatel totiž fakticky nikdy nezformuloval své ucelené požadavky poté, co se seznámil s úvodními architektonickými návrhy dodavatelů, nemohl tedy obdržet ani řešení, jejichž vhodnost by následně mohl posuzovat.

14.         Navrhovatel má za to, že zadavatel namísto budoucího řešení předloženého navrhovatelem nezákonně hodnotí stávající systém. I zde podle navrhovatele Úřad založil své závěry na nesprávném posouzení, na formalistických citacích, aniž by přihlížel k celkovému kontextu. 

15.         Dále navrhovatel tvrdí, že zadavatel nepřípustně zohledňuje, zda navrhovatel v průběhu soutěžního dialogu vyvíjí budoucí řešení (k jehož dodání dosud ani nebyl vybrán). Dle navrhovatele Úřad k této námitce předložil nesmyslné a vnitřně odporující se argumenty.

16.         Navrhovatel je přesvědčen, že zadavatel porušuje zákon i závěry rozhodovací praxe, když odmítá vývoj „na míru“ a požaduje „otevřené řešení“, neboť tím nemístně předepisuje způsob, jakým budou jeho potřeby uspokojeny. Toto pochybení zadavatele Úřad nechal dle navrhovatele bez nápravy.

17.         Navrhovatel brojí proti definici klíčového pojmu „otevřený systém“, neboť má za to, že jej zadavatel nevymezil, v důsledku čehož je vymezení předmětu plnění netransparentní a neurčité.

18.         Konečně v této úvodní části rozkladu navrhovatel namítá, že ani navazující konkrétní důvody vyloučení nejsou oprávněné a podle navrhovatele Úřad není odborně kvalifikován k tomu, aby tyto ryze technické skutečnosti autonomně posoudil (bez provedení znaleckého posudku). Úřad pouze přebírá tvrzení zadavatele, která jdou k tíži navrhovatele.

19.         V další části rozkladu se námitky svým obsahem opakují, proto jsou níže vybrány jen takové námitky navrhovatele, které nebyly uvedeny v úvodní části rozkladu.

20.         Podle názoru navrhovatele nebylo transparentním způsobem definováno zadání, tedy konkrétní potřeby zadavatele, a z tohoto důvodu nemohlo být definováno ani řešení v takové podobě, aby o něm mohl zadavatel transparentně rozhodovat z hlediska vhodnosti či nevhodnosti. Navrhovatel navrhuje způsob, jak měl zadavatel vést ŘSSD, a sice že k určitému kroku v rámci ŘSSD měla proběhnout písemná sumarizace požadavků zadavatele, podepsaná aktualizace řešení dodavatelů, která by na tyto změny a výsledky jednání reagovala. Navrhovatel má za to, že ze zadávací dokumentace (dále jen „ZD“) neplyne, že architektonický návrh zadavatel vnímá jako řešení dle § 69 odst. 5 zákona.

21.         Navrhovatel mj. brojí proti komunikaci mezi zadavatelem a navrhovatelem v rámci ŘSSD, neboť je toho názoru, že komunikace měla být písemná alespoň ve významných otázkách. Dle navrhovatele zvukové záznamy a zápisy z jednání nepředstavují dostatečné zdokumentování obsahu komunikace.

22.         Navrhovatel tvrdí, že požadavek na „otevřené řešení“ není potřebou zadavatele, ale pouze jedním z několika způsobů, jak lze jeho potřeby uspokojovat. Dle navrhovatele zadavatel není oprávněn diktovat dodavatelům cestu (tedy způsob), jakým uspokojují definované potřeby zadavatele. Navrhovatel je tak přesvědčen, že zadavatel nemohl vyloučit jeho řešení jen z toho důvodu, že na vytvoření daného systému musí ještě pracovat, a že hotové řešení nemá již připravené předem.

23.         Podle názoru navrhovatele je nesmyslné tvrzení zadavatele, že „otevřenost“ je imanentní vlastnost systému, tedy systém je (nebo není) otevřený stále, ať už je dodán jednomu, nebo několika klientům. O vhodnosti/nevhodnosti řešení tak měl být vypracován znalecký posudek.

24.         V poslední části rozkladu se navrhovatel vyjadřuje k jednotlivým důvodům vyloučení. Navrhovatel nesouhlasí s názorem Úřadu, že jeho řešení nepočítá s takovou mírou otevřenosti, že by neumožnoval zpřístupnění ostatním zákazníkům.

25.         Dále navrhovatel nesouhlasí s posouzením Úřadu ohledně požadavku na klienta pro mobilní zařízení, funkcionalitu tenkého klienta. Ačkoli Úřad shledal, že takový požadavek v ZD není, přesto pak konstatoval tento důvod vyloučení jako oprávněný s odůvodněním, že „ze strany navrhovatele nevzešla jednoznačná informace o vývoji funkcionalit systému na webové služby, ani nebyl zadavateli poskytnut časový odhad tohoto vývoje.“ Zadavatel v rámci ŘSSD nezakazoval užití PowerBulideru, tedy dle navrhovatele nevylučuje komunikaci na tenkém klientovi, ani webové řešení. Tyto vady Úřad akceptuje jako důvody vyloučení.

26.         Navrhovatel považuje rozhodnutí za nepřezkoumatelné z důvodu opomenutí podstatných okolností, tedy objektivně doložitelnou zkušenost s provozováním cloudu v nastavení SaaS. Pokud Úřad požadavek na cloudové řešení v argumentaci propojuje s požadavkem na certifikaci datového centra, tak tato okolnost nebyla důvodem vyloučení, a proto by k ní neměl Úřad přihlížet. Navrhovatel připomíná, že základním důvodem vyloučení byla dle zadavatele nezkušenost navrhovatele s provozováním cloudu. Navrhovatel má za to, že Úřad nepřípustně doplňuje argumentaci zadavatele v rozhodnutí o vyloučení, která nebyla v rozhodnutí o vyloučení použita.

27.         K části ohledně integrační platformy navrhovatel uvedl, že zadavatel neoprávněně vylučuje řešení navrhovatele na základě důvodu, který opakovaně označil jako důvod hodnoticí, který sice musí být splněn, ale nebude důvodem vyloučení. Navrhovatel považuje důvod jeho vyloučení za nepravdivý, neboť nabízel integrační platformu. Úřad vychází z nesprávně zjištěného skutkového stavu.

28.         Závěrem se navrhovatel vyjádřil k funkcím pro automatizaci digitalizace a individualizace agend. Navrhovatel je toho názoru, že zadavatel v ZD nikde nepožadoval automatizaci digitalizace. Navrhovatel nabídl technické řešení, které tuto potřebu uspokojuje nebo v budoucnu bude uspokojovat.

Závěr rozkladu

29.         Navrhovatel navrhuje, aby předseda Úřadu napadené rozhodnutí zrušil a věc vrátil Úřadu k dalšímu projednání. 

IV.          Řízení o rozkladu

30.         Úřad po doručení rozkladu neshledal podmínky pro postup podle § 87
a podle § 88 odst. 1 správního řádu předal spis se svým stanoviskem předsedovi Úřadu k rozhodnutí o rozkladu.

Vyjádření zadavatele k rozkladu

31.         Dne 26. 5. 2023 zadavatel podal vyjádření k rozkladu. Zadavatel je toho názoru, že se navrhovatel snaží navodit dojem, že zadavatel celé zadávací řízení vede tak, aby se zbavil nepohodlného dodavatele, kterým je navrhovatel. Dle zadavatele se navrhovatel argumentačně stále točí v kruhu a Úřad i zadavatele pouze zahlcuje desítkami stran textů, ve kterých je stále těžší se zorientovat. Zadavatel se ke všem námitkám navrhovatele již dříve podrobně vyjádřil ať už v rozhodnutí o námitkách, tak ve vyjádření k návrhu a i v dalších vyjádřeních ke dvěma dalším samostatným řízením zahájeným navrhovatelem ke stejné veřejné zakázce. Zadavatel je přesvědčen, že způsob vedení obrany navrhovatele proti postupu zadavatele naplňuje znaky šikanózního jednání vedeného snahou celý proces zadávání veřejné zakázky maximálně protahovat. Následně se zadavatel stručně vyjádřil ke všem námitkám navrhovatele, přičemž souhlasí se závěry Úřadu a v ostatním odkazuje na svá předchozí vyjádření.

Replika navrhovatele k vyjádření zadavatele k rozkladu navrhovatele

32.         Dne 23. 6. 2023 předseda Úřadu obdržel od navrhovatele podání, jehož obsahem je replika navrhovatele k vyjádření zadavatele k rozkladu navrhovatele spolu se žádostí o přerušení správního řízení ve smyslu § 64 odst. 1 písm. c) zákona č. 500/2004 Sb. správního řádu, vedeného pod sp. zn. ÚOHS-S0105/2023/VZ a něj navazujícího řízení o rozkladu sp. zn. ÚOHS-R0060/2023/VZ. Navrhovatel v replice vesměs opakuje své argumenty k rozkladu, přičemž nadále setrvává na svém názoru, že postup zadavatele v ŘSSD byl netransparentní. Žádost o přerušení řízení byla zamítnuta usnesením č. j. ÚOHS-25622/2023/162 ze dne 12. 7. 2023.

Stanovisko předsedy Úřadu

33.         Po projednání rozkladu a veškerého spisového materiálu rozkladovou komisí, jmenovanou podle § 152 odst. 3 správního řádu, a po posouzení případu ve všech jeho vzájemných souvislostech byl podle § 89 odst. 2 správního řádu přezkoumán soulad napadeného rozhodnutí a řízení, které jeho vydání předcházelo, s právními předpisy, jakož i správnost napadeného rozhodnutí, ta však toliko v rozsahu námitek uplatněných v rozkladu, přičemž byl přijat následující závěr.

34.         Úřad tím, že napadeným rozhodnutím rozhodl tak, jak je v něm uvedeno, rozhodl správně a v souladu se zákonem. V další části odůvodnění tohoto rozhodnutí budou v podrobnostech rozvedeny důvody, pro které nebylo přistoupeno ke změně ani ke zrušení napadeného rozhodnutí.

V.            K námitkám rozkladu navrhovatele

Vysvětlení IT pojmů

35.         Na tomto místě je třeba pro srozumitelnost tohoto rozhodnutí nejprve vysvětlit klíčové pojmy v napadeném rozhodnutí, které budou použité i v tomto rozhodnutí.

36.         Pojem API (zkratka pro „Application Programming Interface“) označuje v informatice rozhraní, které slouží pro komunikaci mezi dvěma programy/aplikacemi. Skrze něj si mohou vyměňovat data a snáze rozšiřovat svoji funkcionalitu například právě o data, která jsou připravena někým jiným – například doplnit mapu města o pozice vozů MHD aktualizované v reálném čase. Např. otevřená data je možné skrze API libovolně zpracovat a prezentovat třeba ve webové nebo mobilní aplikaci.^[1]

37.         Tenký klient je označení pro počítač, případně počítačový program. V průběhu své činnosti, při zpracovávání zadaného úkolu závisí průběh jeho práce na chodu jiného počítače, jeho serveru. Tlustý klient oproti němu nepotřebuje další přístroj pro vykonávání předem stanovených úloh, příkazy zpracovává sám. Příkladem tenkého klienta (v překladu “thin client”) je webový prohlížeč.^[2]

38.         Webové služby reprezentují nástroj pro inovaci a zefektivnění obchodních procesů v rámci mezipodnikové organizace, nejsou novou technologií. Technologicky jsou webové služby modulární obchodní aplikací se specifikovanými rozhraními, přístupnými a provozovanými v internetovém prostředí. Jednoduše řečeno – jedná se o technologii, která umožňuje integrovat libovolné aplikace provozované na různých platformách a ovládat je prostřednictvím webového rozhraní, tj. z běžného internetového prohlížeče.^[3]

39.         Public cloud se definuje jako výpočetní služby nabízené externími poskytovateli (třetími stranami) prostřednictvím veřejného internetu tak, aby byly dostupné každému, kdo je chce použít nebo koupit. Lze je poskytovat zdarma nebo prodávat na vyžádání a umožňují zákazníkům platit jenom za využití procesorových cyklů, úložiště nebo šířky pásma, které spotřebují. Veřejné cloudy, na rozdíl od cloudů privátních, firmám umožňují nevynakládat velké prostředky na nákup, správu a údržbu místní hardwarové a aplikační infrastruktury. Za veškerou správu a údržbu systému totiž zodpovídá poskytovatel cloudových služeb. Veřejné cloudy jde také nasadit rychleji než místní infrastruktury a s téměř neomezenou škálovatelností. Každý zaměstnanec společnosti může prostřednictvím zařízení podle své volby využívat stejnou aplikaci z libovolné kanceláře nebo pobočky.^[4]

40.         Desktopové prostředí (anglicky desktop environment) je v informatice grafické uživatelské rozhraní (GUI), jehož základem je pracovní plocha. Plocha (angl. desktop) je volný prostor na obrazovce, který má připomínat desku pracovního stolu, na kterou lze umisťovat a pomocí myši podle potřeby přesouvat ikony, panely, okna apod.^[5]

K námitkám ohledně předčasnosti vyloučení navrhovatele a netransparentnosti soutěžního dialogu

41.         Navrhovatel v rozkladu tvrdí, že zadavatel předem nespecifikoval své konkrétní požadavky, a ŘSSD vedl jen proto, aby zjistil, co mu všechno trh nabízí. Navrhovatel má za to, že zadavatel postupoval metodou, že „nevím co chci, ale jak uvidím něco dobrého, tak si o to řeknu.“ Argumentace navrhovatele tak působí dojmem, že zadavatel neměl předem ujasněnou představu o tom, co by mělo být výsledkem ŘSSD.

42.         S navrhovatelem prezentovanou metodou zadavatele nelze souhlasit, neboť zadavatel již v rámci předběžných tržních konzultacích (dále jen „PTK“) zdůraznil základ toho, co potřebuje, tj. nový informační systém, neboť není spokojen se stávajícím systémem, zejména po stránce integračních a komunikačních rozhraní. Zadavatel v dokumentu „Informace o předběžných tržních konzultacích“ konkrétně zmínil: „vytvoření nové generace systému, jehož architektura by měla být otevřena integraci funkčních částí z produkce různých dodavatelů.“  Zadavatel konzultaci mířil na technickou a technologickou stránku API, tedy „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.“

43.         Zadavatel tak měl již před zahájením ŘSSD jasně specifikovaný cíl, kterého chce soutěžním dialogem dosáhnout, a sice informační systém s takovou měrou otevřenosti API, které by umožnovalo přístup k funkcím bez nutnosti součinnosti dodavatele informačního systému.

44.         Lze dát zapravdu navrhovateli, že jednání vedená v rámci ŘSSD směřovala k vyjasnění konkrétních požadavků zadavatele. To je ale právě podstata ŘSSD – nalézt v rámci jednání co nejvhodnější řešení, které by co nejvíce odpovídalo potřebám zadavatele. Pro soutěžní dialog je typická nižší míra konkretizace zadávacích podmínek, která pak umožňuje navrhnout více odpovídajících řešení a flexibilněji zapracovat případné změny zadávacích podmínek na základě výsledků jednání, včetně upřesnění kritérií pro hodnocení.

45.         Naproti tomu nelze souhlasit s názorem navrhovatele, že zadavatel předem nespecifikoval v ZD předmět veřejné zakázky. Zadavatel v bodu 2 ZD uvedl, ž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 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 zadavatel v tomto bodě ZD konstatoval, ž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.“

46.         Zadavatel tak i v ZD předestřel základ svého požadavku, kterým je otevřený informační systém a s tím související míra otevřenosti API, která umožní následný vývoj ze strany zadavatele.

47.         Navrhovatel následně v rozkladu vyvozuje z nedostatečně vymezeného předmětu veřejné zakázky jeho předčasné vyloučení. Navrhovatel se totiž domníval, že po proběhnutí jednání se zadavatelem a po vyjasnění ucelenějších potřeb zadavatele navrhovatel předloží své finální řešení. Tuto konstrukci vedení řízení dovodil z vyjádření zadavatele na jednání ze dne 17. 10. 2022, kde zadavatel uvedl, že před hodnotící (třetí) fází finálně specifikuje své potřeby (srov. bod 2.2 rozkladu). 

48.         Zadavatel na předmětném jednání uvedl, že po realizaci schůzek se všemi účastníky zpracuje konkrétní formulace a zašle abstraktní formu účastníkům k posouzení, výhradám a vyjádření (viz zápis z jednání ze dne 17. 10. 2022 v pasáži cíle a záměry MU). Je pravda, že zadavatel před zasláním výzvy k podání nabídek již musí mít finálně zpracované zadávací podmínky v takovém detailu, aby bylo dodavatelům zcela zřejmé, jaké parametry v rámci jakých řešení musí jimi předkládané nabídky splňovat. Zadavatel se na tomto jednání snažil z podaných informací navrhovatele i ostatních účastníků řízení finalizovat podobu výzvy pro podání nabídek. Zadavatel nicméně není povinen zaslat dodavatelům konkrétní formulace výzvy ještě v době před hodnocením vhodnosti/nevhodnosti řešení. Zákon předpokládá formalizovanou výzvu až v rámci ust. § 69 odst. 6 zákona, kde stanoví, že zadavatel po ukončení soutěžního dialogu vyzve ty účastníky řízení, které nevyloučil z důvodu nevhodnosti nalezených řešení, k podaní nabídek.

49.         Zákon nestanovuje konkrétní pravidla průběhu jednání v rámci soutěžního dialogu (vyjma dodržování zásad dle § 6 a pravidel komunikace dle § 211 zákona), dle kterých musí zadavatel postupovat. Tedy není povinností zadavatele po proběhnutí jednací fáze dialogu učinit tzv. mezikrok v podobě písemné sumarizace požadavků zadavatele, jak v rozkladu požaduje navrhovatel. Podstatné je, že požadavky zadavatele byly navrhovateli srozumitelným způsobem sděleny. To k dodržení zásady transparentnosti ve smyslu požadavku, aby bylo dodavateli jasné, co se po něm žádá, postačí.

50.         Lze podotknout, že je vhodné, aby zadavatel své požadavky formálním způsobem shrnul. Přispěje to k přehlednosti soutěžního dialogu. Není to nicméně požadavkem zákona. Pokud zadavatel již po jednání ze dne 17. 10. 2022 zjistil, že navrhovatel není schopen naplnit jeho potřeby, zákon mu dovoluje v této fázi nevhodné řešení dle § 69 odst. 5 zákona ze zadávacího řízení vyloučit, aniž by byl nucen ještě písemně a souhrnným způsobem upozornit navrhovatele, co všechno musí splnit, aby mohla být jeho nabídka v zadávacím řízení hodnocena. Zadavatel však samozřejmě nesmí nikoho vyloučit svévolně. Může tak činit pouze na základě oprávněných důvodů uvedených v rozhodnutí o vyloučení. Jednotlivé navrhovatelem namítané důvody vyloučení Úřad přezkoumával samostatně, přičemž toto posouzení Úřadu bude v tomto rozhodnutí přezkoumáno níže.

51.         Pokud jde o námitku navrhovatele ohledně předčasnosti jeho vyloučení, neboť z jeho strany nedošlo k předložení uceleného řešení, tak k tomu se Úřad správně vyjádřil v bodě 152 odůvodnění napadeného rozhodnutí, ve kterém uvedl, že architektonický návrh předložený navrhovatelem dne 9. 9. 2021 byl základem pro další jednání se zadavatelem. V rámci soutěžního dialogu proběhlo s navrhovatelem sedm schůzek, kde se jednalo o předloženém návrhu, přičemž navrhovatel v rámci jednání předkládal návrhy na vylepšení předmětného architektonického návrhu. Zadavatel na začátku jednání v ŘSSD tuto pracovní verzi navrhovatele neodmítl, ale s navrhovatelem diskutoval o nalezení vhodného řešení, které by odpovídalo jeho požadavkům. Tedy tento prvně předložený architektonický návrh ze strany navrhovatele nelze chápat bez dalších jednání jako finální „řešení“. Zadavatel až s přihlédnutím ke všemu, co zaznělo na jednáních, vyhodnotil, že řešení navrhovatele, které je tvořeno architektonickým návrhem a modifikacemi, které vzešly ze soutěžního dialogu, není pro zadavatele vhodné. Navrhovateli lze dát částečně zapravdu, že samotný architektonický návrh nelze považovat za finální řešení, jehož vhodnost by měla být předmětem posouzení. To však ani Úřad v bodech 152 a 153 napadeného rozhodnutí nečiní, neboť klade důraz právě na modifikace vzešlé z jednání.

52.         Z výše uvedeného plyne, že Úřad nepovažoval za řešení navrhovatele onen „2 roky starý dokument“, ani mu nepřipsal žádné speciální právní účinky, které navrhovatel nemohl čekat (bod 2.11 rozkladu), a nečiní tak ani zadavatel.

53.         Úřad správně reagoval v bodě 163 odůvodnění napadeného na námitku navrhovatele, kterou navrhovatel tvrdil, že zadavatel v rámci rozhodnutí o vyloučení ani jednou neodkázal na architektonický návrh navrhovatele, když Úřad v tomto bodě na základě citací zadavatele vyložil, jak zadavatel „řešení“ navrhovatele rozumí. Zadavatel v citaci neuvedl pouze nabízené řešení, ale řešení s celkovou koncepcí a vizí jeho rozvoje do budoucna. Úřad tak nedotváří úvahy zadavatele, jak se navrhovatel v rozkladu domnívá, neboť z citace zadavatele z rozhodnutí o vyloučení je zřejmé, že zadavatel hodnotil vhodnost předloženého řešení s přihlédnutím ke všem informacím, které na jednáních zazněly. Není ostatně ani logickým závěr, že by zadavatel snad při posuzování vhodnosti řešení navrhovatele architektonický návrh nebral vůbec v úvahu, když právě ten měl být základem pro jednání v soutěžním dialogu. Jako takovýto základ by se návrh musel logicky do řešení nějak promítnout.

54.         Lze tak shrnout, že pojem řešení je třeba chápat jako souhrn informací a prohlášení, která účastník v rámci jednací fáze ŘSSD ve vztahu k předpokládané podobě předmětu plnění veřejné zakázky deklaruje.

55.         Vzhledem k výše uvedenému je zřejmé, že navrhovatel svou argumentací neprokázal, že by ho zadavatel předčasně vyloučil z ŘSSD.

56.         Druhá část námitek navrhovatele směřuje do netransparentnosti vedení ŘSSD, zejména pokud jde o zpětnou kontrolu postupu zadavatele (bod 2.13 rozkladu a násl.).  K těmto námitkám lze uvést, že zadavatel všechna jednání soutěžního dialogu zaznamenával zvukovými záznamy, ze kterých také provedl zápisy. Úřad tak má k dispozici podklady pro kontrolu průběhu jednaní, ze kterých lze vyčíst, co bylo obsahem jednání a zda na základě těchto informací zadavatel vyloučil řešení navrhovatele z důvodu jeho nevhodnosti. Tento postup zadavatele lze považovat za transparentní.  Nelze souhlasit s tvrzením navrhovatele, že by tato jednání byla nedostatečně zdokumentována, neboť ze zápisů z jednání a taktéž ze zvukových záznamů je zřejmé, kdo mluví za dodavatele a kdo za zadavatele. Není zřejmé, proč zvukové záznamy nejsou pro navrhovatele transparentním zachycením průběhu jednání. 

57.         Navrhovatel dále brojí proti ústní komunikaci mezi zadavatelem a navrhovatelem, neboť je toho názoru, že měla probíhat dle § 216 zákona (pozn. předsedy Úřadu, navrhovatel zřejmě měl na mysli ust. § 211 zákona) písemně.

58.         Podle § 211 odst. 1 zákona probíhá komunikace mezi zadavatelem a dodavatelem v zadávacím řízení a při zvláštních postupech podle části šesté písemně. Zákon připouští také ústní komunikaci mezi zadavatelem a dodavatelem v zadávacím řízení, ale tato musí být adekvátně zdokumentována. Jak bylo výše uvedeno, zápisy i zvukové záznamy jsou dostatečně podrobné na to, aby na základě nich bylo možno postup zadavatele přezkoumat. Stávající, pro případ rozhodné, právní úpravě, na kterou navrhovatel v rozkladu odkazuje, tedy zadavatel vyhověl.

59.         K výše uvedenému ustanovení zákona je třeba doplnit, že ústní formu komunikace je možné využít pouze tam, kde zákon výslovně nestanoví povinnost písemného sdělování informací, popřípadě kde tato povinnost neplyne z povahy sdělovaných informací. Zákon zadavateli dává možnost při jednání s dodavateli využít ústní komunikaci, přičemž obsah ústní komunikace musí být dostatečným způsobem zdokumentován a uchován. Zejména v případě, kdy by ústní komunikace mohla mít podstatný dopad na obsah nebo hodnocení nabídek, musí být dostatečně přezkoumatelná.

60.         Obdobně se k ústní komunikaci vyjádřil Úřad v rozhodnutí sp. zn. ÚOHS-S0409/2020/VZ, č. j.   ÚOHS-42019/2020/521/Opi ze dne 31. 12. 2020, kde uvedl, že „jde-li o ústní/osobní vedení procesu objasňování nebo doplňování nabídky dle § 46 zákona, pak v této věci lze vycházet § 211 odst. 1 zákona, který stanoví, že komunikace mezi zadavatelem a dodavateli v zadávacím řízení a při zvláštních postupech podle části šesté probíhá písemně; není-li v tomto zákoně stanoveno jinak, lze použít i ústní komunikaci, je-li obsah v dostatečné míře zdokumentován, zejména zápisy, zvukovými nahrávkami nebo souhrny hlavních prvků komunikace. Dotčené ustanovení zákona nestanoví úkony, které není možné činit ústně, vyžaduje-li však zákon, aby určitý úkon byl proveden výhradně písemně, je toto uvedeno v příslušném ustanovení (např. § 39 odst. 6 zákona). V případě objasnění nabídky je tak ústní forma úkonu povolena, to však s ohledem na povinnost dodržovat zásadu transparentnosti, tedy pouze za předpokladu jejího dostatečného zdokumentování.“ V daném případě zákon nezakotvuje povinnost zadavateli jednat v soutěžním dialogu výlučně písemně.

61.         Podpůrně je třeba přihlédnout i k tomu, že nově zní ustanovení § 211 odst. 2 zákona (účinnost od 16. 7. 2023), kde je zakotvena ústní komunikace, takto: „Ústní komunikaci mezi zadavatelem a dodavatelem v zadávacím řízení nebo při zvláštních postupech podle části šesté může zadavatel použít, požadovat nebo připustit, pokud tento zákon nestanoví jinak, při

a) jednání s dodavatelem tam, kde ho tento zákon připouští,

b) prohlídce místa plnění,

c) provedení kontroly technické kapacity nebo opatření týkajících se zabezpečení jakosti nebo výzkumu podle § 79 odst. 2,

d) rozhovoru mezi porotou a účastníky soutěže o návrh podle § 148 odst. 6,

e) jiných sděleních, jež se netýkají zásadních prvků zadávacího řízení, mezi které patří zejména zadávací dokumentace, žádost o účast, potvrzení zájmu a nabídka.“

62.         Z novelizovaného znění ustanovení § 211 zákona plyne, že zadavatel může ústní komunikaci použít tehdy, jedná-li s dodavatelem v případech, kdy je jednání přípustné. Takovým případem i je ŘSSD. Zákonodárce přitom nijak neomezil použití ústní komunikace podle toho, o čem zadavatel s dodavatelem jedná. Zjevně tedy zákonodárce nezamýšlel přikázat použití písemné formy jednání v případě „významných otázek, jako je seznam požadavků a potřeb zadavatele, které si ten pro sebe během soutěžního dialogu průběžně vyjasňoval (i v komunikaci s dalšími účastníky), a jako jsou reakce dodavatelů na tyto požadavky, které by pak ve svém souhrnu mohly představovat návrhy jejich řešení.“ (bod 2.15 rozkladu).

63.         Z důvodu rozsáhlých jednání v rámci soutěžního dialogu je logické, že zadavatel zvolil ústní formu komunikace při jednání, což mu ostatně zákon dovoluje. Zadavatelem předložených zvukových záznamů z jednání s navrhovatelem je sedm, přičemž s každým účastníkem vedl stejný počet jednání. Každý z těchto záznamů má cca 2 až 3 hodiny. Způsob komunikace, který požaduje navrhovatel, tj. aby zadavatel o klíčových aspektech komunikoval písemně např. formou otázek a odpovědí mimo jednotlivá jednání, se ve zdejším případě (s ohledem na předmět veřejné zakázky) jeví jako zbytečně složitý a zdlouhavý. V tomto postupu zadavatele tak nelze shledat rozpor se zákonem. Navíc z pohledu transparentnosti nelze shledat rozdíl mezí tím, zda zadavatel položí otázku na ústním jednání, které je řádně zdokumentováno, nebo písemně mimo probíhající jednání.

64.         Pokud jde o příklad soutěžního dialogu provedený TAČR, na který navrhovatel v rozkladu odkazuje, není pro nyní řešený případ rozhodující. Je více způsobů, jak vést soutěžní dialog. Způsob zaznamenávání soutěžního dialogu prostřednictvím zvukových záznamů a zápisů není v rozporu se zákonem a v namítaném případě zadavatel tuto formu zaznamenávání jednání také využil, jak lze vyvodit z informací podaných navrhovatelem v rozkladu (bod 2.19). Navrhovatel vyzdvihuje skutečnost, že tento zadavatel navíc zaznamenal ještě samostatně písemně rozhodné skutečnosti podepsané účastníky. Tento krok je na konkrétním zadavateli, ale zákon takovouto povinnost zadavateli nestanovuje.

K námitkám nezákonného hodnocení stávajícího řešení a diskriminaci navrhovatele

65.         Jak již bylo výše v tomto rozhodnutí uvedeno, zadavatel neposuzoval stávající řešení bez zohlednění informací, které navrhovatel uvedl na jednáních. Navrhovatel setrvává na svém závěru, že zadavatel neposuzoval „řešení“ nabídnuté v rámci soutěžního dialogu, které by upravil o ty funkce, které zadavatel požadoval. Úřad v bodě 161 odůvodnění napadeného rozhodnutí správně posoudil ze str. 3 rozhodnutí o vyloučení, že zadavatel nedostatky řešení vztahuje k „řešení navrženému a diskutovanému se zástupci firmy Magion.“. Nelze souhlasit s tvrzením navrhovatele, že z rozhodnutí o vyloučení nejde poznat, co zadavatel posuzoval a k čemu přihlédl. Právě na str. 3 rozhodnutí o vyloučení zadavatel např. uvedl, že „Magion v současné době nedisponuje rozsáhlým otevřeným API (zpřístupněným všem zákazníkům), 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 Magionu. 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). Tento rozsah je proti ostatním řešením na trhu značně omezený a pro potřeby MU nepostačující. Navíc Magion ani nedeklaroval, že by se situace v budoucnu změnila a poskytl otevřené rozhraní všem zákazníkům. Jak zaznělo v rámci soutěžního dialogu, pořád je počítáno primárně s vývojem API na zakázku.“ (pozn. zvýraznění doplněno). Z daného textu je zřejmé, co zadavatel posuzoval a co konkrétně je pro zadavatele nedostačující, přičemž zadavatel v dalších bodech konstatoval další nedostatky navrženého řešení navrhovatele. Nedostatečnost nabízeného klíčového parametru, čímž je otevřenost API, vyplývá i ze zápisu z posledního jednání ze dne 17. 10. 2022 např. na str. 6 zápisu z jednání, kde navrhovatel na otázku „Váš navrhovaný seznam je to, kam jste ochotni nás nebo API pustit? Zbytek je core, kam nemůžeme?“, odpověděl, že vybral úlohy, kde to má smysl.

66.         Úřad ve správním řízení hodnotí proti sobě jdoucí tvrzení navrhovatele a zadavatele, přičemž žádného z účastníků neupřednostnil, pouze posuzoval a vyhodnocoval, které tvrzení vychází z podkladů ŘSSD, potažmo správního řízení. Jelikož má zadavatel průběh všech jednání řádně zdokumentován jak zvukovými záznamy, tak i zápisy z jednání, důvody vyloučení navrhovatele uvedené v rozhodnutí o vyloučení mají oporu již v těchto jednáních, které Úřad přezkoumal. Úřad se tak nedopustil porušení rovnosti účastníků správního řízení ve smyslu § 7 správního řádu.

67.         Navrhovatel nebyl v rámci soutěžního dialogu zadavatelem nijak diskriminován, neboť zadavatel s ním vedl stejný počet jednání jako s ostatními uchazeči, přičemž kdyby hodnotil stávající sytém již od počátku, vyloučil by ho nejspíše po prvních jednáních po podání architektonického návrhu. Současně je třeba zopakovat, že z jednání a z rozhodnutí o vyloučení vyplynulo, že zadavatel nehodnotil současný systém navrhovatele, nýbrž při posuzování řešení k architektonickému návrhu pouze přihlížel a své závěry vyslovil právě k řešení navrhovatele, které vzešlo z jednání s ním. Je tak možno se ztotožnit s posouzením Úřadu provedeným v bodech 160 – 164 odůvodnění napadeného rozhodnutí.

68.         Navrhovatel tvrdí, že v návrhu uvedl řadu skutečností, které ještě před skončením ŘSSD avizují, že jeho řešení bude vyměněno, tedy že neuspěje. Tím se navrhovatel cítí diskriminován. Navíc dle navrhovatele nebylo ze strany zadavatele nikdy naznačováno, že by bylo stávající řešení nevyhovující. Tato argumentace navrhovatele je mylná, neboť zadavatel vyhlásil ŘSSD právě proto, že chce novou koncepci systému, a to otevřený informační systém, nikoli stávající systém s určitým upgradem. Tedy nelze mluvit o tom, že by zadavatel předjímal, že navrhovatel neuspěje, jak se domnívá navrhovatel v rozkladu, ale o výměně systému za něco modernějšího dle představ zadavatele. To plyne už z dokumentu PTK, kde zadavatel uvedl svou představu o otevřenosti informačního systému. Zadavatel usiluje o výměnu řešení, nikoliv o výměnu dodavatele ve smyslu, že by vytvářel podmínky proto, aby právě navrhovatel nemohl v ŘSSD uspět.

69.         Není pravda, že by zadavatel před zahájením soutěžního dialogu neseznámil navrhovatele s tím, že stávající systém je nevyhovující, neboť v již v rámci PTK uvedl, že „stávající verze EIS již nedostačuje požadavkům a potřebám univerzity po stránce dat a zpracovatelských funkcí, a zejména po stránce integračních a komunikačních rozhraní. MU proto formou předběžných tržních konzultací mapuje možnosti softwarového trhu.“ Navrhovatel nebyl zadavatelem nijak diskriminován, jelikož ho zadavatel seznámil se svojí představou o budoucím IT systému už v rámci PTK a navrhovatel mohl nabídnout své řešení dle těchto potřeb zadavatele. 

K tvrzení navrhovatele o neoprávněném zohledňování technologického vývoje u navrhovatele

70.         Dle navrhovatele Úřad zmatečně vyvrací jeho námitku, že zadavatel neoprávněně zohledňuje, zda navrhovatel v průběhu soutěžního dialogu pracuje na vývoji budoucího řešení, přičemž je toho názoru, že není povinen v době probíhajícího soutěžního dialogu pracovat na budoucím předmětu plnění. Navrhovatel je toho názoru, že si Úřad protiřečí, když uvádí, že zadavatel nehodnotí, zda probíhá vývoj, ale hodnotí úroveň vývoje jednotlivých technologií. Úřad tak podle navrhovatele přiznává, že zadavatel oprávněně hodnotí zkušenosti dodavatelů.

71.         S tímto názorem navrhovatele nelze souhlasit, neboť v tvrzení Úřadu nelze shledat žádnou zmatečnost či protiřečení si, ale logickou úvahu, kterou vyvodil z obsahu rozhodnutí o námitkách (viz podrobně bod 166 odůvodnění napadeného rozhodnutí). Tam zadavatel citoval závěry navrhovatele, které zazněly na jednáních. Úřad správně shledal, že zadavatel hodnotil stav vývoje jednotlivých technologických prvků systému ve vztahu k informacím, které navrhovatel uvedl na posledním jednání ze dne 17. 10. 2022, kde se dle názoru zadavatele navrhovatel v některých aspektech neposunul, a nehodnotil, zda navrhovatel na vývoji již pracuje. Tu lze doplnit, že nedostatečný vývoj řešení navrhovatele lze vyčíst také ze zápisu z posledního jednání ze dne 17. 10. 2022 (str. 5 zápisu z jednání ze dne 17. 10. 2022), kde navrhovatel uvedl, že by musel sadu webových služeb dodělat ze 70 až 80 %, přičemž nebyl schopen uvést, v jakém časovém horizontu toto dovyvine. Zadavatel na jednání uvedl, že požaduje pokrytí dalších webových služeb do roka. Na to navrhovatel reagoval tím, že mu má zadavatel říct, v jakém pořadí, které služby potřebuje, přičemž již neodpověděl, jak dlouho by to trvalo. Dále navrhovatel uvedl, že neumí nabídnout něco otevřenějšího než otevření funkcionality entitami.

72.         Tyto skutečnosti nelze chápat tak, že by snad zadavatel v rámci posouzení vhodnosti řešení zvýhodňoval paušálně existující řešení oproti řešením, která existují toliko v rovině návrhu. Zjevnou potřebou zadavatele bylo, aby bylo řešení realizováno v rozumném časovém horizontu. Úvahy zadavatele na téma, v jakém stádiu vývoje se navrhovatel nachází, pak byly potřebné právě pro zodpovězení otázky, jestli je vůbec reálné, aby řešení v potřebné době vzniklo. Otázku času plnění lze pojmově zahrnout pod pojem vhodnost plnění, neboť v řadě případů jen včasné plnění může uspokojit potřeby zadavatele. Pokud lze z jednání usoudit, že navrhovatelovy zkušenosti nepostačují pro větší otevřenost systému a že už vůbec nedokáže předvídat, za jaký čas by se přiblížil požadované míře otevřenosti API, je i logické, že zadavatel bude zohledňovat právě i časový aspekt vývoje. Stejně tak zadavatel nehodnotil, zda navrhovatel již pracuje na budoucím předmětu plnění, ale zda jeho celková koncepce k otevřenosti API směřuje tak, jak je to potřebné pro zadavatelem požadované řešení.

73.         Pokud jde o otázku, k jakému API měl navrhovatel směřovat, pak s ním nelze souhlasit v tom, že by mu nebylo známo zadání, neboť zadavatel nejenom v bodě 2 ZD, ale také na jednání s navrhovatelem, tj. dne 28. 6. 2022 představil navrhovateli, co pro něho znamená 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.“ (str. 7 zápisu z jednání).Dálena jednání dne 1. 12. 2021 zaznělo: „Požadované řešení není o předpovědi, co budeme chtít. Ideální je vytvoření frontend a vystavení jako veřejného API systému, ne vytvoření webové služby na míru a vytvoření business logiky na míru. S API komunikuje webová aplikace, plán zaintegrovat jen do střední části zpracování, integrace rozšíření a přidání dalších API. Tento styl bychom preferovali.“ (str. 6 zápisu z jednání).

74.         Námitka navrhovatele tak není důvodná, neboť zadavatel jasně vymezil, co požaduje a pouze posuzoval, jestli je reálné, že se mu takového plnění od navrhovatele dostane v požadovaném časovém horizontu. Takové úvahy jsou jednoznačně úvahami o vhodnosti řešení.

75.         Na závěr této části je tedy třeba konstatovat, že Úřad správně dospěl k závěru, že zadavatel v rozhodnutí o vyloučení, jakožto nyní přezkoumávaném úkonu, neuvedl jako důvod vyloučení skutečnost, že navrhovatel svůj systém nevyvíjel.

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

76.         Navrhovatel nadále setrvává na své námitce, že zadavatel nepřípustně a věcně neodůvodněně odmítal, aby jeho potřeby byly uspokojovány řešením vyvíjeným „na míru“.  Dle navrhovatele zadavatel není oprávněn diktovat způsob, jakým navrhovatel uspokojí definované potřeby zadavatele.

77.         Obecně, pokud navrhovatel v rozkladu (zejm. bod 2.55) vyzdvihuje dichotomii mezi potřebou zadavatele a způsobem jejího naplnění, lze mu přisvědčit potud, že zadavatel má skutečně v otázce vhodnosti řešení (§ 69 odst. 5 zákona) posuzovat pouze to, zda předložené řešení vyhovuje potřebám zadavatele. Nelze nicméně přehlížet, že je to zadavatel, kdo má určující slovo v tom, jaké řešení chce pořídit, a tedy co označí za své potřeby. Pokud zadavatel předem navrhovateli sdělí, jaký způsob naplnění svých cílů požaduje, pak se takový požadavek stává potřebou zadavatele, kterou je možno následně posuzovat ve vztahu k předloženému řešení. Naopak dodavatel nemůže zadavateli diktovat rozsah potřeb, které by zadavatel mohl v ŘSSD formulovat. Pokud je tedy dodavateli jasně předem sděleno, jakým způsobem má cíle zadavatele naplnit, je nepřípadné, aby takové požadavky zadavatele zpochybňoval argumentem, že jde vlastně jen o vymezení způsobu naplnění cílů zadavatele (jak), a nikoliv o vymezení potřeby zadavatele po materiální stránce (co).

78.         Z průběhu jednání mezi zadavatelem a navrhovatelem plyne, že došlo k protichůdným představám, jak naplnit potřebu zadavatele otevřeného API (viz bod 171 odůvodnění napadeného rozhodnutí).  Soutěžní dialog se vyznačuje právě tím, že se v průběhu jednání konkrétněji specifikují požadavky zadavatele na základě vzájemně poskytnutých informací. Na posledním jednání ze dne 17. 10. 2022 zadavatel uvedl, co preferuje. (…) „MU by preferovala firmu, která má API na své roadmapě i za poplatek, ale není to v podobě vývoje na základě specifikace. Argument Inetu – samozřejmě bude nezbytný i vývoj podle výsledku VŘ i na naší straně a společný vývoj s dodavatelskou firmou. Díváme se na celkové pokrytí systému a projekci kolik cca práce bude potřeba na straně dodavatele a naší straně. Hlavní rozdíl je mezi přístupem otevírání systému pro zákazníka na míru nebo otevřenost a následné přizpůsobení zákazníka. V Enterprise level předpokládáme otevření automaticky.“ Navrhovatel reagoval tak, že pochopil představu zadavatele, když uvedl že „MU má tedy představu pod API zpřístupnit funkcionality. Chcete testovat dodavatele, kdo to umožní svým řešením. Někdo má roadmapu, Magion zpřístupní webové služby a vyrobí funkcionality zakázkovým přístupem, ale v obou případech je potřeba nějaký čas a peníze. Oba dodavatelé budou něco vyvíjet za peníze. MU by se měla dívat na to, kolik času a jaké náklady a ceny bude stát pokrytí rozsahu funkcionalit systému. To by měli potencionální dodavatelé ocenit.“ (str. 4 zápisu z jednání, tučné zvýraznění doplněno).

79.         Zadavatel také již na jednání dne 1. 12. 2021 (viz bod 73 tohoto rozhodnutí) uvedl, co je pro něho ideální, a tím je „vytvoření frontend a vystavení jako veřejného API systému, ne vytvoření webové služby na míru a vytvoření business logiky na míru.“ (pozn. tučné zvýraznění doplněno)

80.         Ze zápisu z průběhu jednání tak vyšlo najevo, že navrhovatel měl jasnou představu tom, co zadavatel požaduje a co pro něho vhodné není, a i přes to navrhovatel nadále na jednáních prezentoval svůj vývoj rozhraní na klíč.  Zadavatel může v rámci ŘSSD odmítnout i způsob, který má vést k naplnění cíle zadavatele, kterým je co nejvíce otevřený informační systém, pokud tento způsob není dokonalý pro míru otevřenosti rozhraní API, jakou požaduje zadavatel.

81.         Zadavatel ve vyjádření ze dne 20. 2. 2023 k absenci rozsáhlého otevřeného rozhraní API představeného navrhovatelem uvedl, že „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.“ Tedy tvrzení navrhovatele v rozkladu, že momentálně systém EIS nemá API v tak rozsáhlé míře, ale v rámci jeho „dovývoje“, k němuž by dle názoru navrhovatele došlo při dodávce otevřeného systému zadavateli, by byl dovybaven, jen potvrzuje výše uvedenou citaci zadavatele.

82.         Navrhovatel tvrdí, že pro uspokojování potřeby v rámci řešení na míru není nezbytné standardizované otevřené řešení, protože postačí i příprava vhodného rozhraní, které vznikne „na míru“ v rámci dodávky otevřeného systému, a zadavatel bude mít následně neomezenou možnost vyvíjet si své funkcionality sám. Tento způsob zadavatel označil za nevhodný, neboť mu to znemožňuje realizovat vývoj řešení pro třetí strany, které by rozhraní API využívaly (viz rozhodnutí o vyloučení). Zadavatel v rozhodnutí o vyloučení vyjmenoval další nedostatky navrhovatelem nabízeného API, které je ve srovnání s plnohodnotným rozhraním API zásadně omezeno.

83.         Jak Úřad správně v bodě 173 odůvodnění napadeného rozhodnutí uvedl, zadavatel zná své vlastní potřeby nejlépe a dodavatelé jsou ti, kteří se mají svými řešeními co nejvíce přiblížit jeho potřebám a mají vnucovat své představy, jak by řešení mělo vypadat. Navrhovatel také na jednání ze dne 17. 10. 2022 přiznal, že nemá otevřený systém podobně jako velké firmy, protože nemá takový počet zákazníků (zvukový záznam z předmětného jednání přibližný čas 55:00). Úřad tak správně dospěl k závěru, že požadavek zadavatele spočívající v otevřeném rozhraní API pro budoucí vývoj funkcionalit zadavatelem je legitimní (bod 173 odůvodnění napadeného rozhodnutí). Nelze souhlasit s názorem navrhovatele, že by Úřad dovozoval v odůvodnění napadeného rozhodnutí, že tento požadavek nebylo možné uspokojit v rámci řešení „na míru“, pouze posoudil, zda je požadavek odůvodněn potřebami zadavatele.

84.         Ostatně souhlasit s tvrzením navrhovatele, že požadavek na otevřený systém není potřebou zadavatele, ale jeden z několika způsobů, jak lze potřeby zadavatele uspokojovat, nelze už proto, že cílem předmětu plnění je „otevřený informační systém s otevřeným API, které umožní zákaznický vývoj a rozvoj procesů a funkčnosti pro Masarykovu univerzitu.“ Klíčová potřeba zadavatele je mít otevřený systém, tedy systém s otevřeným rozhraním API, a právě o této pro zadavatele nejdůležitější potřebě se i vede celý soutěžní dialog.

85.         Odkaz navrhovatele na rozhodnutí Úřadu sp. zn. ÚOHS-S0209/2019/VZ, č. j. ÚOHS-41378/2020/510/MKo ze dne 21. 12. 2020, dle kterého by měl zadavatel v prvé řadě stanovit cíle a vlastnosti předmětu plnění, není po daný případ přiléhavý, neboť zadavatel v nyní posuzovaném případě vede ŘSSD, které se vyznačuje právě tím, že zadavatel nemá konkrétněji specifikovaný předmět plnění.  Pokud by totiž zadavatel do jednání šel s tím, že má o předmětu plnění jasno, nemusel by řízení se soutěžním dialogem vůbec zahajovat. Odkazovaný případ se týkal zjednodušeného podlimitního řízení.

K námitce netransparentnosti pojmu „otevřený systém“

86.         Navrhovatel nadále trvá na svém tvrzení, že zadavatel používá pojem „otevřený systém“ netransparentně, neboť nepředložil žádnou definici tohoto pojmu.

87.         K tomuto je nejprve třeba opět říci, že pokud by zadavatel předložil uceleně, co požaduje, nemusel by vést ŘSSD. Právě ŘSSD mu mělo ujasnit, jakou míru otevřenosti rozhraní API jsou dodavatelé na trhu schopni poskytnout. Jak již bylo uvedeno v části „K námitkám ohledně předčasnosti vyloučení navrhovatele a netransparentnosti soutěžního dialogu“, z jednotlivých kroků zadavatele nelze shledat, že by jeho základní požadavky byly v rámci ŘSSD nejasné (viz body 42 až 46 tohoto rozhodnutí).  Zde je třeba doplnit, že způsoby řešení nabízené dodavateli a míra otevřenosti jsou předmětem vyjednávání v rámci ŘSSD o tom, co jsou schopni dodavatele na trhu poskytnout.  

88.         Lze se ztotožnit s posouzením Úřadu, který ze ZD a z diskuse v rámci soutěžního dialogu vyvodil závěr, že „otevřenost systému“ závisí na míře otevřenosti jeho API rozhraní (viz body 176 až 181 odůvodnění napadeného rozhodnutí). Otevřenost systému je v tomto případě pro zadavatele stěžejní oblast, o které se jednalo na sedmi jednáních, tedy navrhovatel měl dostatek času si od zadavatele vyjasnit, co tím zadavatel konkrétně myslí. Pokud skutečně navrhovatel nerozuměl, co pod pojmem otevřenost systému zadavatel zamýšlí, mohl položit zadavateli dotaz. Zadavatel v průběhu jednání jednal s navrhovatelem jakožto s dodavatelem, který se dlouhodobě zabývá vývojem informačních systémů, a který mu současně provozuje stávající systém. Z těchto důvodů zadavatel očekával, že pojmu otevřenosti rozhraní API rozumí. O to víc, když se navrhovatel pojmu otevřenosti systému věnuje i v rámci jím vypracovaného architektonického návrhu (viz bod 182 odůvodnění napadeného rozhodnutí).

89.         Lze tak označit námitku navrhovatele o nesrozumitelnosti tohoto klíčového pojmu po všech jednáních, na kterých s předmětným pojmem navrhovatel operoval a také diskutoval míru otevřenosti, jednak za opožděnou a také za účelovou. Účelovou z toho důvodu, že navrhovatel tomuto pojmu dobře rozumí, když mj. v návrhu uvedl, že jako odborník na SW systémy zodpovědně prohlašuje, že absolutně otevřený systém na trhu neexistuje.  V rozkladu obdobně tvrdí, že univerzální „otevřený“ systém fakticky neexistuje. Zadavatel pak ani v ŘSSD nepožaduje absolutní otevřenost systému, ale soutěžním dialogem nalézá míru otevřenosti rozhraní API, kterou mu je trh schopen nabídnout. 

90.         Navrhovatel v rozkladu rozebírá útržky z diskuse na jednání s tím, že nedávají žádný smysl. Pro posouzení takto komplikovaného tématu je třeba vzít v úvahu fakt, že diskuse probíhá mezi odborníky v daném oboru, kteří používají odborné IT pojmy jim dobře známé. Proto jednotlivé myšlenky zadavatele vytrhnuté z kontextu celé diskuse nemusí dávat smysl, avšak odborníkovi jako je navrhovatel, který se celé diskuse účastnil, by měly dávat smysl o to víc, když z těchto jednání je zřejmé, že na ně reaguje.

91.         Úřad nehodnotí technickou stránku věci, ale pouze přezkoumal, zda byl pojem „otevřenost“ systému pro navrhovatele přehledný, srozumitelný, o čemž Úřad z přuběhu jednání správně usoudil, že byl (konkrétně body 175 až 183 odůvodnění napadeného rozhodnutí).

K jednotlivým důvodům vyloučení

92.         Před tím, než přistoupím k úvahám Úřadu týkajícím se důvodů vyloučení, je třeba říci, že Úřad správně konstatoval, že není oprávněn v rámci přezkumu důvodů vyloučení zkoumat představy zadavatele o technických náležitostech v rámci ŘSSD.

93.         Základní východiska přezkoumání postupu zadavatele v zadávacím řízení shrnul Nejvyšší správní soud v rozsudku ze dne 17. 8. 2021, č. j. 7 As 199/2021 - 71, následovně: „[Ú]kolem žalovaného a správních soudů je kontrola rámce, v němž se výběr provádí, nikoliv samotné kvality výběru. Správní soudy ani žalovaný nemohou vstupovat do myšlenkových pochodů jednotlivých hodnotitelů, tedy členů hodnotící komise, či nahrazovat jejich uvážení vlastním správním uvážením. Úkolem správních soudů a žalovaného je kontrola těch činností zadavatele, které vytvářejí prostor pro fair podmínky pro účast uchazečů v soutěži a jeho postupu v daném řízení, přičemž v tomto ohledu jsou mj. oprávněni posuzovat dodržení zásady transparentnosti. (…)[P]rostřednictvím zásady transparentnosti jsou chráněny cíle právní úpravy v oblasti veřejných zakázek, mezi které patří zajištění hospodárnosti, efektivnosti a účelnosti nakládání s veřejnými prostředky, jakož i zajištění řádné hospodářské soutěže mezi podnikateli. Předpokladem naplnění těchto cílů je přitom mj. i přezkoumatelnost rozhodnutí zadavatele a celkově racionální, logický, bezrozporný, resp. objektivní postup zadavatele během zadávacího řízení.“

94.         Přestože se výše uvedený rozsudek netýká ŘSSD, lze úvahy Nejvyššího správního soudu vztáhnout i na nyní posuzovaný případ. Úřad se nemůže stavět do pozice zadavatele a hodnotit vhodnost či nevhodnost nabízených řešení, neboť to je věcí zadavatele. Úřad pouze může ověřit, zda postup zadavatele byl v souladu se zásadou transparentnosti, tedy zda jsou důvody pro vyloučení navrhovatele náležitě odůvodněné, a z tohoto odůvodnění musí být patrné, na základě čeho zadavatel k tomuto rozhodnutí dospěl.  Úřad tak postupoval správně, když ověřoval, zda byly potřeby zadavatele předem definovány, popřípadě vyjádřeny/upřesněny v průběhu soutěžního dialogu, a zda pak byly tyto potřeby promítnuty i do rozhodnutí o vyloučení tak, aby z něho byla zřejmá nemožnost naplnění potřeb zadavatele, resp. zda některý z důvodů vyloučení není zjevným excesem, kdy zadavatel vylučuje z libovolného důvodu, který nemá opodstatnění v deklarovaných potřebách zadavatele (viz bod 185 odůvodnění napadeného rozhodnutí). Jelikož Úřad nehodnotil technickou stránku věci, nebyla zde ani potřeba nechat si zpracovat znalecký posudek.

K námitkám navrhovatele proti důvodu vyloučení – otevřenost API

95.         Zadavatel jako první důvod vyloučení navrhovatele uvedl, že navrhovatel nedisponuje takovým rozsahem otevřenosti rozhraní 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.

96.         Navrhovatel i v této části rozkladu tvrdí, že zadavatel nikde nedefinoval „otevřenost“ systému a ani to, jaká „rozsáhlost otevřenosti rozhraní API“ by už potřebu zadavatele naplnila. Okruh námitek ohledně definice „otevřenosti“ rozhraní API již byl výše v tomto rozhodnutí vypořádán, a na tyto závěry lze proto odkázat. Jak již bylo v bodě 46 tohoto rozhodnutí uvedeno, předmětem jednání v rámci soutěžního dialogu byla míra otevřenosti rozhraní API, kterou jsou schopni dodavatelé na trhu poskytnout, proto zadavatel ani nemohl konkrétněji specifikovat míru otevřenosti rozhraní API. Není pravdivé tvrzení navrhovatele, že by se Úřad k odkazu na bod 2 ZD vyjádřil tak, že zadavatel požadoval „absolutně otevřené“ řízení. Úřad z tohoto bodu ZD pouze vyvodil závěr, že zadavatel již v ZD definoval svoji potřebu nalézt otevřený systém, jehož otevřenost jako základní vlastnost systému je vnímaná skrze co nejvyšší otevřenost rozhraní API a následně v soutěžním dialogu jednal o míře této otevřenosti.  Současně potřeba otevřenosti systému pro zadavatele znamená mít obecně zpřístupněné API i pro všechny další zákazníky, nikoli rozhraní API vyvinuté dodavatelem pouze pro zadavatele. Úřad správně konstatoval v bodě 187 odůvodnění napadeného rozhodnutí, že se jedná o legitimní požadavky zadavatele, které odráží potřebu mít informační systém, v rámci kterého bude zadavatel mocivyvíjet vlastními silami další funkcionality bez nutnosti součinnosti dodavatele a ty dále poskytovat jiným subjektům.

97.         Navrhovatel namítá nerovný přístup Úřadu spočívající v tom, že Úřad údajně nedodržuje pravidla, která si pro přezkum důvodů pro vyloučení navrhovatele sám vytyčil (zejm. body 184 a 185 napadeného rozhodnutí), a zatímco Úřad hodnotí požadavky a potřeby zadavatele z pohledu jejich oprávněnosti, ačkoliv nejdříve uvedl, že to činit nebude, a to jen tehdy, jde-li to ku prospěchu zadavateli, následně nastolený rámec přezkumu důsledně dodržuje vůči navrhovateli. Tato námitka není důvodná, protože Úřad nevyvozuje z legitimity požadavků zadavatele konkrétní negativní právní následky pro navrhovatele. Zda je určitý požadavek oprávněný, je přezkoumáno (např. bod 187 napadeného rozhodnutí) nad rámec a jde tak v podstatě o procesní výhodu pro navrhovatele – ačkoliv by se totiž ve správním řízení mělo řešit výhradně to, zda navrhovatel požadavky zadavatele dodržel, či nikoliv, a tedy jestli zadavatel navrhovatele vyloučil v souladu se svými požadavky, či nikoliv, hodnotí se nad rámec nutného ještě i otázka, zda zadavatel má pro své požadavky dobré důvody.

98.         Námitka navrhovatele ohledně nesdělení zadavatele o nepřípustnosti zakázkové úpravy API není důvodná, neboť zadavatel projevil vůli vyhnout se zakázkové úpravě rozhraní API již v PTK, kde směřoval diskusi k odpovědi na otázku, jakými API jsou 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 (obdobně i výzva k účasti, viz bod 126 napadeného rozhodnutí). Rovněž zadavatel v průběhu soutěžního dialogu na jednání ze dne 1. 12. 2021 uvedl, že ideální je dle zadavatele „vytvoření frontend a vystavění veřejného API systému, ně vytvoření webové služby na míru a vytvoření business logiky na míru“ (str. 6 zápisu z jednání). 

99.         Navrhovatel dále brojí proti citaci z jednání ze dne 17. 10. 2022, na kterou Úřad odkazuje v bodě 188 odůvodnění napadeného rozhodnutí. Navrhovatel je toho názoru, že z této citace nelze vyvodit závěr, že řešení navrhovatele „není přístupné ostatním zákazníkům“. Úřad z této citace ovšem vyvodil i jiný závěr, a to ten, že řešení nenaplňuje potřebu otevřenosti do takové míry, jakou zadavatel očekává. Z jednání vyplynulo, že navrhovatel nemá takové REST API a webové služby, které by pokrývaly celý systém, což v podstatě znamená menší rozsah rozhraní API.  Zadavatel se ve svém vyjádření o tomto rozhraní vyjádřil jako o minimálním rozhraní API. Navrhovatel právě v Úřadem odkazované citaci nabízí, že udělá rozhraní na všechny úlohy, které jsou v systému a u kterých to má smysl. Tím by zadavatel musel nejprve čekat na vývoj rozhraní od navrhovatele přímo pro zadavatele, a teprve poté by bylo možné přistoupit k integraci pomocí API do ostatních IT systémů. Tuto úvahu podporuje také např. vyjádření zadavatele v rozhodnutí o námitkách, kde zadavatel popsal obsah diskuse ze zvukového záznamu a uvedl, co to pro něho znamená. „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).“  Tedy tvrzení navrhovatele, že jeho řešení téměř naplňuje požadavek na přístup třetích stran, nebo se k tomu blíží, je zavádějící. Přechod na strategii otevření API by totiž vyžadoval nějaký čas s tím, že není jisté, zda navrhovatel zpřístupní API i pro třetí strany (viz rozhodnutí o vyloučení).

100.     Úřad správně došel k závěru, že z proběhlých jednání vyplynulo, že řešení, které navrhovatel na jednáních prezentuje, není pro zadavatele dostatečné, tedy nenaplňuje výše zmíněné potřeby zadavatele do míry jím požadované.

101.     Na tomto místě je možno říct, že zadavateli postačí jeden důvod pro vyloučení navrhovatele, přičemž v daném případě byla tím hlavním důvodem nedostatečná míra otevřenosti rozhraní API nabízené v řešení navrhovatele. Další důvody vyloučení, i kdyby nebyly oprávněné, nemohou na výsledku rozhodnutí zadavatele o vyloučení navrhovatele ničeho změnit. Úřad se však v napadeném rozhodnutí zabývá i dalšími důvody vyloučení navrhovatele, aby veškeré námitky navrhovatele obsažené v návrhu vyčerpávajícím způsobem přezkoumal.

K námitkám navrhovatele ohledně důvodu vyloučení týkajícího se využívání tlustých klientů

102.     Jako další důvod vyloučení navrhovatele zadavatel označil technologické omezení na úrovni frontendu, kdy se navrhovatel chystá nasadit (nebo nedávno nasadil) modernější verzi desktopového řešení, ale pořád založeného na technologii PowerBuilderu. Dále zadavateli nevyhovuje, že navrhovatel nepočítá s vývojem klientů pro mobilní zařízení.

103.     Ze zápisu jednání ze dne 17. 10. 2022 v rámci bodu „Uživatelské rozhraní a podpora různých koncových zařízení“ vyplývá, že zadavatel na začátku vytyčil své požadavky. Zadavatel požaduje podporu více typů zařízení a případnou podporu možnosti zásahu do GUI,a také má záměr postupně se zbavovat tlustého řešení. Úřad správně dospěl k závěru, že v průběhu jednání zadavatel zřetelně uvedl, že nechce, aby se pracovalo v desktop klientovi (viz bod 190 odůvodnění napadeného rozhodnutí) v žádném případě (zvukový záznam z jednání ze dne 17. 10. 2022 cca 47:00).

104.     Navrhovatel v rozkladu tvrdí, že zadavatel v ZD nepožadoval, aby dodavatel disponoval tenkým klientem. Navrhovatel si však mohl vyjasnit tento konkrétní požadavek i v průběhu soutěžního dialogu, přičemž zadavatel tento požadavek nemusel mít přesně specifikovaný v ZD. Tento postup zadavatele není v rozporu s pravidly soutěžního dialogu.

105.     Navrhovatel na jednání dne 17. 10. 2022 uvedl, že „v současné době jsme ještě nikde nenasadili v Power Builderu na tenkém klientovi, ale budou to ty samé úlohy. Postupná inovace na VŠ je snaha mít vše na webu, což umožňuje nová verze Power Builderu 22. Když provozujeme personální portál, tam je GUI uděláno jinak a je směrováno na virtuální platformy. Chápeme potřebu zákazníků funkci spravovat. V tuto chvíli zákazníkům customizujeme sami, tento proces by musel jít ven. Jádro je ale stále stejné. Tuto potřebu víme už dnes a museli bychom to pouze vytáhnout.“ (str. 9 zápisu z jednání). Dále navrhovatel uvedl, že „Tenké rozhraní ještě nikde neběží“ (str. 10 zápisu z jednání). Z výše uvedeného a rovněž z citace uvedené v bodě 191 odůvodnění napadeného rozhodnutí lze usoudit, že navrhovatel nedostačuje požadavkům zadavatele svojí zkušeností s rozhraním v tenkém klientovi, neboť je ve fázi, že ho bude teprve zkoušet. Vývoj migrace na tenké klienty v rámci PowerBuilder zatím nedokončil (viz audiozáznam jednání od času 1:28).  Navrhovatel nedal zadavateli ani žádnou indicii, jak daleko je s tvorbou tenkého klienta. Na dotaz zadavatele „Jak je složité zmigrovat na PowerBuilder v tenkém prostředí? Jak jste na tom dnes po půl roce? Pro představu, jak je to složité.“ (viz zápis z jednání ze dne 17. 10. 2022, str. 10), navrhovatel odpověděl: „Samo o sobě je to automatický proces. Museli jsme tam změnit několik málo míst konstrukce, které byly na pár místech použité. Má to jisté omezení, jisté konstrukce se musí nahradit.“ Zadavatel z takto předložených informací mohl mít důvodné pochybnosti o schopnosti navrhovatele přejít z tlustých klientů na tenké v relativně krátkém čase. Odpověď navrhovatele je nejasná až vyhýbavá. Proto neobstojí tvrzení navrhovatele, že tenkého klienta zařadí do svého řešení a že není důvod se domnívat, že by se nestal součástí řešení ve standardní implementační době 12-24 měsíců. Není totiž jisté, zda a v jakém časovém horizontu se to navrhovateli podaří.

106.     Úřad tak správně dospěl k závěru, že důvod vyloučení týkající se využívání tzv. tlustých klientů a provozování desktopového řešení založeného na technologickém prostředí PowerBuilder byl oprávněným důvodem vyloučení, neboť z jednání v ŘSSD vyplynulo, že navrhovatel ve svém řešení v této věci nyní nenaplňuje požadavky zadavatele a není jisto, zda a kdy je bude schopen naplnit.

107.     Navrhovatel konstatuje, že nikde v ZD není požadavek na klienty pro mobilní zařízení. Přesto Úřad shledal i tento důvod vyloučení jako oprávněný. Jak již bylo výše zmíněno, požadavky zadavatele jsou u části „Uživatelské rozhraní a podpora koncových zařízení“ uvedené na začátku jednání, o čemž se mělo dále diskutovat (viz zápis z jednání ze dne 17. 10. 2022). Zadavatel požadoval podporu více zařízení a případnou podporu možnosti zásahu do GUI. Je zřejmé, že požadavek klientů pro mobilní zařízení nebo tablety (tj. více zařízení) vyplývá z předmětného jednání, přičemž navrhovatel se k danému tématu nijak nevyjádřil. Úřad tak správně konstatoval, že zadavateli nebyla sdělena jednoznačná informace o vývoji funkcionalit systému na webové služby. Lze dovodit, že pokud je navrhovatel pouze v procesu přechodu z tlustých klientů na tenké, tak lze předpokládat, že vývoj klientů pro mobilní zařízení ještě nebyl započat. Proto zadavatel usoudil v rozhodnutí o vyloučení, že „existence klientů pro mobilní zařízení nebo tablety zatím není v plánu (resp. o tom zadavatel neví a nebyla Magionem představena v rámci soutěžního dialogu) ani v podobě speciální aplikace, ani v podobě vývojového prostředí pro programátory.“ Zadavatel ponechává na dodavatelích prezentaci jejich řešení (co nejlepšího mohou v rámci svých schopností a zkušenosti nabídnout), a pokud tito nejsou zcela precizní ve své prezentaci (např. tak, že nezodpoví všechny relevantní otázky), pak tato okolnost nejde k tíži zadavatele, který předem vytyčil body, o kterých se bude v dané oblasti (bod 3 zápisu z jednání ze dne 17. 10. 2022 s názvem „Uživatelské rozhraní a podpora různých koncových zařízení“) jednat.  

K námitkám navrhovatele ohledně důvodu vyloučení pro nedostatečnou zkušenost s provozováním řešení v cloudu

108.     Dalším důvodem vyloučení je nedostatečná zkušenost s provozováním řešení v cloudu.  S tímto navrhovatel nesouhlasí a v rozkladu tvrdí, že není pravdou, že by neměl zkušenosti s provozováním cloudu, což dle jeho názoru dokazuje, že od roku 2017 provozuje cloud pro své potřeby, a od roku 2020 pro Akademii věd ČR a rovněž pro klienta. Navrhovatel je toho názoru, že tímto vyvrátil nové a dříve v rámci jednání neuplatněné tvrzení zadavatele, že řešení navrhovatele nelze převést do cloudu v nejpokročilejším nastavení SaaS. Navrhovatel v rámci jednání ze dne 17. 10. 2022 ani v rozkladu neuvádí žádný způsob, jak by provozoval své řešení v cloudu, pouze uvedl, že má zkušenost s Microsoft Azure, přičemž uvedl, že bude muset o podmínkách využití Azure a serveru jednat s Microsoftem.

109.     Zadavatel se v rámci jednání dne 17. 10. 2022 (viz zápis z jednání z tohoto dne) zeptal navrhovatele k public cloudu, „jak byste provozovali a jestli jste vůbec schopni provozovat a za jakých podmínek? A zda máte zkušenost.“ Na to navrhovatel odpověděl, že „Certifikace data centra nemáme, nemáme data centrum.“ Pokud na otázku, za jakých podmínek by byl schopný public cloud provozovat, navrhovatel odpověděl, že nemá certifikaci ani data centra a ke zkušenosti se vůbec nevyjádřil, lze z tohoto logicky dovodit, že zadavateli neprezentoval dostatečnou zkušenost s provozováním svého řešení v cloudu, což je právě důvod obsažený v rozhodnutí o vyloučení. Není tedy pravdou, že by tato skutečnost jakkoliv nesouvisela s důvody zadavatele formulovanými v rozhodnutí o vyloučení. Propojení certifikací datového centra s požadavkem na cloudové řešení tak lze shledat i z této reakce navrhovatele. Námitka navrhovatele, že Úřad k tomuto neměl přihlížet, tak není důvodná. Pokud si zadavatel v průběhu jednání vydefinoval, že chce public cloud, je to jeho potřeba, kterou by měli úspěšní dodavatelé splňovat. Její nesplnění je důvodem pro závěr o nevhodnosti řešení.

110.     Dále navrhovatel poté, co zadavatel uvedl své představy o cloudovém řešení (viz zápis z jednání ze dne 17. 10. 2022), reagoval tak, že bude „muset jednat s Microsoftem o podmínkách využití Azuru a serveru. Byli jsme zvyklí na menší databáze.“ (str. 12 zápisu z jednání). Z jednání v soutěžním dialogu tak plyne, že navrhovatel provozoval řešení pouze prostřednictvím cloudové platformy třetí strany (tj. Microsoftu). Tedy i z této citace lze vyvodit, že zkušenost s provozováním svého řešení v cloudu nemá zadavatel v rámci jednání nijak podloženou. 

111.     Z průběhu jednání je zřejmé, že zadavatel má určitou představu, proč chce přejít na cloudové řešení. Na jednání dne 17. 10. 2022 zadavatel uvedl: „Z diskusí vnímáme, že řada firem v cloudu nabízí věci, které v on site nenabízí. Narážíme na to, že některé kompetence potřebné pro on site řešení začínají být pro nás drahé. Je pro nás jednodušší, aby nám někdo garantoval cloudové řešení. Pro MU začíná být cloud řešení velmi zajímavé jako klasické enterprise řešení přesto, že univerzita byla dlouho zaměřená na onsite řešení. Doba se mění, nemusíme mít takové vlastní kapacity a dodavatel přebírá odpovědnost za případné výpadky. Po téměř ročním dialogu vnímáme, že naše předpoklady kolem on site přestávají být validní i finančně i s ohledem na neviditelné náklady“ (viz zápis z jednání ze dne 17. 10. 2022, str. 12). Tento požadavek zadavatele je logický, jasně formulovaný a zřetelně zazněl na předmětném jednání. Zadavatel v rozhodnutí o vyloučení netvrdil, že navrhovatel nemá žádnou zkušenost s provozováním řešení v cloudu, ale tato zkušenost není pro zadavatele dostatečná.

112.     V bodech 4.26 a 4.27 rozkladu navrhovatel argumentuje, že vyvrátil důvody zadavatele stran cloudového řešení v rozhodnutí o vyloučení. Při pohledu na námitky navrhovatele a na jeho návrh však není jasné, čím konkrétně by toto důvody měly být vyvráceny. V bodě 2.49 námitek navrhovatel uvádí konkrétní zkušenost s provozováním cloudu, není však jasné, z jakého důvodu by ji měl zadavatel považovat za dostatečnou. V rozhodnutí o námitkách proti tomu zadavatel postavil konkrétní technické argumenty, pro které je zkušenost navrhovatele pro něho nedostatečnou. V relevantním bodu 2.37 návrhu na to navrhovatel reagoval opět pouze obecným způsobem a argumentaci zadavatele konkrétními technickými argumenty nevyvracel.

K námitkám ohledně vyloučení z důvodu chybějící integrační platformy ESB

113.     Zadavatel jako další důvod nevhodného řešení uvedl, že „řešení navrhovatele nenabízí integrační platformu (ESB – enterprise service bus) alespoň se základními funkcemi (asynchronní zpracování zpráv, konektory na externí systémy, monitoring služeb a error handling), která by umožnila jednoduchou integraci řešení Magionu s řešením Masarykovy univerzity a s řadou dalších systémů, které v IT ekosystému MU provozuje. Neexistence této platformy by též omezila možnosti prodeje Masarykovou univerzitou vyvinutého řešení a jeho integrace do IT prostředí jiných VVŠ.“

114.     Úřad správně dospěl k závěru, že jelikož zadavatel předem definoval svou potřebou v rámci zadávací dokumentace, tj. aby dodavatelé v rámci řešení navrhli způsob integrace s externími systémy, byl oprávněn požadovat, aby řešení navrhovatele toto obsáhlo. Daný požadavek na integrační platformu, jak je z výše uvedené citace zadavatele z rozhodnutí o vyloučení zřejmé – a ostatně to vyplývá i z jednání dne 17. 10. 2022 (zvukový záznam od času 1:00:30) – je pro zadavatele zásadní, neboť přímo zasahuje do klíčového požadavku, tj. otevřenosti systému.

115.     Námitce navrhovatele týkající se netransparentnosti postupu zadavatele spočívající v tom, že na jednání zadavatel výslovně deklaroval, že absence ESB nebude vylučovací důvod, ale následně svůj postoj změnil, lze do jisté míry přisvědčit. Z průběhu jednání dne 17. 10. 2022 totiž nelze učinit jasný závěr o tom, zda zadavatel požadavek na integrační platformu, jakožto budoucí hodnoticí kritérium, bude považovat za důvod vyloučení, či nikoliv. Na předmětném jednání totiž zaznělo, že „u integrační platformy jsme brali, že to není vylučovací ve smyslu, že kdo ji nemá, tak vypadává, ale je to jedno ze zásadních kritérií pro školení lidí a předimplementační fáze,“ (zápis z jednání ze dne 17. 10. 2022, str. 8). Tedypokud zadavatel na jednání věc prezentoval tak, že nebude dodavatele vylučovat z důvodu chybějící integrační platformy, pak mohl navrhovatel důvodně očekávat, že absence integrační platformy v jeho řešení skutečně nebude mít za následek vyloučení ze zadávacího řízení, ať už by šlo o vyloučení pro nesplnění zadávacích podmínek později podanou nabídkou [§ 48 odst. 2 písm. a) zákona] nebo vyloučení dodavatele s nevhodným řešením dle § 69 odst. 5 zákona. Z napadeného rozhodnutí není zjevné, jestli mohlo být navrhovateli v průběhu soutěžního dialogu jasné, jaký následek bude mít, že jeho řešení neobsahuje integrační platformu, aby mohl svému případnému vyloučení ze zadávacího řízení včas předejít a přesvědčit zadavatele o vhodnosti svého řešení. Navrhovatel přitom problematiku hodnoticího a eliminačního kritéria alespoň v základních rysech zmiňuje v bodě 2.39 návrhu, byť ji dále ve své právní argumentaci (bod 2.41 návrhu) nerozvíjí.   

116.     Na základě napadeného rozhodnutí nelze při zohlednění námitek rozkladu bez dalších pochybností uzavřít, že zadavatel předem jasně definoval svoji potřebu, aby nabízené řešení mělo integrační platformu určitých vlastností, a že navrhovateli mohlo být jasné, že následkem nesplnění takového požadavku bude závěr o nevhodnosti řešení ve smyslu § 69 odst. 5 zákona. Tato otázka by vyžadovala podrobnějšího posouzení. Dále lze konstatovat, že za účelem vyřešení zbývajících námitek rozkladu týkajících se problematiky integrační platformy by bylo třeba obsáhlejšího posouzení otázek, jakou integrační platformu zadavatel požadoval a jestli byl navrhovatel schopen jeho požadavkům vyhovět. Nicméně s ohledem na to, že ostatní výše pojednané důvody vyloučení navrhovatele byly shledány opodstatněnými, není toho s ohledem na zásadu procesní ekonomie třeba. Rozhodnutí o vyloučení navrhovatele ze ŘSSD obstojí, i pokud je oprávněným byť jen jeden jediný důvod jeho vyloučení. A taková situace ve zdejší věci dána je. K tomu lze odkázat na předchozí části odůvodnění tohoto rozhodnutí o rozkladu.

K okruhu námitek týkajících se funkce pro automatizaci digitalizace a individualizace agend

117.     Navrhovatel je toho názoru, že Úřad nesprávně vyvozuje závěry z citací textů, ve kterých dle navrhovatele nejsou tyto závěry explicitně uvedeny. K tomu lze uvést, že potřeba zadavatele v rámci ŘSSD nemusí být v ZD explicitně a výslovně vyjádřena, postačí, když je zřejmé, co zadavatel požadoval. Zadavatel ve zdejším případě požadoval zvláštní funkcionality, které v rozhodnutí o vyloučení označil jako „specifické funkce pro automatizaci digitalizace a individualizaci agend“ a příkladem je v rozhodnutí o vyloučení také vyjmenoval. Pokud navrhovatel namítá proti napadenému rozhodnutí v této části, že Úřadem uváděné citace ZD neobsahují slova „automatizace“ a „individualizace“, a z toho vyvozuje jeho nepřezkoumatelnost, pak je třeba říci, že Úřad hodnotil smysl a účel uvedených citací ze zadávací dokumentace, a to i ve světle toho, co zaznělo v průběhu jednání v soutěžním dialogu. To je zcela přípustné a nečiní to bod 197 napadeného rozhodnutí nepřezkoumatelným, neboť je patrné, z čeho Úřad vycházel. Navíc jde o námitku zcela formálně vznesenou. Navrhovatel ani v návrhu, ani v rozkladu nerozporuje, že zadavatel měl určité požadavky stran automatizace digitalizace a individualizace agend. Ostatně, určitý způsob, jak své řešení v tomto směru přizpůsobit požadavkům zadavatele, i navrhoval. Předmětem sporu je to, zda navrhovatel požadavkům zadavatele vyhověl.

118.     Úřad v odůvodnění napadeného rozhodnutí označil místa, kde zadavatel vyjádřil tuto potřebu jak v ZD, tak i na jednání dne 17. 10. 2022. Přitom vedle toho, co Úřad uvedl v odůvodnění napadeného rozhodnutí, lze požadavek na automatizaci vyvodit i ze zápisu z jednání ze dne 17. 10. 2022 v bodě 4 pod názvem „(Uživatelská) Automatizace procesů“. Zadavatel v této části jednání nejprve přednesl body, o kterých se bude jednat, jako např. dostupnost nástroje, skriptovacího jazyka nebo platformy pro tvorbu automatizovaných scénářů nebo dokonce jednoduchých aplikací samotnými uživateli. Následně dále v rámci jednání uvedl své požadavky, přičemž vysloveně uvedl, že je pro něho podpora automatizace důležitá a chce vytvářet aplikace bez nutnosti programování.   

119.     Požadavek na automatizaci procesů, jak správně Úřad uvedl, byl předmětem soutěžního dialogu (viz zápis z jednání dne 17. 10. 2022). I zde Úřad správně vyhodnotil, že zadavatel předem v ZD definoval svou potřebu, přičemž navrhovatel v rámci jednání neprezentoval, jaké funkce by nabídl pro automatizaci digitalizace a individualizaci agend. Navrhovatel na jednání uvedl pouze produkt Power Automate Microsoft, který umožňuje vytvářet skripty nebo procesy, které jsou schopné víceméně ovládat obrazovku. To však evidentně zadavateli nestačilo, pokud se v odůvodnění rozhodnutí o vyloučení vyjádřil, že navrhovatel nenabídl „další specifické funkce“, které zadavatel i vyjmenoval (skriptování, uživatelský reporting, chatboti apod.).

120.     V námitkách se navrhovatel věnuje opět pouze nástroji Power Automate Microsoft. Zadavatel v rozhodnutí o námitkách uvedl, že „řešení vytvořené týmem ZČU, které využívá technologii MS Power Automate a tohle nepovažujeme za zkušenost Stěžovatele (čas 1:39:40 záznamu). K žádné další zkušenosti v oblasti automatizace se Stěžovatel nevyjádřil.“ Lze uvést, že Úřad v tomto ohledu nesupluje názor zadavatele. Zadavatel je ten, kdo určuje, co je po něho dostačující, proto neobstojí tvrzení navrhovatele, že by Úřad zpochybňoval, že tato funkcionalita nepostačuje. Zadavatel zjevně v rámci posouzení vhodnosti řešení posuzoval i zkušenosti navrhovatele, což je za určitých okolností možné, jak je popsáno níže.

121.     V návrhu se navrhovatel v této části věnuje pouze obecné argumentaci a rovněž kromě nástroje Power Automate Microsoft nezmiňuje další funkcionality. Navrhovatel v rozkladu tvrdí, že tyto další specifické funkce dle požadavků zadavatele nabídl (body 4.49, 4.50 rozkladu), avšak již neuvedl konkrétně které (kromě nástroje Power Automate Microsoft), a to ani v průběhu správního řízení, ani v průběhu soutěžního dialogu. Úřad tak ani nemohl prozkoumat, zda jsou obsahem řešení navrhovatele.

122.     Navrhovatel v rozkladu tvrdí, že určité funkcionality nabídne do budoucna v rámci nově zpracovaného řešení. Tato námitka navazuje na tezi, kterou navrhovatel uvádí opakovaně ve správním řízení, a sice že zadavatel by neměl posuzovat vhodnost řešení dle zkušeností dodavatele, ale pouze dle vlastností navrhovaného řešení. Taková teze je ale lichá. I dosavadní zkušenosti dodavatele vypovídají mnoho o tom, co je schopen reálně nabídnout jako budoucí řešení. Pojmově tedy není vyloučeno, aby zkušenosti dodavatele zadavatel v rámci otázky vhodnosti řešení posuzoval, pokud takové úvahy povedou logicky k závěrům o tom, jaké plnění nebo např. v jaké době je dodavatel je schopen poskytnout.

123.     Příslib, že navrhovatel poskytne plnění určité kvality, je pro zdejšího zadavatele v rámci jednání nepodstatný, neboť zadavatel považoval s ohledem na složitost poptávaného plnění za vhodné ověřit si právě ony zkušenosti dodavatelů – tedy co mohou nabídnout již dnes a jaké mají zkušenosti – aby si mohl utvořit představu, jak reálné jsou jeho představy o budoucím plnění a následně tyto představy přetavit do zadávacích podmínek.

K námitkám nepřezkoumatelnosti

124.     Na tomto místě je třeba se vyjádřit k početným námitkám navrhovatele ohledně nepřezkoumatelnosti napadeného rozhodnutí. Navrhovatel v některých argumentačních okruzích uvedl, že se Úřad nevyjádřil k určité jednotlivé námitce, a proto považuje napadené rozhodnutí za nepřezkoumatelné.

125.     K nepřezkoumatelnosti se vyjádřil Nejvyšší právní soud v rozsudku č. j.  3 As 366/2019 – 43 ze dne 10. 12. 2021, kde uvedl, že „za nepřezkoumatelné (pro nedostatek důvodů) lze označit zejména takové rozhodnutí, v němž soud zcela opomene vypořádat některou z uplatněných žalobních námitek (…), respektive pokud z jeho odůvodnění není zřejmé, proč soud nepovažoval za důvodnou právní argumentaci účastníka řízení v žalobě a proč žalobní námitky účastníka považuje za liché, mylné nebo vyvrácené, a to zejména tehdy, jde-li o právní argumentaci, na níž je postaven základ žaloby (viz rozsudek tohoto soudu ze dne 14. 7. 2005, č. j. 2 Afs 24/2005 - 44). (…) Dále je třeba připomenout, že povinností soudu není výslovně reagovat na každé žalobní tvrzení, postaví-li soud své závěry na ucelené argumentaci, která věcně pokryje všechny argumentační pozice žaloby (…).“ Po přezkoumání napadeného rozhodnutí lze dospět k závěru, že Úřad výše uvedená kritéria přezkoumatelnosti napadené rozhodnutí splňuje.

126.     Úřad vycházel jen ze skutečností, které zazněly v průběhu jednání, přičemž navrhovateli se nepodařilo svou argumentací v průběhu správního řízení vyvrátit tvrzení zadavatele, že by jeho řešení splňovalo potřeby zadavatele, které zadavatel v rámci ŘSSD definoval. Tedy nelze v daném případě shledat důvody pro uložení nápravného opatření.

VI.          Závěr

127.     Po zvážení všech aspektů dané věci a po zjištění, že Úřad postupoval v posuzovaném případě v souladu s relevantními právními předpisy, dospěl předseda Úřadu k závěru, že nastaly podmínky pro potvrzení napadeného rozhodnutí, a to z důvodů výše uvedených.

Poučení

Proti tomuto rozhodnutí se podle § 91 odst. 1 zákona č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů ve spojení s § 152 odst. 5 téhož zákona nelze dále odvolat.

 

 

otisk úředního razítka

 

 

 

 

 

 

 

doc. JUDr. PhDr. Petr Mlsna, Ph.D.

předseda Úřadu pro ochranu hospodářské soutěže

 

 

 

 

Obdrží

Mgr. Marek Šimka, Moravské náměstí 754/13, 602 00 Brno

Masarykova univerzita, Žerotínovo náměstí 617/9, 602 00 Brno

 

Vypraveno dne

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