{"html": "<div class=\"doc\"><p>Z parametrů greenlistu (zejména celkový objem dat, struktura dat databáze, způsob práce s databází) dále plynou požadavky na odbavovací zařízení:</p><p>-          požadavky na výpočetní výkon HW odbavovacího zařízení (zda stovky MB nebo jednotky GB v případě fotografie),</p><p>-          požadavky na velikost a rychlost datového úložiště,</p><p>-          zabezpečení dat (šifrování, fyzické znepřístupnění datového úložiště, ochrana komunikačních portů zařízení atd.).</p><p>Na základě výše uvedených skutečností zejména četnost zasílání zpráv, celkový objem přenášených dat, celkových objem dat databáze, struktura dat databáze a s ní související datová struktura greenlistu a popis datové komunikace budou mít vliv na úpravy odbavovacích zařízení a centrální část OS (BackOffice).“</p><p>V bodě 2.4 znaleckého posudku nazvaném „Stanovisko posuzovatele“ uvedl znalec jako odpověď na otázku č. 1 část 2 následující: „Poskytnuté informace dostatečné nejsou. Seznam parametrů a informací, které mají být součástí zadávací dokumentace, je obsahem kapitoly 2.3.2.“</p><p>V bodě 2.3.2 znaleckého posudku uvedl znalec mimo jiné toto:</p><p>„Informace a parametry, které by měly být uvedeny v zadávací dokumentaci, jsou uvedeny v předcházející kapitole. Odkazy na relevantní informace uvedené v zadávací dokumentaci jsou obsahem kapitoly 2.2.1. Na základě porovnání informací v obou výše uvedených kapitolách lze dospět k seznamu informací, které nejsou v zadávací dokumentaci uvedeny. Jedná se o níže uvedené informace a parametry.</p><p>Algoritmus výpočtu tokenu</p><p>Skutečností je, že ani tokenizační algoritmus ani tokenizační klíče nebyly v zadávací dokumentaci popsány, což bylo zdůvodněno bezpečnostními hledisky (viz [5] na str. 4, dotaz č. 11). Ke zdůvodnění objednatele k neposkytnutí tokenizačního algoritmu, kde objednavatel zdůvodňuje neposkytnutí algoritmu bezpečností odbavovacího systému, lze říct následující: bezpečnost odbavovacího systému tak, jak jsou chápány použité bezpečnostní nástroje (hašovací funkce, tokenizační klíč), by měla být zajištěna prostřednictvím utajení tokenizačního klíče nebo klíčů. Vzhledem ke skutečnosti, že použití nestandardního algoritmu se z důvodu následné špatné HW kompatibility nepředpokládá, není důvod neposkytnout odkaz na jeden nebo více standardizovaných algoritmů, ze kterých jeden bude v odbavovacím systému použit [55].</p><p>K poskytnutí tokenizačního klíče nebo klíčů v rámci zadávací dokumentace: jak bylo uvedeno výše, není možné zveřejnit tzv. ostré klíče, protože na jejich utajení je založena bezpečnost odbavovacího systému, bylo by to zásadní narušení jeho bezpečnosti. Vzhledem k potřebě znalosti parametrů tokenizačního klíče pro stanovení odhadu náročnosti implementace tokenizace do HW dodavatele odbavovacího systému (a to i v případě zajištění dodávky tohoto HW externím dodavatelem) lze tuto potřebu řešit poskytnutím tzv. testovacích klíčů (klíče stejných parametrů obsahujících však jiné hodnoty) [55].</p><p>V případě využití tzv. SAM modulu v oblasti bezpečnosti odbavovacího systému (tato skutečnost však není ze zadávací dokumentace zřejmá), nemusí dodavatel znát ani tokenizační algoritmus, ani klíče. Objednatel však musí poskytnout specifikaci SAM modulu a dokumentaci ke komunikačnímu rozhraní (API), aby dodavatel mohl posoudit složitost a t ím i časovou a finanční náročnost implementace SAM modulu do svého odbavovacího zařízení z hlediska HW a SW.</p><p>Greenlist</p><p>Kromě vybraného formátu greenlistu (XML viz [5]) musí specifikace greenlistu obsahovat:</p><p>-          Popis variant/verzí greenlistu (pokud existují).</p><p>-          Popis datové struktury nebo struktur greenlistu.</p><p>-          Popis komunikace mezi koncovými body systému.</p><p>Specifikace greenlistu musí obsahovat také kvalitativní a kvantitativní parametry související s distribucí greenlistu:</p><p>-          časové limity, do kdy musí být informace distribuovány z BackOffice do koncových zařízení a naopak,</p><p>-          celková (odhadovaná, maximální) velikost zasílaného greenlistu, velikost jeho inkrementálních částí.</p><p>Další informace:</p><p>-          popis (směry) datových toků a způsob distribuce greenlistu mezi jednotlivými prvky (subjekty) systému (odbavovací zařízení dopravce, BackOffice dopravce, BackOffice koordinátora),</p><p>-          popis nebo schéma procesů (odbavení, reklamace), ze kterého je zřejmé, jak se nakládá s informacemi obsaženými v greenlistu pro reálné situace, které mohou v systému nastat.</p><p>Skutečností je, že žádné z výše uvedených informací nebyly v zadávací dokumentaci uvedeny. Informace uvedené v dokumentu [49] jsou marginální. Zadávací dokumentace v zásadě pouze obsahuje informaci (viz [5], str. 4, odpověď zadavatele na dotaz č. 11), že „ se jedná o běžný formát souboru, který se používá i v jiných odbavovacích systémech.&quot; Tato informace spolu s informací o formátu souboru greenlistu „xml&quot; pro kladné zodpovězení otázek uvedených v zadání dostatečná není.“</p><p>163.     V bodě 3. znaleckého posudku se znalec věnoval problematice komunikace s dispečerskou aplikací, konkrétně v této části znaleckého posudku odpovídal na následující otázky Úřadu:</p><p>„Jaký okruh a rozsah informací musí objednatel, který požaduje dodání odbavovacího systému pro použití při zajištění dopravní obslužnosti v přepravě cestujících veřejnou linkovou dopravou (prováděnou autobusy) uvést v souvislosti s požadavkem na funkcionalitu – komunikace s dispečerskou aplikací – tak, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu komunikace s dispečerskou aplikací zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují?“ (dále také „otázka č. 2 část 1“)</p><p>„Jsou informace o funkcionalitě – komunikace s dispečerskou aplikací – poskytnuté zadavatelem v zadávací dokumentaci na veřejnou zakázku „Zajištění dopravní obslužnosti Olomouckého kraje veřejnými službami v přepravě cestujících veřejnou linkovou dopravou – oblast Jesenicko“ (vše je přílohou této žádosti), dostatečné pro to, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu komunikace s dispečerskou aplikací zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují? Znalci se ukládá své odpovědi odůvodnit.“ (dále také „otázka č. 2 část 2“)</p><p>V bodě 3.4 znaleckého posudku nazvaném „Stanovisko posuzovatele“ uvedl znalec jako odpověď na otázku č. 2 část 1 následující:</p><p>„Objednavatel musí uvést:</p><p>kompletní dokumentaci, či odkaz na standard, popisující požadované funkcionality odbavovacího systému vzhledem k dispečerské aplikaci</p><p>kompletní dokumentaci, či odkaz na standard, popisující komunikaci odbavovacího systému s dispečerskou aplikací.</p><p>Podrobnosti o požadavcích jsou uvedeny v kapitole 3.3.“</p><p>V bodě 3.3.1 znaleckého posudku uvedl znalec mimo jiné toto:</p><p>„Aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení funkcionality - komunikace s dispečerskou aplikací, tedy vytvoření a dodání odbavovacího systému schopného funkcionality komunikace s dispečerskou aplikací zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují, musejí obdržet tyto informace:</p><p>kompletní dokumentaci, či odkaz na standard, popisující požadované funkcionality odbavovacího systému vzhledem k dispečerské aplikaci, což souvisí se:</p><p>o      zasíláním dat z palubního počítače,</p><p>o      příjmem a zpracováním dat z dispečerské aplikace,</p><p>kompletní dokumentaci, či odkaz na standard, popisující komunikaci odbavovacího systému s dispečerskou aplikací:</p><p>o      popis komunikačního protokolu - u standardních protokolů stačí název,</p><p>o      popis zabezpečení komunikace,</p><p>o      popis datového formátu zasílaných zpráv včetně přesného popisu údajů s uvedením oboru hodnot, které se ve zprávách posílají, aby dodavatel odbavovacího systému byl schopen určit, zda odbavovací zařízení disponuje periferiemi pro získání požadovaných údajů, či je musí doplnit (např. souřadnice polohy s danou přesností a četností poskytování),</p><p>o      použité kódování diakritiky,</p><p>o      popis druhu zpráv (požadavek - odpověď),</p><p>o      popis událostí aktivujících komunikaci.</p><p>Na základě těchto údajů dodavatelé odbavovacích systémů mohou ověřit, zda jejich zařízení disponuje požadovanou funkcionalitou. Pokud dojdou k závěru, že jejich zařízení nedisponuje požadovanou funkcionalitou, poskytnuté informace jim poslouží ke stanovení rozsahu činností, časové náročnosti a nákladech na doplnění požadované funkcionality. Činnosti mohou souviset jak s úpravou software, tak i hardware, kdy je nutné provést - analýzu požadavků, návrh řešení, vývoj, implementaci a testování, které probíhá nejenom po implementaci, ale i během vývoje.</p><p>Jako příklad dokumentace, která je pro účely veřejné zakázky dostatečná, je možné uvést dokument Centrální dispečink Zlínského kraje - Příloha č. 8 Smlouvy o přistoupení k IDS ZK, viz [63].“</p><p>V bodě 3.4 znaleckého posudku nazvaném „Stanovisko posuzovatele“ uvedl znalec jako odpověď na otázku č. 2 část 2 následující:</p><p>„Poskytnuté informace nejsou dostatečné, zcela chybí popis zabezpečení komunikace; popis datového formátu zasílaných zpráv včetně přesného popisu údajů s uvedením oboru hodnot, které se ve zprávách posílají; použité kódování diakritiky; popis druhu zpráv (požadavek - odpověď); jasná specifikace událostí aktivující komunikaci. Rozbor poskytnutých informací je v kapitole 3.3.“</p><p>V bodě 3.3.2 znaleckého posudku uvedl znalec mimo jiné toto:</p><p>„Informace ohledně požadavků na odbavovací zařízení v souvislosti s dispečerskou aplikací, které byly součástí Zadávací dokumentace předmětné Veřejné zakázky, byly obsaženy v Příloze č. 2 (soubor Príloha_č_2_Technické_a_provozní_standardy_25_7_2016.pdf [13]). Požadavek na odbavovací zařízení je uveden velmi vágně, formulace požadavku &quot;komunikace s dispečerskou aplikací (krajskou a vlastní)&quot; je opravdu velmi obecná. V kapitole 6 téhož dokumentu jsou informace již konkrétnější, nicméně stále velmi vágní, některé dokonce zcela nesmyslné (&quot;Komunikační jednotky musí být zároveň vybaveny SIM kartou pro zachování možnosti ukládání dat při dočasné ztrátě signálu.&quot; - patrně byla myšlena „SD karta&quot; místo „SIM karta&quot;), a hlavně stále vykazující vysoký stupeň neurčitosti.</p><p>Až v odpovědi k dotazu č. 23 (soubor Dodatečné Jnformace_sada_č_4.pdf (Sj) je obsažena část potřebných informací, nicméně se rozšiřuje množina požadovaných odesílaných údajů. Poslední odstavec odpovědi &quot;Konkrétní technická specifikace komunikace závisí na výrobci konkrétního odbavovacího systému. Předpokládá se, že při dodržení výše uvedených minimálních parametrů bude aplikační rozhraní upraveno na straně dispečerského systému v rámci jeho implementace.&quot; vzbuzuje dojem, že dispečerská aplikace se podřídí řešení odbavovacího zařízení, což sice odstraňuje velkou nejistotu, ale je to v ostrém rozporu se závazkem v dokumentu Příloha č. 6 - Závazný text smlouvy o plnění předmětu veřejné zakázky [23], kde je jasně určena povinnost dopravce &quot;... zajistit bezproblémový proces vzájemné komunikace používaných vozidel s centrálním dispečinkem Objednatele ...&quot;. Rozhodně nejsou definovány všechny požadavky na funkcionalitu odbavovacího systému a detailně popsána veškerá komunikace s dispečerskou aplikací.</p><p>Možným vysvětlením nedostatků a neurčitostí v Příloze č. 2 - Technické a provozní standardy (viz [13]) je fakt, že na dodávku systému centrálního dispečinku Koordinátora Integrovaného dopravního systému Olomouckého kraje byla smlouva podepsána s firmou T-MAPY spol s.r.o. až dne 14.12.2016 (viz [60]) a dispečink IDSOK byl předán až dne 30.6.2017 (viz [58] a [59]).“</p><p>164.     V bodě 4. znaleckého posudku se znalec věnoval problematice zajištění komunikace se systémem e-shopu KIDSOK, konkrétně v této části znaleckého posudku odpovídal na následující otázky Úřadu:</p><p>„Jaký okruh a rozsah informací musí objednatel, který požaduje dodání odbavovacího systému pro použití při zajištění dopravní obslužnosti v přepravě cestujících veřejnou linkovou dopravou (prováděnou autobusy) uvést v souvislosti s požadavkem na funkcionalitu – zajištění komunikace se systémem e-shopu KIDSOK – tak, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu komunikace se systémem e-shopu KIDSOK zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují?“ (dále také „otázka č. 3 část 1“)</p><p>„Jsou technické požadavky týkající se popisu aplikačního rozhraní pro komunikaci se systémem e-shopu KIDSOK poskytnuté zadavatelem v zadávací dokumentaci na veřejnou zakázku „Zajištění dopravní obslužnosti Olomouckého kraje veřejnými službami v přepravě cestujících veřejnou linkovou dopravou – oblast Jesenicko“ (vše je přílohou této žádosti), dostatečné pro to, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu komunikace se systémem e-shopu KIDSOK zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují? Znalci se ukládá své odpovědi odůvodnit.“ (dále také „otázka č. 3 část 2“)</p><p>V bodě 4.4 znaleckého posudku nazvaném „Stanovisko posuzovatele“ uvedl znalec jako odpověď na otázku č. 3 část 1 následující: „Požadovaný rozsah informací je specifikovaný v kap. 4.3.1.“</p><p>V bodě 4.3.1 znaleckého posudku uvedl znalec mimo jiné toto:</p><p>„Rozsah a detail dokumentace nezbytné jako podklady pro realizaci e-Shopu je závislá na složitosti celkového řešení a na tom, zda se jedná o zcela nové řešení nebo napojení na stávající řešení. Vzhledem k tomu, že se jedná o posudek zadávací dokumentace řešení, které bude napojeno na stávající řešení Systému EMV karet v osobní dopravě KIDSOK, musí být kladen velký důraz na detailní specifikace, které musí obsahovat následující minimální okruh informací:</p><p>-          Způsob napojení e-Shopu na clearingový systém.</p><p>-          Způsob využití Greenlistu, Blacklistu a případně Whitelistu v logice e-Shopu,</p><p>-          Způsob napojení transakčních systémů dopravců na e-Shop,</p><p>-          Způsob napojení systému bezkontaktních/kontaktních karet na e-Shop,</p><p>-          Rozsah funkcí e-Shopu a rozsah využití pro dopravce.</p><p>-          Zda bude nezbytné pořízení HW, SW a služeb ve vztahu k řešení e-Shopu IDSOK.</p><p>V návaznosti na výše uvedené okruhy požadovaných informací a vzhledem k tomu, že je povinnost dopravce využívat e-Shop BackOffice IDSOK, lze shrnout nedostatky do následujících oblastí, které byly vyhodnoceny posuzovatelem, že nejsou dostatečně nebo vůbec specifikovány:</p><p>-          způsob napojení e-Shopu na clearingový systém ve vztahu na zde realizované transakce (nákup kupónů, časových jízdenek apod.). Logika napojení komponent je nezbytná pro definování dodávaných komponent a souvisí s případnou nutností dodání této komponenty dopravcem pro fungování celého řešení ve vztahu k dopravci,</p><p>-          způsob využití nebo provázání Greenlistu, Blacklistu a případné Whitelistu v logice e-Shopu, který je nezbytný pro definování intervalů a komunikačních kanálů pro odbavovací systémy nebo komponenty dopravce,</p><p>-          způsob napojení transakčních systémů dopravců (odbavovací systémy, kontaktní místa apod.) na e-Shop, které může znamenat nutnost dodání takovéhoto řešení přímo dopravcem,</p><p>-          způsob napojení systému bezkontaktních/kontaktních karet (včetně databáze) na e-Shop. Logika napojení karet může znamenat nutnost dodání takovéhoto řešení přímo dopravcem,</p><p>-          jaký je rozsah funkcí e-Shopu, kdy nelze kvalifikovaně odhadnout možnosti a způsoby jejich využití pro řízení ekonomických ukazatelů dopravce a efektivitu dopravních služeb, tj. zda nebude ze strany dopravce potřeba zajistit některé funkce zakoupením nebo vývojem vlastního SW,</p><p>-          zda bude nezbytné pořízení k výše uvedeným oblastem:</p><p>HW, síťových komponent a souvisejících periférií,</p><p>SW od zadavatele formou služby nebo pořízení,</p><p>vývoj vlastního SW dopravce,</p><p>které jsou nezbytné pro návrh dodávaného řešení ve vztahu na komponenty, služby a další dodávky.“</p><p>V bodě 4.4 znaleckého posudku nazvaném „Stanovisko posuzovatele“ uvedl znalec jako odpověď na otázku č. 3 část 2 následující:</p><p>„Poskytnutý rozsah informací byl na základě dostupných informací nedostatečný, jak je uvedeno v kap. 4.3.2, a proto si dodavatelé odbavovacích systémů nemohli učinit reálnou představu o činnostech nutných k zabezpečení této funkcionality, ani ověřit, zda takovýmto systémem disponují.“</p><p>V bodě 4.3.2 znaleckého posudku uvedl znalec mimo jiné toto:</p><p>„Na základě výše uvedených informací shrnutých v nálezové části a uvedeného výčtu nedostatků e-Shopu specifikovaných v posudkové části je zřejmé, že předložená zadávací dokumentace spolu s upřesněnými údaji uvedenými v doplňujících informacích a jejich přílohách jsou nedostatečné pro zpracování nabídky a dodání zcela funkčního řešení.</p><p>Informace nebyly dostatečné, proto dodavatelé nemohli získat reálnou představu o detailních informacích o celkovém fungování, rozsahu využití a způsobu napojení na e-Shop, a to i vzhledem k závazku dopravce využívat e-Shop BackOffice IDSOK.</p><p>Z posouzení dostupných informací (objednávka KIDSOK 1951/2017 ze dne 11.12.2017) [65] vyplývá, že KIDSOK v době zadávacího řízení nedisponoval takovým e-shopem, který je součástí navrhovaného řešení a nebylo ani známé budoucí řešení (dodání připravených podkladů bylo stanoveno na 20. 12. 2016) [66].“</p><p>165.     V bodě 5. znaleckého posudku se znalec věnoval problematice integrace požadovaného systému odbavení (clearing), konkrétně v této části znaleckého posudku odpovídal na následující otázky Úřadu:</p><p>„Jaký okruh a rozsah informací musí objednatel, který požaduje dodání odbavovacího systému pro použití při zajištění dopravní obslužnosti v přepravě cestujících veřejnou linkovou dopravou (prováděnou autobusy) uvést v souvislosti s požadavkem na integraci požadovaného systému odbavení (tj. požadavek na clearing tržeb, datové a aplikační rozhraní clearingu, na provozovatele clearingu, dispečinku) – tak, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu integrace požadovaného systému odbavení (tj. požadavek na clearing tržeb, datové a aplikační rozhraní clearingu, na provozovatele clearingu, dispečinku) zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují?“ (dále také „otázka č. 4 část 1“)</p><p>„Jsou informace o dalších službách potřebných pro integraci požadovaného systému odbavení (tj. požadavek na clearing tržeb, datové a aplikační rozhraní clearingu, na provozovatele clearingu, dispečinku) poskytnuté zadavatelem v zadávací dokumentaci na veřejnou zakázku „Zajištění dopravní obslužnosti Olomouckého kraje veřejnými službami v přepravě cestujících veřejnou linkovou dopravou – oblast Jesenicko“ (vše je přílohou této žádosti), dostatečné pro to, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu integrace požadovaného systému odbavení (tj. požadavek na clearing tržeb, datové a aplikační rozhraní clearingu, na provozovatele clearingu, dispečinku) zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují? Znalci se ukládá své odpovědi odůvodnit.“ (dále také „otázka č. 4 část 2“)</p><p>V bodě 5.4 znaleckého posudku nazvaném „Stanovisko posuzovatele“ uvedl znalec jako odpověď na otázku č. 4 část 1 následující: „Požadovaný rozsah informací je specifikovaný v kap. 5.3.1.“</p><p>V bodě 5.3.1 znaleckého posudku uvedl znalec mimo jiné toto:</p><p>„Rozsah a detaily dokumentace nezbytné jako podklad pro clearingový systém jsou závislé na složitosti celkového řešení a na tom, zda se jedná o zcela nové řešení nebo napojení na stávající řešení. Vzhledem k tomu, že se jedná o posudek zadávací dokumentace řešení, které bude napojeno na stávající řešení Systému EMV karet v osobní dopravě KIDSOK, musí být kladen velký důraz na detailní specifikace, které musí obsahovat následující minimální okruh informací:</p><p>-          Způsob správy a vyhodnocení transakci dopravce,</p><p>-          Způsob předávání všech transakcí vzniklých v odbavovacím systému dopravce do clearingového systému,</p><p>-          Kde budou dostupné výstupy rozúčtování clearingového systému,</p><p>-          Způsob distribuce Blacklistu a případně Whitelistu,</p><p>-          Zda bude dostupnost algoritmů rozúčtování časového jízdného, přestupních jízdenek a dělení kupónů,</p><p>-          Způsob využití a návrhu řešení elektronické peněženky,</p><p>-          Způsob napojení nebo integrace na další IDS, lokální nebo regionální řešení a České dráhy,</p><p>-          Způsob komunikace a datový tok, komunikační intervaly nebo rozsah dostupnosti,</p><p>-          Způsob a možnosti kontroly transakcí,</p><p>-          Detailní upřesnění jednotlivých rozhraní,</p><p>-          Zda bude dostupnost algoritmů tarifního systému zadavatele,</p><p>-          Principy řešení mimořádných stavů,</p><p>-          Způsob zajištění nezbytného výkaznictví dopravce,</p><p>-          Zda bude nezbytné pořízení HW, SW a služeb ve vztahu k řešení IDSOK.</p><p>Požadavky uvedené výše vycházející ze základních požadavků definovaných v zadávacích dokumentacích modernizace odbavování cestujících v IDSJMK [73] a IREDO [74], které specifikují požadavky na nové řešení clearingu.</p><p>V návaznosti na výše uvedené okruhy požadovaných informací lze shrnout nedostatky do následujících oblastí, které byly vyhodnoceny posuzovatelem, že nejsou dostatečně nebo vůbec specifikovány:</p><p>-          zda je umožněno jednotlivým dopravcům provádět správu a vyhodnocení svých transakci přístupem do centrálního clearingu zadavatele nebo bude nutné tuto funkcionalitu implementovat do svých systémů. Tato specifikace je nezbytná pro řízení ekonomických ukazatelů dopravce a efektivitu dopravních služeb,</p><p>-          zda je požadováno předávání všech transakcí vzniklých v odbavovacím systému dopravce sumarizovaně a konsolidovaně a bude nutné tuto funkcionalitu implementovat do svých systémů nebo se jedná o předávání samostatných transakčních souborů z každého odbavovacího zařízení samostatně nebo se bude jednat o přímou komunikaci odbavovacího zařízení s clearingovým centrem,</p><p>-          zda budou v centrálním clearingu dostupné výstupy rozúčtování nebo bude nutné tuto funkcionalitu implementovat do svých systémů nezbytných pro efektivitu dopravních služeb,</p><p>-          způsoby a logiky distribuce zakázaných karet nebo zařízení (Blacklistu) a případně povolených karet nebo zařízení (Whitelistu) v rámci řešení,</p><p>-          dostupnost algoritmů rozúčtování časového jízdného, přestupních jízdenek a dělení kupónů nebo bude nutné tyto mechanismy analyzovat dopravcem. Způsoby výpočtu a logika dělení znamená významnou část určující komplikovanost a náročnost výpočtů,</p><p>-          zda řešení bude obsahovat využití elektronické peněženky jak stávajících, tak i připravovaného řešení, tj. definování způsobu využití a zpracování elektronické peněženky, které je nezbytné pro specifikace a definované logiky řešení,</p><p>-          definování způsobu napojení nebo integrace na další IDS, lokální nebo regionální řešení a České dráhy. Způsob integrace nebo napojení na další řešení může znamenat zásadní „omezení&quot; nebo naopak složitost pro dodavatele řešení,</p><p>-          požadavky na komunikace, a to především datový tok, komunikační intervaly nebo rozsah dostupnosti pro:</p><p>Vozidla,</p><p>Kontaktní místa,</p><p>Přepravní kontrolu,</p><p>Případné validačních nebo informačních center,</p><p>Centrálních systémů se systémy dopravce,</p><p>které jsou nezbytné pro specifikaci nároků na komunikace, a především požadavky na náklady k zajištění těchto služeb nezbytných pro fungování celého řešení,</p><p>-          způsob a možnosti kontroly transakcí (např. blokace karet, cizích karet), nebo bude nutné tyto mechanismy (nezbytné pro fungování kontrolních mechanizmů řešení) analyzovat dopravcem,</p><p>-          detailní upřesnění jednotlivých rozhraní, tj. způsobu vstupního napojení dopravců a formát výstupního rozhraní nezbytné pro fungování napojení dopravce,</p><p>-          zda bude garantována dostupnost algoritmů tarifního systému zadavatele, nebo bude nutné tyto mechanismy analyzovat dopravcem. Způsoby logiky tarifního systému a výpočtu přepravy znamená významnou část určující komplikovanost a implementovatelnost tarifů do celkového řešení,</p><p>-          principy řešení mimořádných stavů:</p><p>nesoulad v rozdělení transakcí,</p><p>chybějící transakce z odbavovacích zařízení,</p><p>chybějící informace o přestupní jízdenky,</p><p>neznámé transakce,</p><p>apod.,</p><p>nezbytných pro fungování a důvěryhodnost celého řešení.</p><p>-          způsob zajištění výkaznictví dopravce nebo bude nutné tuto funkcionalitu implementovat do svých systémů, které jsou nezbytné pro řízení ekonomických ukazatelů dopravce a efektivitu dopravních služeb,</p><p>-          zda bude nezbytné pořízení k výše uvedeným oblastem:</p><p>HW, síťových komponent a souvisejících periférií,</p><p>SW od zadavatele formou služby nebo pořízení,</p><p>vývoj vlastního SW dopravce,</p><p>které jsou nezbytné pro návrh dodávaného řešení ve vztahu na komponenty, služby a další dodávky.</p><p>Výše uvedené nedostatky lze prezentovat na příkladu zveřejněné Datové věty pro clearingový systém regionálního řešení MSK, kde tyto informace jsou dostupné všem subjektům, kteří se připojují do systému MSK. Obdobně lze prezentovat na příkladu obecného popisu clearingu Cards Exchange společnosti ČSAD SVT Praha s.r.o., který je veřejně dostupný na webové stránce přístupu do clearingu (http://cards.svt.cz/tcards/help/cs/CE01-PO-Clearing-ObecnvPopis-l 19.pdf) [67].“</p><p>V bodě 5.4 znaleckého posudku nazvaném „Stanovisko posuzovatele“ uvedl znalec jako odpověď na otázku č. 4 část 2 následující:</p><p>„Požadovaný rozsah informací byl na základě dostupných informací nedostatečný, jak je uvedeno v kap. 5.3.1, a proto si dodavatelé odbavovacích systémů nemohli učinit reálnou představu o činnostech nutných k zabezpečení této funkcionality.“</p><p>V bodě 5.3.2 znaleckého posudku uvedl znalec mimo jiné toto:</p><p>„Na základě výše uvedených informací shrnutých v nálezové části a uvedeného výčtu nedostatků specifikovaných v posudkové části vztahující se na clearingový systém je zřejmé, že předložená zadávací dokumentace spolu s upřesněnými údaji uvedenými v doplňujících informacích a jejich přílohách, jsou nedostatečné pro zpracování nabídky a dodání zcela funkčního řešení.</p><p>Informace nebyly dostatečné, protože dodavatelé nemohli z těchto informací získat reálnou představu o detailních specifikacích nezbytných pro dodávku fungujícího clearingového systému, navazujících komunikaci, jednotlivých souvisejících vazeb, specifikaci vstupních a výstupních rozhraní, použitých algoritmů a celkového fungování řešení IDSOK.</p><p>Z posouzení dostupných informací (Smlouva o dílo se společností TELMAX s.r.o., ze dne 20.11.2017) [64] vyplývá, že KIDSOK nedisponoval takovým clearingem, který je součástí navrhovaného řešení.“</p><p>166.     V bodě 6. znaleckého posudku se znalec zabýval problematikou aplikačního rozhraní a způsobu komunikace odbavovacího systému s dispečerským systémem KIDSOK, konkrétně v této části znaleckého posudku odpovídal na následující otázky:</p><p>„Jaký okruh a rozsah informací musí objednatel, který požaduje dodání odbavovacího systému pro použití při zajištění dopravní obslužnosti v přepravě cestujících veřejnou linkovou dopravou (prováděnou autobusy) uvést o aplikačním rozhraní a popisu způsobu komunikace mezi odbavovacím systémem dopravce a dispečerským systémem KIDSOK tak, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu komunikace mezi odbavovacím systémem dopravce a dispečerským systémem KIDSOK zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují?“ (dále také „otázka č. 5 část 1“)</p><p>„Jsou informace o aplikačním rozhraní a popisu způsobu komunikace mezi odbavovacím systémem dopravce a dispečerským systémem KIDSOK poskytnuté zadavatelem v zadávací dokumentaci na veřejnou zakázku „Zajištění dopravní obslužnosti Olomouckého kraje veřejnými službami v přepravě cestujících veřejnou linkovou dopravou – oblast Jesenicko“ (vše je přílohou této žádosti), dostatečné pro to, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu komunikace mezi odbavovacím systémem dopravce a dispečerským systémem KIDSOK zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují? Znalci se ukládá své odpovědi odůvodnit.“ (dále také „otázka č. 5 část 2“)</p><p>V bodě 6.4 znaleckého posudku nazvaném „Stanovisko posuzovatele“ uvedl znalec jako odpověď na otázku č. 5 část 1 následující:</p><p>„Objednavatel musí uvést:</p><p>kompletní dokumentaci, či odkaz na standard, popisující aplikační rozhraní serverové části dispečerského systému KIDSOK a komunikaci odbavovacího systému s dispečerskou aplikací KIDSOK</p><p>případnou alternativou je, že výrobce dispečerského systému dodá tzv. API (Application Programming Interface), pomocí kterého by odbavovací systém dopravce komunikoval s dispečerským systémem, ale v t om případě je nutné k t o m u API poskytnout kompletní dokumentaci.</p><p>Podrobnosti o požadavcích jsou uvedeny v kapitole 6.3.“</p><p>V bodě 6.3.1 znaleckého posudku uvedl znalec mimo jiné toto:</p><p>„Aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení funkcionality - vytvoření a dodání odbavovacího systému schopného funkcionalitu komunikace mezi odbavovacím systémem dopravce a dispečerským systémem KIDSOK, případně k ověření, zda již takovým odbavovacím systémem disponují, musejí obdržet tyto informace o aplikačním rozhraní a popis způsobu komunikace mezi odbavovacím systémem dopravce a dispečerským systémem KIDSOK:</p><p>kompletní dokumentaci, či odkaz na standard, popisující aplikační rozhraní serverové části dispečerského systému KIDSOK a komunikaci odbavovacího systému s dispečerskou aplikací KIDSOK, tedy:</p><p>o      popis komunikačního protokolu - u standardních protokolů stačí název,</p><p>o      popis zabezpečení komunikace,</p><p>o      popis druhu zasílaných a přijímaných zpráv,</p><p>o      popis datového formátu zasílaných a přijímaných zpráv včetně přesného popisu údajů s uvedením oboru hodnot, které se ve zprávách posílají,</p><p>o      použité kódování diakritiky,</p><p>o      popis událostí aktivujících komunikaci,</p><p>případnou alternativou je, že dodavatel dispečerského systému (nebo jiný dodavatel) poskytne tzv. API (Application Programming Interface), pomocí kterého by odbavovací systém dopravce komunikoval s dispečerským systémem, ale v t om případě je nutné k tomu API poskytnout kompletní dokumentaci, která bude obsahovat informace:</p><p>o      minimální požadavky na hardware a software,</p><p>o      pro jaký programovací jazyk je API určeno,</p><p>o      seznam a popis procedur/funkcí/tříd API,</p><p>o      tzv. „programátorskou kuchařku&quot; s příklady pro jednotlivé druhy zasílaných a přijímaných zpráv,</p><p>o      popis událostí aktivujících komunikaci.</p><p>Na základě těchto údajů dodavatelé odbavovacích systémů mohou ověřit, zda jejich zařízení disponuje požadovanou funkcionalitou. Pokud dojdou k závěru, že jejich zařízení nedisponuje požadovanou funkcionalitou, poskytnuté informace jim poslouží ke stanovení rozsahu činností, časové náročnosti a nákladech na doplnění požadované funkcionality. Činnosti mohou souviset jak s úpravou software, nebo i hardware, kdy je nutné provést - analýzu požadavků, návrh řešení, vývoj, implementaci a testování, které probíhá nejenom po implementaci, ale i během vývoje.</p><p>Jako příklad dokumentace, která je pro účely veřejné zakázky dostatečná, je možné uvést dokument Centrální dispečink Zlínského kraje – Příloha č. 8 Smlouvy o přistoupení k IDS ZK, viz [63].“</p><p>V bodě 6.4 znaleckého posudku nazvaném „Stanovisko posuzovatele“ uvedl znalec jako odpověď na otázku č. 5 část 2 následující:</p><p>„Poskytnuté informace nejsou dostatečné, zcela chybí popis zabezpečení komunikace; popis druhu zasílaných a přijímaných zpráv; popis datového formátu zasílaných a přijímaných zpráv; použité kódování diakritiky.</p><p>Rozbor poskytnutých informací je v kapitole 6.3.“</p><p>V bodě 6.3.2 znaleckého posudku uvedl znalec mimo jiné toto:</p><p>„Ke komunikaci mezi odbavovacím systémem dopravce a dispečerským systémem KIDSOK je uvedeno v dokumentu Dodatečné_informace_sada_č_3.pdf [4] &quot;Komunikace s krajskou dispečerskou aplikací bude předána vítěznému uchazeči. Jedná se o standardní formát komunikace jako v jiných regionálních dispečerských systémech. Zadavatel považuje zveřejněné informace za dostatečné k provedení kalkulace.&quot;. Informace, že se jedná o standardní formát komunikace jako v jiných regionálních dispečerských systémech, je velice vágní. Pokud by byl uveden konkrétní regionální dispečerský systém, k němuž je zveřejněna úplná dokumentace, bylo by to v pořádku, ale tak tomu není. V dokumentu DodatečnéJnformace_sada_č_4.pdf [5] je alespoň uveden protokol UDP, což však není dostatečné, protože chybí popis formátu zasílaných zpráv. Navíc protokol UDP neověřuje doručení, takže není vhodný pro zasílání důležitých zpráv, u kterých je potřeba potvrzení o přijetí adresátem. Za takové lze pokládat textové zprávy zaslané v rámci protokolu, které musí odbavovací zařízení umožnit přijímat, zobrazovat a také odesílat. Chybějící popis formátu zasílaných zpráv souvisí s aplikačním rozhraním, o kterém je v naposledy uvedeném dokumentu (viz [5]) uvedeno &quot;... Předpokládá se, že při dodržení výše uvedených minimálních parametrů bude aplikační rozhraní upraveno na straně dispečerského systému v rámci jeho implementace.&quot; Nicméně t o t o tvrzení je v ostrém rozporu se závazkem v dokumentu Příloha č. 6 - Závazný text smlouvy o plnění předmětu veřejné zakázky [23], kde je jasně určena povinnost dopravce &quot;... zajistit bezproblémový proces vzájemné komunikace používaných vozidel s centrálním dispečinkem Objednatele ...&quot;. Rozhodně nejsou informace o aplikačním rozhraní a popisu způsobu komunikace mezi odbavovacím systémem dopravce a dispečerským systémem KIDSOK poskytnuté zadavatelem dostačující.</p><p>Možným vysvětlením nedostatků a neurčitostí může být fakt, že na dodávku systému centrálního dispečinku Koordinátora Integrovaného dopravního systému Olomouckého kraje byla smlouva podepsána s firmou T-MAPY spol s.r.o. až dne 14.12.2016 (viz [60]) a dispečink IDSOK byl předán až dne 30.6.2017 (viz [58] a [59]).“</p><p>167.     V bodě 7. znaleckého posudku se znalec zabýval problematikou požadavků na sledování polohy vozidel a odesílání dat o odbavení, případně další funkce v návaznosti na dispečink, konkrétně v této části znaleckého posudku odpovídal na následující otázky:</p><p>„Jaký okruh a rozsah informací musí objednatel, který požaduje dodání odbavovacího systému pro použití při zajištění dopravní obslužnosti v přepravě cestujících veřejnou linkovou dopravou (prováděnou autobusy) uvést o požadavcích na sledování polohy vozidel a odesílání dat o odbavení, případně dalších funkcích, které mají být v návaznosti na dispečink k dispozici tak, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu sledování polohy vozidel a odesílání dat o odbavení, případně dalších funkcí, které mají být v návaznosti na dispečink k dispozici zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují?“ (dále také „otázka č. 6 část 1“)</p><p>„Jsou informace o požadavcích na sledování polohy vozidel a odesílání dat o odbavení, případně dalších funkcích, které mají být v návaznosti na dispečink k dispozici poskytnuté zadavatelem v zadávací dokumentaci na veřejnou zakázku „Zajištění dopravní obslužnosti Olomouckého kraje veřejnými službami v přepravě cestujících veřejnou linkovou dopravou – oblast Jesenicko“ (vše je přílohou této žádosti), dostatečné pro to, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu sledování polohy vozidel a odesílání dat o odbavení, případně dalších funkcí, které mají být v návaznosti na dispečink k dispozici zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují? Znalci se ukládá své odpovědi odůvodnit.“ (dále také „otázka č. 6 část 2“)</p><p>V bodě 7.4 znaleckého posudku nazvaném „Stanovisko posuzovatele“ uvedl znalec jako odpověď na otázku č. 6 část 1 následující:</p><p>„Objednavatel musí uvést:</p><p>kompletní dokumentaci, či odkaz na standard, popisující požadované funkcionality odbavovacího systému vzhledem k dispečerské aplikaci,</p><p>kompletní dokumentaci, či odkaz na standard, popisující komunikaci odbavovacího systému s dispečerskou aplikací.</p><p>Podrobnosti jsou uvedeny v kapitole 7.3.“</p><p>V bodě 7.3.1 znaleckého posudku je uvedeno mimo jiné toto:</p><p>„Aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení funkcionality - vytvoření a dodání odbavovacího systému schopného funkcionalitu sledování polohy vozidel a odesílání dat o odbavení, případně dalších funkcí, které mají být v návaznosti na dispečink k dispozici zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují, musejí obdržet tyto informace:</p><p>kompletní dokumentaci, či odkaz na standard, popisující požadované funkcionality odbavovacího systému vzhledem k dispečerské aplikaci, což souvisí se:</p><p>o      zasíláním dat z palubního počítače,</p><p>o      příjmem a zpracováním dat z dispečerské aplikace,</p><p>kompletní dokumentaci, či odkaz na standard, popisující komunikaci odbavovacího systému s dispečerskou aplikací:</p><p>o      popis komunikačního protokolu - u standardních protokolů stačí název,</p><p>o      popis zabezpečení komunikace,</p><p>o      popis datového formátu zasílaných zpráv včetně přesného popisu údajů s uvedením oboru hodnot, které se ve zprávách posílají, aby dodavatel odbavovacího systému byl schopen určit, zda odbavovací zařízení disponuje periferiemi pro získání požadovaných údajů, či je musí doplnit,</p><p>o      použité kódování diakritiky,</p><p>o      popis druhu zpráv (požadavek - odpověď),</p><p>o      popis událostí aktivující komunikaci.</p><p>Na základě těchto údajů dodavatelé odbavovacích systémů mohou ověřit, zda jejich zařízení disponuje požadovanou funkcionalitou. Pokud dojdou k závěru, že jejich zařízení nedisponuje požadovanou funkcionalitou, poskytnuté informace jim poslouží ke stanovení rozsahu činností, časové náročnosti a nákladech na doplnění požadované funkcionality. Činnosti mohou souviset jak s úpravou software, nebo i hardware, kdy je nutné provést - analýzu požadavků, návrh řešení, vývoj, implementaci a testování, které probíhá nejenom po implementaci, ale i během vývoje.</p><p>V otázce se objevuje dotaz na funkcionalitu „odesílání dat o odbavení&quot;. Tato funkcionalita souvisí s Clearingem (což je řešeno v kapitole 5 Integrace požadovaného systému odbavení (clearing)), pro dispečink se nepoužívá, proto zde na ni neuvádíme žádné požadavky.</p><p>Vyjádření k dalším funkcím v návaznosti na dispečink - kromě funkcí požadovaných v zadání (funkce pro sledování polohy a stavu vozidel, funkce pro komunikaci s vybraným vozidlem nebo výběrem vozidel), žádné další funkce nejsou nutné (ani požadované zadavatelem) pro korektní funkci dispečerského systému.</p><p>Jako příklad dokumentace, která je pro účely veřejné zakázky dostatečná, je možné uvést dokument Centrální dispečink Zlínského kraje - Příloha č. 8 Smlouvy o přistoupení k IDS ZK, viz [63].“</p><p>V bodě 7.4 znaleckého posudku nazvaném „Stanovisko posuzovatele“ uvedl znalec jako odpověď na otázku č. 6 část 1 následující:</p><p>„Poskytnuté informace nejsou dostatečné, zcela chybí popis zabezpečení komunikace; popis datového formátu zasílaných zpráv včetně přesného popisu údajů s uvedením oboru hodnot, které se ve zprávách posílají; použité kódování diakritiky; popis druhu zpráv (požadavek - odpověď); jasná specifikace událostí aktivující komunikaci. Rozbor poskytnutých informací je v kapitole 7.3.“</p><p>V bodě 7.3.2 znaleckého posudku je uvedeno mimo jiné toto:</p><p>„V dokumentu Příloha_č_2_Technické_a_provozní_standardy_25_7_2016.pdf [13] v kapitole 6 (6. ŘÍZENÍ PROVOZU) je uveden požadavek na vyhodnocování polohy vozidla na základě signálu GPS ...&quot; a přenesení dat na dispečink. O jiných údajích, které by se měly ještě posílat na dispečink, je zmínka až v dokumentu Dodatečné_informace_sada_č_4.pdf [5], dotaz č. 23, kde je rozšířen obsah zpráv zasílaných z odbavovacího systému o jednoznačný identifikátor zařízení, čas, linku, spoj, id řidiče a informace o průjezdu / zastavení v zastávce. Minimální perioda zasílání zpráv z vozu je prodloužena na 20 vteřin (oproti původním 6ti vteřinám v dokumentu Příloha_č_2_Technické_a_provozní_standardy_25_7_2016.pdf [13]) a ještě je poukázáno na nepravidelné posílání zpráv „...významné zprávy (zastavení v zastávce apod.) se posílají okamžitě mimo pravidelný cyklus.&quot;. Chybí zde přesné určení událostí, kdy se má odesílat zpráva na dispečink.</p><p>V odpovědi na dotaz č. 23 je také uvedena nová informace „Odbavovací zařízení musí umožnit přijímat a zobrazovat a také odesílat textové zprávy zaslané v rámci protokolu (ne SMS).&quot;. Nikde však není uveden formát odesílaných a přijímaných zpráv, což platí také o zprávách zasílaných z vozidla obsahujících údaje o poloze vozidla.</p><p>Na páté straně dokumentu Dodatečné_informace_sada_č_4.pdf [5] je dotaz č. 24, kde je požadováno: „Žádáme o sdělení, jaké požadavky jsou kladeny na sledování polohy vozidel a odesílání dat o odbavení, případně které další funkce mají být v návaznosti na dispečink k dispozici?&quot;. Odpovědí je „Zodpovězeno v rámci dotazu č. 23.&quot;. V položeném dotazu je chyba, nikde v dokumentaci není uveden požadavek na odesílání dat o odbavení v návaznosti na dispečink, v odpovědi na dotaz č. 22 je uvedeno „Transakce z odbavovacího systému o prodaném jízdném ve vozidlech dopravce budou v běžném formátu (MS Excel, txt apod.) zasílány elektronickou formou (e-mail apod.) na e-mailovou adresu koordinátora minimálně jednou týdně.&quot;, ale nikde není explicitně uvedeno, že to má být přímo zajištěno funkcionalitou odbavovacího systému.</p><p>Možným vysvětlením nedostatků a neurčitostí může být fakt, že na dodávku systému centrálního dispečinku Koordinátora Integrovaného dopravního systému Olomouckého kraje byla smlouva podepsána s firmou T-MAPY spol s.r.o. až dne 14.12.2016 (viz [60]) a dispečink IDSOK byl předán až dne 30.6.2017 (viz [58] a [59]).</p><p>Poskytnuté informace o požadavcích na sledování polohy vozidel, případně dalších funkcích, které mají být v návaznosti na dispečink k dispozici poskytnuté zadavatelem v zadávací dokumentaci na veřejnou zakázku „Zajištění dopravní obslužnosti Olomouckého kraje veřejnými službami v přepravě cestujících veřejnou linkovou dopravou - oblast Jesenicko&quot; (vše je přílohou této žádosti), nejsou dostatečné pro to, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu sledování polohy vozidel, případně dalších funkcí, které mají být v návaznosti na dispečink k dispozici zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují.“</p><p>168.     V bodě 8. znaleckého posudku se znalec zabýval problematikou dobíjení karet řidičem, konkrétně v této části znaleckého posudku odpovídal na následující otázky:</p><p>„Jaký rozsah informací o spektru (typech) karet, které mají být řidičem při odbavení dobíjeny musí objednatel, který požaduje dodání odbavovacího systému pro použití při zajištění dopravní obslužnosti v přepravě cestujících veřejnou linkovou dopravou (prováděnou autobusy) uvést v souvislosti s požadavkem na tuto funkcionalitu tak, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu odbavení a dobíjení karet řidičem zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují?“ (dále také „otázka č. 7 část 1“)</p><p>„Jsou informace o spektru (typech) karet, které mají být řidičem ve vztahu k povinnosti dopravce, resp. řidiče odbavit cestující „v hotovosti nebo pomocí bankovní karty včetně dobití karty řidičem“ při odbavení dobíjeny poskytnuté zadavatelem v zadávací dokumentaci na veřejnou zakázku „Zajištění dopravní obslužnosti Olomouckého kraje veřejnými službami v přepravě cestujících veřejnou linkovou dopravou – oblast Jesenicko“ (vše je přílohou této žádosti), dostatečné pro to, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu odbavení a dobíjení karet řidičem zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují? Znalci se ukládá své odpovědi odůvodnit.“ (dále také „otázka č. 7 část 2“)</p><p>V bodě 8.4 znaleckého posudku nazvaném „Stanovisko posuzovatele“ uvedl znalec jako odpověď na otázku č. 7 část 1 následující: „Okruh a rozsah informací je obsahem kapitoly 8.3.1.“</p><p>V bodě 8.3.1 znaleckého posudku je uvedeno mimo jiné toto:</p><p>„Na základě rozboru požadované technologie byly identifikovány tyto základní informace nebo dokumenty nutné pro realizaci funkcionality „dobíjení karty řidičem&quot; dodavateli OS:</p><p>- typ proprietární čipové karty z hlediska jejího HW</p><p>- název konkrétní implementace PČK a poskytnutí s ní související dokumentace:</p><p>struktury karty (aplikace, datové struktury, zejména informace k funkcionalitě elektronická peněženka),</p><p>procesů (týkající se samotného odbavení cestujícího, zejména informace k funkcionalitě elektronická peněženka),</p><p>bezpečnosti (způsob zabezpečení relevantních aplikací - především elektronická peněženka, šifrování, práce s přístupovými klíči),</p><p>funkčních požadavků na odbavovací zařízení v souvislosti s dobíjením elektronické peněženky,</p><p>případně k rozúčtování (clearingu) elektronické peněženky a/nebo jízdních produktů, pokud je clearing v systému využíván,</p><p>k SAM modulu (pokud je v systému implementován).</p><p>Pro samotnou realizaci je dále důležité poskytnutí:</p><p>- testovacích karet a přístupových klíčů nebo SAMŮ (dle implementace),</p><p>- vzorové příklady korektního čtení/zápisu na kartu a komunikace se SAMem.</p><p>Součástí implementace je i otázka poskytnutí licencí na konkrétní implementaci dopravní karty dodavateli OS od držitele této licence.“</p><p>V bodě 8.4 znaleckého posudku nazvaném „Stanovisko posuzovatele“ uvedl znalec jako odpověď na otázku č. 7 část 2 následující:</p><p>„Poskytnuté informace dostatečné nejsou. Seznam parametrů a informací, které by měly být součástí zadávací dokumentace, je obsahem kapitoly 8.3.2.“</p><p>V bodě 8.3.2 znaleckého posudku je uvedeno mimo jiné toto:</p><p>„Informace a parametry, které by měly být uvedeny v zadávací dokumentaci, jsou uvedeny v předcházející kapitole. Odkazy na relevantní informace uvedené v zadávací dokumentaci jsou obsahem kapitoly 8.2.1. K dobíjení elektronické peněženky karty MSK (ODISka) byla poskytnuta tato dokumentace: datová věta pro MSK, procesy MSK, struktura BČK karty Moravskoslezského kraje.</p><p>V [6] - Dodatečné informace sada č. 4, str. 5 je v odpovědi na dotaz č. 25 uvedena informace „Dobití karty řidičem, je rozuměno dobití dopravní karty Mifare Desfare EVl, např. karta ODISka, v rámci přeshraniční dopravy s Moravskoslezským krajem.&quot; Z uvedeného plyne, že je jako upřesnění okruhu karet je požadována technologie Mifare DESFire EVl, která standardně využívá v rámci zabezpečení moduly SAM. Z možných implementací je uvedená pouze jako příklad karta ODISka.</p><p>Na základě porovnání výše uvedených informací a informací v předchozí kapitole lze dospět k seznamu informací, které nejsou v zadávací dokumentaci uvedeny.</p><p>K implementaci PČK pod názvem ODISka (karta MSK):</p><p>-          bezpečnost (způsob zabezpečení relevantních aplikací - především elektronická peněženka, šifrování, práce s přístupovými klíči),</p><p>-          funkční požadavky na odbavovací zařízení v souvislosti s dobíjením elektronické peněženky,</p><p>-          informace k SAM modulu.</p><p>K implementaci dalších PČK (minimálně zde přichází v úvahu karta IREDO z Pardubického kraje, který s Olomouckým krajem sousedí, přičemž karta IREDO je postavená na technologii Mifare DESFire EVl, a dále IN karta státního dopravce Českých drah):</p><p>-          název konkrétní implementace PČK, resp. název karty,</p><p>-          struktura karty (aplikace, datové struktury, zejména informace k funkcionalitě elektronická peněženka),</p><p>-          procesy (týkající se samotného odbavení cestujícího, zejména informace k funkcionalitě elektronická peněženka),</p><p>-          bezpečnost (způsob zabezpečení relevantních aplikací - především elektronická peněženka, šifrování, práce s přístupovými klíči),</p><p>-          funkční požadavky na odbavovací zařízení v souvislosti s dobíjením elektronické peněženky,</p><p>-          případně definice způsobu rozúčtování (clearing) elektronické peněženky a/nebo jízdních produktů, pokud je clearing v systému využíván,</p><p>-          informace k SAM modulu (pokud je v systému implementován).</p><p>Pro samotnou realizaci veřejné zakázky po výběru vítězného uchazeče je dále důležité (u všech implementací karet resp. technických řešení) poskytnutí:</p><p>-          testovacích karet a přístupových klíčů nebo SAMŮ (dle implementace),</p><p>-          vzorové příklady korektního čtení/zápisu na kartu a komunikace se SAMem.</p><p>Součástí implementace je i otázka poskytnutí licencí na každou požadovanou implementaci dopravní karty dodavateli OS od držitele této licence.“</p><p>Právní posouzení</p><p>169.     Úřad nejprve obecně uvádí, že zadávací řízení je procesním postupem zadavatele směřujícím k zadání veřejné zakázky, a jako takové představuje vysoce formalizovaný proces, který klade vysoké nároky na precizní zpracování zadávacích podmínek zadavatelem. Zákon stanoví v ustanovení § 44 odst. 1 zákona jasnou odpovědnost zadavatele za správnost a úplnost zadávacích podmínek, přičemž též platí, že je zadavatel povinen vymezit předmět veřejné zakázky v podrobnostech nezbytných pro zpracování nabídky. Jedná se tak o poskytnutí určitých, konkrétních a dostatečně podrobných informací, na základě kterých se dodavatelé rozhodují, zda se o veřejnou zakázku budou ucházet či nikoliv.</p><p>170.     Úřad v této souvislosti dodává, že „zadávací dokumentace musí být transparentní, dostatečně konkrétní a srozumitelná tak, aby na jejím základě mohla proběhnout všestranně korektní soutěž, v jejímž rámci bude vybrána ta nejlepší nabídka“ (blíže rozsudek Krajského soudu v Brně ze dne 10. 3. 2011, č. j. 62 Ca 3/2009; v rozhodnutí citované rozsudky jsou dostupné online mj. na www.nssoud.cz). K tomuto lze dále uvést, že (obdobně např. v rozsudku Nejvyššího správního soudu ze dne 25. 3. 2009, č. j. 2 Afs 86/2008), „požadavek jednoznačnosti, konkrétnosti a přesnosti zadávací dokumentace plyne z obecné zásady transparentnosti zakotvené v § 6 ZVZ. Tato zásada spolu se zásadou zákazu diskriminace a zásadou stejného zacházení se všemi dodavateli musí být zadavatelem dodržována v rámci celého zadávacího řízení“.</p><p>171.     Na základě shora uvedeného lze tedy shrnout, že ustanovení § 44 odst. 1 zákona přisuzuje odpovědnost za správnost a úplnost zadávací dokumentace zadavateli veřejné zakázky. Tento soubor dokumentů, údajů, požadavků a technických podmínek tvoří společně nejvýznamnější dokument nezbytný pro to, aby subjekty, které se hodlají zadávacího řízení zúčastnit, mohli řádně zpracovat své porovnatelné nabídky, které umožní zadavateli jejich následné hodnocení dle stanovených hodnotících kritérií. Zvláštní důraz je pak kladen právě na specifikaci předmětu veřejné zakázky, která v podaných nabídkách ovlivní zejména výši nabídkové ceny. V tomto smyslu se vyjádřil i např. Nejvyšší správní soud ve svém rozsudku č. j. 9 Afs 30/2010 ze dne 16. 11. 2010, když uvedl, že „zadávací dokumentace je nejvýznamnějším dokumentem v rámci zadávacího řízení. Za jeho zpracování je plně odpovědný zadavatel a je povinen ho zpracovat dostatečně kvalitně a s patřičnou odborností tak, aby na jeho základě bylo možno podat odpovídající a především vzájemně porovnatelné nabídky“.</p><p>172.     K technickým podmínkám, které vymezují charakteristiky a požadavky zadavatele na předmět veřejné zakázky (§ 45 odst. 1 zákona), Úřad uvádí, že zákonodárce umožnil zadavateli stanovit technické podmínky formou požadavků na výkon nebo funkci požadovaného plnění, přičemž ponechává na zadavateli, pro kterou variantu se rozhodne. Musí však své požadavky na výkon či funkci předmětu plnění stanovit dostatečně přesně. Pouze takové vymezení těchto požadavků, které bude dostatečně určité a podrobné, umožní uchazečům o veřejnou zakázku jednoznačně určit předmět zakázky, a to v detailech, které jsou nezbytné nejen pro zpracování nabídek, ale též pro zpracování takových nabídek, které budou vzájemně porovnatelné. Stanovení technických podmínek pomocí požadavků na funkci nebo výkon proto na zadavatele klade nepochybně vyšší nároky, než vymezení prostřednictvím odkazů na technické normy apod. Zadavatel proto musí usilovat o to, aby případnou nejednoznačností (neúplností) svých požadavků v zadávací dokumentaci nezpůsobil objektivní stav, kdy uchazeči nebudou schopni jednoznačně určit, co je ze strany zadavatele poptáváno, resp. nebudou schopni požadavky zadavatele jednoznačně ocenit, čímž by jim byla odepřena možnost se takového to zadávacího řízení účastnit, a tedy předložit v něm své nabídky.</p><p>173.     K tomuto je vhodné doplnit i názor Nejvyššího správního soudu, který byl vysloven v rozsudku č. j. 7 Afs 66/2010 ze dne 26. 10. 2011, podle kterého „ani odborně zdatný uchazeč nemůže při zpracování nabídky vycházet z nejednoznačných podkladů, resp. nabídka zpracovaná na základě neúplných či příliš obecných podkladů bude spíše než odbornou reakcí na požadavky zadavatele, nepodloženou spekulací uchazeče.“ Z citovaného tak vyplývá, že ani odborným znalostem dodavatelů nelze přisuzovat váhu do té míry, dokud by měly suplovat povinnosti zadavatele při jednoznačném vymezení zadávacích podmínek.</p><p>174.     Úřad tedy uzavírá, že na základě výše uvedeného, tzn. z dikce zákona a z relevantní judikatury, platí odpovědnost zadavatele za správnost a úplnost zadávacích podmínek, tedy i těch, jež se týkají technických požadavků zadavatele na předmět veřejné zakázky. V šetřeném případě je tedy stěžejní otázkou, a tedy hlavní námitkou navrhovatele, pochybnost, zda zadavatel stanovil v zadávací dokumentaci, resp. v dodatečných informacích, požadavky na odbavovací systém (zařízení) v takovém rozsahu (podrobnostech), že umožňovaly potenciálním dodavatelům podat odborně a cenově precizní a tedy i vzájemně porovnatelné nabídky. Po posouzení obsahu návrhu navrhovatele Úřad zbylé námitky, tj. neporovnatelnost předložených nabídek a možné zvýhodnění dodavatele TELMAX s. r. o., příp. stávajících dopravců ARRIVA MORAVA a. s. a First Transport Lines a. s., vnímá již jako důsledky případného pochybení zadavatele – nesprávně nastavených zadávacích podmínek. Z tohoto důvodu Úřad nejdřív přistoupil k posouzení té části návrhu týkající se nedostatečného vymezení zadávacích podmínek.</p><p>175.     Po zrušení napadeného rozhodnutí a vrácení věci Úřadu k novému projednání se v dalším průběhu správního řízení nepodařilo vyvrátit rozpor mezi jednotlivými tvrzeními společností BUSE s.r.o. a Bustec s.r.o., jelikož jak společnost BUSE s.r.o. ve svém vyjádření ze dne 2. 8. 2017 tak i společnost Bustec s.r.o. ve svém vyjádření ze dne 27. 7. 2017 setrvaly na svých předchozích vyjádřeních a shodně odmítly jakýkoliv rozpor v jejich předchozích vyjádřeních, přičemž společnost BUSE s.r.o. již na další žádosti Úřadu o informace ze dne 4. 8. 2017 a dne 22. 8. 2017 nereagovala a dále z dodavatelů navržených zadavatelem v jeho vyjádření ze dne 27. 7. 2017 (tj. společnost Merchant Payment Acquiring Services s.r.o. a společnost Diebold Nixdorf s.r.o.) reagoval na žádosti Úřadu o informace pouze jeden z nich. Úřad tak nemohl skutková zjištění opřít o vyjádření společností BUSE s.r.o. a Bustec s.r.o. ani jiných dodavatelů (tj. těch, které navrhoval zadavatel ve vyjádření ze dne 27. 7. 2017), tudíž Úřad zároveň nemohl posoudit schopnost potenciálních dodavatelů na základě konkrétně stanovených požadavků zadavatele podat nabídku v zadávacím řízení na veřejnou zakázku. Vzhledem k tomu, že má Úřad dle zásady materiální pravdy zakotvené v § 3 správního řádu povinnost zjistit stav věci, o němž nejsou důvodné pochybnosti a v rámci posuzování schopnosti potenciálních dodavatelů na základě konkrétně stanovených požadavků zadavatele podat nabídku v zadávacím řízení na veřejnou zakázku důvodné pochybnosti o stavu věci nadále přetrvávaly, přistoupil Úřad v souladu se závěry druhostupňového rozhodnutí k posouzení způsobu stanovení požadavků zadavatelem, tj. zda zadávací podmínky v rozsahu, v jakém byly uvedeny v zadávací dokumentaci, byly vymezeny dostatečně tak, aby byli potenciální dodavatelé schopni na jejich základě podat odborně a cenově precizní a tedy i vzájemně porovnatelné nabídky.</p><p>176.     Úřad dále uvádí, že pro provedení skutkového zjištění, zda zadávací podmínky v rozsahu, v jakém byly uvedeny v zadávací dokumentaci, byly vymezeny dostatečně tak, aby byli potenciální dodavatelé schopni na jejich základě podat odborně a cenově precizní a tedy i vzájemně porovnatelné nabídky, bylo třeba ustanovit znalce, neboť se jednalo o posouzení skutečností, k nimž je třeba vysoce odborných znalostí z oblasti dopravy, které úřední osoby nemají a zároveň takovéto odborné posouzení nebylo lze v souladu se zásadou efektivního výkonu státní správy opatřit od jiného správního orgánu.</p><p>177.     Proto Úřad usnesením č. j. ÚOHS-S0747/2016/VZ-34095/2017/512/AKp ze dne 28. 11. 2017 ustanovil znalcem – České vysoké učení technické v Praze, Fakulta dopravní, IĆO 68407700, Ústav soudního znalectví v dopravě, se sídlem Horská 3, 128 03 Praha 2, obory znalecké činnosti: doprava a spoje, přičemž dne 19. 4. 2018 byl Úřadu doručen znalecký posudek ze dne 17. 4. 2018.</p><p>178.     Úřad nejprve obecně uvádí, že správní orgán (Úřad) provede důkaz znaleckým posudkem tam, kde je k posouzení skutečností významných pro zjištění skutkového stavu věci zapotřebí odborných znalostí. Správní orgán musí dbát o to, aby znalcem byl ustanoven odborník z toho oboru, popřípadě z jeho odvětví, do něhož spadá odborné posouzení konkrétní skutečnosti; zadání musí formulovat tak, aby znalci nebylo ukládáno vyjadřovat se k otázkám, u nichž nejde o odborné posouzení konkrétní skutečnosti, nýbrž o právní posouzení určitého skutkového stavu nebo o výklad právního předpisu. Toto považuje Úřad za splněné (k námitce přílišné formálnosti znaleckého posudku se Úřad vyjádří dále), načež je podle názoru Úřad vhodné akcentovat, že obecně platí, že znalecký posudek přestavuje jen jeden z podkladů rozhodnutí a má stejnou váhu jako jakýkoli jiný.</p><p>179.     K tomuto Úřad dále uvádí, že možnosti hodnocení znaleckého posudku, jako důkazního prostředku, se správnímu orgánu, jak ostatně uvedl Nejvyšší správní soud v rozsudku ze dne 30. 5. 2014, č. j. 5 Afs 48/2013-272, otevírají minimálně, a to jen pokud jde o jeho přesvědčivost, úplnost ve vztahu k zadání, jeho logické odůvodnění a (zejména) soulad s ostatními provedenými důkazy.</p><p>180.     Obdobný závěr vyplývá i z rozsudku Nejvyššího soudu č. j. 22 Cdo 1810/2009 ze dne 21. 10. 2009, kde hodnocení důkazu znaleckým posudkem spočívá v „posouzení, zda závěry posudku jsou náležitě odůvodněny, zda jsou podloženy obsahem nálezu, zda bylo přihlédnuto ke všem skutečnostem, s nimiž se bylo třeba vypořádat, zda závěry posudku nejsou v rozporu s výsledky ostatních důkazů a zda odůvodnění znaleckého posudku odpovídá pravidlům logického myšlení.“ Aby Úřad (soud) mohl znalecký posudek „odpovědně hodnotit, nesmí se znalec omezit ve svém posudku na podání odborného závěru, nýbrž z jeho posudku musí mít soud možnost seznat, z kterých zjištění v posudku znalec vychází, jakou cestou k těmto zjištěním dospěl a na základě jakých úvah došel ke svému závěru“.</p><p>181.     Úřad dodává, že mu v případě hodnocení znaleckých posudků nesvědčí pozice odborného arbitra, který by byl oprávněn usuzovat, zda je znalecký posudek správný (v konkrétní rovině, zda korektně posoudil odborné skutečnosti, k nimž je třeba odborných znalostí). Jak již Úřad uvedl výše, možnosti hodnocení znaleckého posudku, jako důkazního prostředku, se správnímu orgánu otevírají minimálně, a to jen pokud jde o jeho přesvědčivost, úplnost ve vztahu k zadání, jeho logickému odůvodnění a (zejména) souladu s ostatními provedenými důkazy. Protože však Úřad nemá pochybnosti o správnosti, byť i jen dílčích, závěrů znaleckého posudku, jak bude argumentováno dále, nepřistoupil z logiky věci ani k zadání znaleckého posudku nového, případně k vypracování znaleckého posudku revizního, byť bylo toto vypracování navrhováno zadavatelem (k čemuž se Úřad vyjádří na závěr své argumentace). Úřad na tomto místě zdůrazňuje, že v žádném případě jen mechanicky nepřevzal závěry znaleckého posudku, poněvadž si je vědom, že ani znalecký posudek jako důkazní prostředek není automaticky nadřazen důkazním prostředkům jiným (a totéž platí také o důkazech z nich vyplývajících), nýbrž že je třeba jej hodnotit dle výše uvedených pravidel, což Úřad učinil.</p><p>182.     Úřad proto podrobil znalecký posudek posouzení s ohledem na výše uvedená kritéria a konstatuje, že posudek znaleckého ústavu z hlediska splnění formálních znaků posudku je přípustný, přičemž platí, že závěry znaleckého posudku jsou závěry učiněné odborně kvalifikovanou osobou, jsou jasné a vnitřně bezrozporné. Úřad dále konstatuje, že závěry znalce jsou založeny na objektivní metodě, která je ve znaleckém posudku popsána s takovou určitostí, že umožňuje zpětně rekonstruovat činnost znalce při zpracování znaleckého posudku a Úřad tak shledal závěry znalce ve znaleckém posudku za způsobilé být součástí právní argumentace při posouzení projednávané věci. Úřad dále naznal, že závěry znalce nejsou v rozporu s žádnou jinou skutečností, která by byla Úřadem zjištěna z dokumentace o veřejné zakázce. Úřad si je vědom toho, že zadavatel zpochybnil výše uvedené závěry Úřadu ve svém vyjádření, Úřad se však ke konkrétním výhradám zadavatele pro přehlednost vyjádří vždy při posouzení konkrétních závěrů znalce.</p><p>183.     Na základě výše uvedeného Úřad konstatuje, že shledává předložený znalecký posudek znaleckého ústavu učiněný v souladu s ustanovením § 56 správního řádu. Úřad dále (opakovaně) dodává, že uvedený posudek splňuje i požadavky uvedené v § 8 zákona o znalcích a § 13 odst. 1 a 2 vyhlášky o znalcích.</p><p>184.     Poté co Úřad posoudil přípustnost podaného znaleckého posudku coby důkazu, přistoupil k věcnému posouzení samotných závěrů, které znalec učinil.</p><p>185.     V následující části odůvodnění tohoto rozhodnutí se Úřad tedy bude věnovat těm zadávacím podmínkám, resp. technickým požadavkům zadavatele na odbavovací systém (zařízení), jež navrhovatel v rámci svého návrhu ze dne 12. 12. 2016 napadal a jež také byly předmětem znaleckého zkoumání, a to konkrétně z toho ohledu, zda v rozsahu, v jakém byly uvedeny v zadávací dokumentaci, byly vymezeny dostatečně tak, aby byli potenciální dodavatelé schopni na jejich základě podat odborně a cenově precizní a tedy i vzájemně porovnatelné nabídky.</p><p>K akceptaci časových kuponů na bankovních platebních kartách</p><p>186.     Úřad nejprve přistoupil k posouzení úplnosti způsobu řešení akceptace časových kupónů KIDSOK na platební kartě. Jak již bylo uvedeno výše, Úřad bude při posuzování úplnosti způsobu řešení akceptace časových kupónů KIDSOK na platební kartě vycházet ze závěrů znaleckého posudku ze dne 17. 4. 2018.</p><p>187.     Nejprve Úřad uvádí, že zadavatel předmětný požadavek stanovil v rámci článku 1.2 přílohy č. 2 závazného návrhu smlouvy, když u specifikace odbavovacího zařízení uvedl potřebu „akceptace časových kupónů KIDSOK na platební kartě“. Poté tento požadavek upřesnil prostřednictvím odpovědi na dotaz č. 11 v dodatečných informacích sada č. 3 ze dne 5. 9. 2016, když konkretizoval informace nezbytné pro implementaci požadavku o potřeby tokenizace a greenlistu, přičemž požadavek greenlistu dále doplnil v odpovědi na dotaz č. 20 uvedený v dodatečných informacích sada č. 4 ze dne 15. 9. 2016. Znalec dále ve vztahu k této části zadávacích podmínek rovněž posoudil odpověď na dotaz č. 19 uvedený v dodatečných informacích sada č. 4 ze dne 15. 9. 2016, dokument Datová věta pro MSK, dokument Příloha č. 1 dodatečných informací sada č. 6.</p><p>188.     S odkazem na závěry znalce uvedené v bodech 2.3.1., 2.3.2. a 2.4. znaleckého posudku (podrobně uvedeny viz bod 162. odůvodnění tohoto rozhodnutí) lze ze strany Úřadu uvést, že v zadávací dokumentaci k požadavku zadavatele – akceptace časových kuponů na bankovních platebních kartách – chyběly následující informace či parametry:</p><p>-          tokenizační algoritmus a tokenizační klíče [v případě využití tzv. SAM modulu v oblasti bezpečnosti odbavovacího systému (tato skutečnost však není ze zadávací dokumentace zřejmá) musí být poskytnuta specifikace SAM modulu a dokumentace ke komunikačnímu rozhraní (API)];</p><p>-          kromě vybraného formátu greenlistu (XML) musí specifikace greenlistu obsahovat:</p><p>popis variant/verzí greenlistu (pokud existují),</p><p>popis datové struktury nebo struktur greenlistu,</p><p>popis komunikace mezi koncovými body systému.</p><p>-          specifikace greenlistu musí obsahovat také kvalitativní a kvantitativní parametry související s distribucí greenlistu:</p><p>časové limity, do kdy musí být informace distribuovány z BackOffice do koncových zařízení a naopak,</p><p>celková (odhadovaná, maximální) velikost zasílaného greenlistu, velikost jeho inkrementálních částí.</p><p>-          další informace:</p><p>popis (směry) datových toků a způsob distribuce greenlistu mezi jednotlivými prvky (subjekty) systému (odbavovací zařízení dopravce, BackOffice dopravce, BackOffice koordinátora),</p><p>popis nebo schéma procesů (odbavení, reklamace), ze kterého je zřejmé, jak se nakládá s informacemi obsaženými v greenlistu pro reálné situace, které mohou v systému nastat.</p><p>189.     Ze závěrů znaleckého posudku tak zcela jasně vyplývá, že informace uvedené v zadávací dokumentaci k požadavku zadavatele – akceptace časových kuponů na bankovních platebních kartách – nebyly s ohledem na chybějící informace či parametry (uvedeny viz předcházející bod odůvodnění tohoto rozhodnutí) dostatečné pro to, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu akceptace časových kuponů KIDSOK na bankovních platebních kartách zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují.</p><p>Ke komunikaci s dispečerskou aplikací</p><p>190.     Dalším navrhovatelem namítaným bodem je zadavatelem nedostatečné sdělení informací ve věci komunikace s krajskou dispečerskou aplikací, zejména tak uchazeči nevědí, „kdo s kým komunikuje a v jaké přesné struktuře dat“.</p><p>191.     Úřad k tomuto uvádí, že zadavatel v článku 1.2 přílohy č. 2 závazného návrhu smlouvy požaduje jako jednu z funkcí zařízení na výdej jízdenek komunikaci s dispečerskou aplikací (krajskou i vlastní). Tento požadavek zadavatel prostřednictvím dodatečných informací (sada č. 3 a sada č. 4) upřesnil tak, že se jedná o standardní formát komunikace formou UDP datových přenosů v síti GSM/GPRS. Znalec ve vztahu k danému požadavku zadavatele posoudil rovněž přílohu č. 6 - Závazný text smlouvy o plnění předmětu veřejné zakázky.</p><p>192.     S ohledem na obsah bodů 3.3.1., 3.3.2. a 3.4. znaleckého posudku (podrobně uveden viz bod 163. odůvodnění tohoto rozhodnutí) Úřad uvádí, že v zadávací dokumentaci k požadavku zadavatele – komunikace s dispečerskou aplikací – zcela chyběly následující informace či parametry:</p><p>-          popis zabezpečení komunikace,</p><p>-          popis datového formátu zasílaných zpráv včetně přesného popisu údajů s uvedením oboru hodnot, které se ve zprávách posílají,</p><p>-          použité kódování diakritiky,</p><p>-           popis druhu zpráv (požadavek – odpověď),</p><p>-          jasná specifikace událostí aktivující komunikaci.</p><p>193.     Ze závěrů znaleckého posudku tak zcela jasně vyplývá, že informace uvedené v zadávací dokumentaci k požadavku zadavatele – komunikace s dispečerskou aplikací – nebyly vzhledem k chybějícím informacím či parametrům uvedeným v předcházejícím bodu odůvodnění tohoto rozhodnutí dostatečné pro to, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu komunikace s dispečerskou aplikací zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují.</p><p>K zajištění komunikace se systémem e-shopu KIDSOK</p><p>194.     Další dílčí námitkou navrhovatele je v podaném návrhu neúplnost popisu aplikačního rozhraní pro komunikaci se systémem e-shopu KIDSOK, zejména informace o tom, kdo je dodavatelem a provozovatelem daného e-shopu.</p><p>195.     Zadavatel v článku 1.2 přílohy č. 2 závazného návrhu smlouvy stanovil požadavek na plnou integraci odbavovacího systému do e-shopu KIDSOK. Tento požadavek dále zadavatel upřesnil v dodatečných informacích sada č. 3 tak, že se má jednat zejména o párování plateb mezi ERP systémem uchazeče a e-shopem KIDSOK, přičemž dodal, že provoz e-shopu zajišťuje sám zadavatel. Znalec dále v rámci posuzování daného požadavku zadavatele zohlednil také dodatečné informace sada č. 4 a dodatečné informace sada č. 6.</p><p>196.     Na základě závěrů znalce uvedených v bodech 4.3.1., 4.3.2. a 4.4. znaleckého posudku (podrobně uvedeny viz bod 164. odůvodnění tohoto rozhodnutí) Úřad uvádí, že v zadávací dokumentaci k požadavku zadavatele – zajištění komunikace se systémem e-shopu KIDSOK – nebyly dostatečně nebo vůbec specifikovány následující oblasti:</p><p>-          způsob napojení e-Shopu na clearingový systém ve vztahu na zde realizované transakce (nákup kupónů, časových jízdenek apod.). Logika napojení komponent je nezbytná pro definování dodávaných komponent a souvisí s případnou nutností dodání této komponenty dopravcem pro fungování celého řešení ve vztahu k dopravci,</p><p>-          způsob využití nebo provázání Greenlistu, Blacklistu a případné Whitelistu v logice e-Shopu, který je nezbytný pro definování intervalů a komunikačních kanálů pro odbavovací systémy nebo komponenty dopravce,</p><p>-          způsob napojení transakčních systémů dopravců (odbavovací systémy, kontaktní místa apod.) na e-Shop, které může znamenat nutnost dodání takovéhoto řešení přímo dopravcem,</p><p>-          způsob napojení systému bezkontaktních/kontaktních karet (včetně databáze) na e-Shop. Logika napojení karet může znamenat nutnost dodání takovéhoto řešení přímo dopravcem,</p><p>-          jaký je rozsah funkcí e-Shopu, kdy nelze kvalifikovaně odhadnout možnosti a způsoby jejich využití pro řízení ekonomických ukazatelů dopravce a efektivitu dopravních služeb, tj. zda nebude ze strany dopravce potřeba zajistit některé funkce zakoupením nebo vývojem vlastního SW,</p><p>-          zda bude nezbytné pořízení k výše uvedeným oblastem:</p><p>HW, síťových komponent a souvisejících periférií,</p><p>SW od zadavatele formou služby nebo pořízení,</p><p>vývoj vlastního SW dopravce,</p><p>které jsou nezbytné pro návrh dodávaného řešení ve vztahu na komponenty, služby a další dodávky.</p><p>197.     S ohledem na závěry znaleckého posudku tak lze opět ze strany Úřadu uvést, že informace uvedené v zadávací dokumentaci k požadavku zadavatele – zajištění komunikace se systémem e-shopu KIDSOK – nebyly vzhledem k chybějícím či nedostatečným informacím specifikovaným v předcházejícím bodu odůvodnění tohoto rozhodnutí dostatečné pro to, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu komunikace s dispečerskou aplikací zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují.</p><p>K integraci požadovaného systému odbavení (clearing)</p><p>198.     V rámci svého návrhu ze dne 12. 12. 2016 navrhovatel rovněž namítal, že „(n)ekonkretizovány zůstávají požadavky na další služby nutné pro integraci požadovaného systému odbavení (včetně požadavků na clearing tržeb, datového a aplikačního rozhraní clearingu), podle kterých má být plná integrace odbavovacího systému provedena.“</p><p>199.     Znalec vzal při posuzování daného požadavku zadavatele v potaz především následující dokumenty: dodatečné informace sada č. 4, dodatečné informace sada č. 6, dodatečné informace sada č. 7, dodatečné informace sada č. 8.</p><p>200.     Na základě informací uvedených v bodech 5.3.1., 5.3.2. a 5.4. znaleckého posudku (podrobně uvedeny viz bod 165. odůvodnění tohoto rozhodnutí) Úřad uvádí, že v zadávací dokumentaci k požadavku zadavatele – integrace požadovaného systému odbavení (clearing) – nebyly dostatečně či vůbec specifikovány následující oblasti:</p><p>-          zda je umožněno jednotlivým dopravcům provádět správu a vyhodnocení svých transakci přístupem do centrálního clearingu zadavatele nebo bude nutné tuto funkcionalitu implementovat do svých systémů. Tato specifikace je nezbytná pro řízení ekonomických ukazatelů dopravce a efektivitu dopravních služeb,</p><p>-          zda je požadováno předávání všech transakcí vzniklých v odbavovacím systému dopravce sumarizovaně a konsolidovaně a bude nutné tuto funkcionalitu implementovat do svých systémů nebo se jedná o předávání samostatných transakčních souborů z každého odbavovacího zařízení samostatně nebo se bude jednat o přímou komunikaci odbavovacího zařízení s clearingovým centrem,</p><p>-          zda budou v centrálním clearingu dostupné výstupy rozúčtování nebo bude nutné tuto funkcionalitu implementovat do svých systémů nezbytných pro efektivitu dopravních služeb,</p><p>-          způsoby a logiky distribuce zakázaných karet nebo zařízení (Blacklistu) a případně povolených karet nebo zařízení (Whitelistu) v rámci řešení,</p><p>-          dostupnost algoritmů rozúčtování časového jízdného, přestupních jízdenek a dělení kupónů nebo bude nutné tyto mechanismy analyzovat dopravcem. Způsoby výpočtu a logika dělení znamená významnou část určující komplikovanost a náročnost výpočtů,</p><p>-          zda řešení bude obsahovat využití elektronické peněženky jak stávajících, tak i připravovaného řešení, tj. definování způsobu využití a zpracování elektronické peněženky, které je nezbytné pro specifikace a definované logiky řešení,</p><p>-          definování způsobu napojení nebo integrace na další IDS, lokální nebo regionální řešení a České dráhy. Způsob integrace nebo napojení na další řešení může znamenat zásadní „omezení&quot; nebo naopak složitost pro dodavatele řešení,</p><p>-          požadavky na komunikace, a to především datový tok, komunikační intervaly nebo rozsah dostupnosti pro:</p><p>Vozidla,</p><p>Kontaktní místa,</p><p>Přepravní kontrolu,</p><p>Případné validačních nebo informačních center,</p><p>Centrálních systémů se systémy dopravce,</p><p>které jsou nezbytné pro specifikaci nároků na komunikace, a především požadavky na náklady k zajištění těchto služeb nezbytných pro fungování celého řešení,</p><p>-          způsob a možnosti kontroly transakcí (např. blokace karet, cizích karet), nebo bude nutné tyto mechanismy (nezbytné pro fungování kontrolních mechanizmů řešení) analyzovat dopravcem,</p><p>-          detailní upřesnění jednotlivých rozhraní, tj. způsobu vstupního napojení dopravců a formát výstupního rozhraní nezbytné pro fungování napojení dopravce,</p><p>-          zda bude garantována dostupnost algoritmů tarifního systému zadavatele, nebo bude nutné tyto mechanismy analyzovat dopravcem. Způsoby logiky tarifního systému a výpočtu přepravy znamená významnou část určující komplikovanost a implementovatelnost tarifů do celkového řešení,</p><p>-          principy řešení mimořádných stavů:</p><p>nesoulad v rozdělení transakcí,</p><p>chybějící transakce z odbavovacích zařízení,</p><p>chybějící informace o přestupní jízdenky,</p><p>neznámé transakce,</p><p>apod.,</p><p>nezbytných pro fungování a důvěryhodnost celého řešení.</p><p>-          způsob zajištění výkaznictví dopravce nebo bude nutné tuto funkcionalitu implementovat do svých systémů, které jsou nezbytné pro řízení ekonomických ukazatelů dopravce a efektivitu dopravních služeb,</p><p>-          zda bude nezbytné pořízení k výše uvedeným oblastem:</p><p>HW, síťových komponent a souvisejících periférií,</p><p>SW od zadavatele formou služby nebo pořízení,</p><p>vývoj vlastního SW dopravce,</p><p>které jsou nezbytné pro návrh dodávaného řešení ve vztahu na komponenty, služby a další dodávky.</p><p>201.     Ze závěrů znaleckého posudku tak zcela jasně vyplývá, že informace uvedené v zadávací dokumentaci k požadavku zadavatele – integrace požadovaného systému odbavení (clearing) – nebyly s odkazem na zcela chybějící či nedostatečně specifikované oblasti vymezené v předcházejícím bodu odůvodnění tohoto rozhodnutí dostatečné pro to, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu integrace požadovaného systému odbavení (tj. požadavek na clearing tržeb, datové a aplikační rozhraní clearingu, na provozovatele clearingu, dispečinku) zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují.</p><p>K aplikačnímu rozhraní a způsobu komunikace odbavovacího systému s dispečerským systémem KIDSOK</p><p>202.     Navrhovatel také v rámci svého návrhu ze dne 12. 12. 2016 mimo jiné uvedl, že »[i]nformace o komunikaci s krajskou dispečerskou aplikací také odmítá Zadavatel sdělit, přitom potenciální dodavatelé mají komunikaci dle zadávacích podmínek zajistit, a tudíž ji musí v rámci své nabídky nacenit; nevědí ovšem např. „kdo s kým komunikuje a v jaké přesné struktuře dat“.«</p><p>203.     Daný požadavek zadavatele je uveden pod bodem 1.3 přílohy č. 2 závazného návrhu smlouvy, kdy je u odbavovacího zařízení požadována funkce zařízení na výdej jízdenek „- komunikace s dispečerskou aplikací (krajskou a vlastní)“ a dále je mu věnován bod 6. přílohy č. 2 závazného návrhu smlouvy. Kromě relevantních informací uvedených v příloze č. 2 závazného návrhu smlouvy vzal znalec v rámci posuzování daného požadavku zadavatele v potaz také informace z následujících dokumentů: dodatečné informace sada č. 3, dodatečné informace sada č. 4, příloha č. 6 Závazný text smlouvy o plnění předmětu veřejné zakázky.</p><p>204.     S ohledem na závěry znalce uvedené v bodech 6.3.1., 6.3.2. a 6.4. znaleckého posudku (podrobně uvedeny v bodě 166. odůvodnění tohoto rozhodnutí) Úřad uvádí, že v zadávací dokumentaci k požadavku zadavatele – komunikace mezi odbavovacím systémem dopravce a dispečerským systémem KIDSOK – zcela chyběly následující informace či parametry:</p><p>-          popis zabezpečení komunikace,</p><p>-          popis druhu zasílaných a přijímaných zpráv,</p><p>-          popis datového formátu zasílaných a přijímaných zpráv,</p><p>-          použité kódování diakritiky.</p><p>205.     Ze závěrů znaleckého posudku tak opět jasně vyplývá, že informace uvedené v zadávací dokumentaci k požadavku zadavatele – komunikace mezi odbavovacím systémem dopravce a dispečerským systémem KIDSOK – nebyly s ohledem na zcela chybějící informace či parametry specifikované v předcházejícím bodu odůvodnění tohoto rozhodnutí dostatečné pro to, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu komunikace mezi odbavovacím systémem dopravce a dispečerským systémem KIDSOK zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují.</p><p>K požadavkům na sledování polohy vozidel a odesílání dat o odbavení, případně další funkce v návaznosti na dispečink</p><p>206.     Další navrhovatelem namítanou skutečností je požadavek zadavatele na sledování polohy vozidla, jež plyne z funkčního předpokladu na odbavovací zařízení podle článku 1.2 přílohy č. 2 závazného návrhu smlouvy. Ten byl zadavatelem blíže specifikován v dodatečných informacích sada č. 4. Znalec dále při posuzování daných požadavků zadavatele vycházel také z dokumentu dodatečné informace sada č. 3 a přílohy č. 6 Závazný text smlouvy o plnění předmětu veřejné zakázky.</p><p>207.     S ohledem na závěry znalce uvedené v bodech 7.3.1., 7.3.2. a 7.4. znaleckého posudku (podrobně uvedeny v bodě 167. odůvodnění tohoto rozhodnutí) Úřad uvádí, že v zadávací dokumentaci k požadavkům zadavatele – na sledování polohy vozidel a odesílání dat o odbavení, případně další funkce v návaznosti na dispečink – zcela absentovaly následující informace či parametry:</p><p>-          popis zabezpečení komunikace;</p><p>-          popis datového formátu zasílaných zpráv včetně přesného popisu údajů s uvedením oboru hodnot, které se ve zprávách posílají;</p><p>-          použité kódování diakritiky;</p><p>-          popis druhu zpráv (požadavek – odpověď);</p><p>-          jasná specifikace událostí aktivující komunikaci.</p><p>208.     Na základě závěrů znaleckého posudku tak Úřad uvádí, že informace uvedené v zadávací dokumentaci k požadavkům zadavatele – na sledování polohy vozidel a odesílání dat o odbavení, případně další funkce v návaznosti na dispečink – nebyly s ohledem na zcela absentující informace či parametry definované v předcházejícím bodu odůvodnění tohoto rozhodnutí dostatečné pro to, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu sledování polohy vozidel a odesílání dat o odbavení, případně dalších funkcí, které mají být v návaznosti na dispečink k dispozici, zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují.</p><p>K dobíjení karet řidičem</p><p>209.     Navrhovatel v rámci svého návrhu ze dne 12. 12. 2016 také namítal údajnou neurčitost požadavku zadavatele na dobití karty řidičem, resp. konkrétně na to, které typy karet mají být řidičem v rámci odbavení cestujícího dobity.</p><p>210.     Ze zadávací dokumentace, resp. článku 1.2 přílohy č. 2 závazného návrhu smlouvy, vyplývá požadavek zadavatele v následujícím znění: „umístění tak, aby každý cestující mohl být odbaven řidičem v hotovosti nebo pomocí bankovní karty včetně dobití karty řidičem“. V dodatečných informacích sada č. 4  zadavatel dále uvedl, že dobitím karty se rozumí dobití dopravní karty Mifare Desfare EV1 (např. karty ODISka) v rámci přeshraniční spolupráce s Moravskoslezským krajem. Znalec vzal při posuzování daného požadavku zadavatele také v potaz dokument Struktura MSK karty, dokument Dopravní obslužnost – procesy MSK, dokument Dopravní obslužnost Datová věta pro MSK a dokument Informace o IDSOK.</p><p>211.     Úřad na základě závěrů znalce uvedených v bodech 8.3.1., 8.3.2. a 8.4. znaleckého posudku (podrobně uvedeny v bodě 168. odůvodnění tohoto rozhodnutí) uvádí, že v zadávací dokumentaci k požadavku zadavatele – dobíjení karet řidičem – nejsou uvedeny následující informace či parametry:</p><p>-          k implementaci PČK pod názvem ODISka (karta MSK):</p><p>bezpečnost (způsob zabezpečení relevantních aplikací - především elektronická peněženka, šifrování, práce s přístupovými klíči),</p><p>funkční požadavky na odbavovací zařízení v souvislosti s dobíjením elektronické peněženky,</p><p>informace k SAM modulu;</p><p>-          k implementaci dalších PČK (minimálně zde přichází v úvahu karta IREDO z Pardubického kraje, který s Olomouckým krajem sousedí, přičemž karta IREDO je postavená na technologii Mifare DESFire EVl, a dále IN karta státního dopravce Českých drah):</p><p>název konkrétní implementace PČK, resp. název karty,</p><p>struktura karty (aplikace, datové struktury, zejména informace k funkcionalitě elektronická peněženka),</p><p>procesy (týkající se samotného odbavení cestujícího, zejména informace k funkcionalitě elektronická peněženka),</p><p>bezpečnost (způsob zabezpečení relevantních aplikací - především elektronická peněženka, šifrování, práce s přístupovými klíči),</p><p>funkční požadavky na odbavovací zařízení v souvislosti s dobíjením elektronické peněženky,</p><p>případně definice způsobu rozúčtování (clearing) elektronické peněženky a/nebo jízdních produktů, pokud je clearing v systému využíván,</p><p>informace k SAM modulu (pokud je v systému implementován);</p><p>-          součástí implementace je i otázka poskytnutí licencí na každou požadovanou implementaci dopravní karty dodavateli OS od držitele této licence.</p><p>212.     Ze závěrů znaleckého posudku tak zcela jasně vyplývá, že informace uvedené v zadávací dokumentaci k požadavku zadavatele – dobíjení karet řidičem – nebyly s ohledem na chybějící informace či parametry specifikované v předcházejícím bodu odůvodnění tohoto rozhodnutí dostatečné pro to, aby si dodavatelé odbavovacích systémů mohli učinit reálnou představu o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení této funkcionality, tedy vytvoření a dodání odbavovacího systému schopného funkcionalitu odbavení a dobíjení karet řidičem zajistit, případně k ověření, zda již takovým odbavovacím systémem disponují.</p><p>Ke všem výše uvedeným pochybením</p><p>213.     Souhrnně tedy Úřad s ohledem na závěry znaleckého posudku uvádí, že informace uvedené v zadávací dokumentaci k výše specifikovaným technickým požadavkům zadavatele na odbavovací systém (zařízení), nebyly dostatečné pro to, aby si mohli dodavatelé učinit reálné představy o činnostech (jejich rozsahu, časové náročnosti a nákladech) nutných k zabezpečení zadavatelem požadovaných funkcionalit v rámci vytvoření a dodání odbavovacího systému, a jestliže si dodavatelé na základě zadavatelem poskytnutých informací nemohli učinit reálné představy o rozsahu, časové náročnosti a nákladech činností nutných k zabezpečení zadavatelem požadovaných funkcionalit v rámci vytvoření a dodání odbavovacího systému, nemohli být ani schopni na jejich základě podat odborně a cenově precizní a tedy i vzájemně porovnatelné nabídky. Úřad tak konstatuje, že zadávací podmínky v částech namítaných navrhovatelem nebyly vymezeny dostatečně tak, aby byli potenciální dodavatelé schopni na jejich základě podat odborně a cenově precizní a tedy i vzájemně porovnatelné nabídky.</p><p>214.     Úřad tedy uvádí, že zadavatel nevymezil předmět veřejné zakázky v podrobnostech nezbytných pro zpracování nabídky, když v zadávacích podmínkách neposkytl dostatečné informace v souvislosti s požadavky na následující funkcionality – akceptace časových kuponů na bankovních platebních kartách; komunikace s dispečerskou aplikací; zajištění komunikace se systémem e-shopu KIDSOK; integrace požadovaného systému odbavení (clearing); aplikační rozhraní a způsob komunikace odbavovacího systému s dispečerským systémem KIDSOK; požadavky na sledování polohy vozidel a odesílání dat o odbavení, případně další funkce v návaznosti na dispečink; dobíjení karet řidičem, čímž ze strany zadavatele nedošlo pouze k nedodržení postupu stanoveného v § 44 odst. 1 zákona, nýbrž zároveň došlo také k porušení zásady transparentnosti zakotvené v § 6 odst. 1 zákona, jelikož vzhledem k neposkytnutí dostatečných informací v zadávacích podmínkách v souvislosti s výše definovanými požadavky zadavatele nebyly zadávací podmínky stanoveny jasně, určitě a srozumitelně, čímž zároveň zadavatel učinil zadávací řízení na veřejnou zakázku nečitelným a nepřehledným.</p><p>215.     K argumentaci zadavatele, že „předmětem veřejné zakázky není vývoj odbavovacího zařízení, ale zajištění dopravní obslužnosti oblasti Jesenicko veřejnou linkovou dopravou.“ a že „definovat způsob vývoje odbavovacího zařízení není úkolem zadavatele.“, uvádí Úřad následující.</p><p>216.     Předně Úřad uvádí, že nijak nerozporuje tvrzení zadavatele, že „předmětem veřejné zakázky není vývoj odbavovacího zařízení (...)“, neboť v bodu III. odst. 1 zadávací dokumentace je mimo jiné jasně uvedeno, že „[p]ředmětem této veřejné zakázky je poskytování veřejných služeb v přepravě cestujících veřejnou linkovou dopravou s cílem zajištění dopravní obslužnosti Olomouckého kraje, oblast Jesenicko v délce trvání deseti let (dále jen „veřejné služby“ či „předmět zakázky“). Dopravní obslužností se rozumí zabezpečení dopravy po všechny dny v týdnu především do škol a školských zařízení, k orgánům veřejné moci, do zaměstnání, do zdravotnických zařízení poskytujících základní zdravotní péči a k uspokojení kulturních, rekreačních a společenských potřeb, včetně dopravy zpět, přispívající k trvale udržitelnému rozvoji územního obvodu.“ Nicméně zároveň lze také uvést, že předmět veřejné zakázky zadavatel vymezil prostřednictvím požadavků uvedených v zadávacích podmínkách, tj. i prostřednictvím požadavků na vybavení vozidel, jimiž bude přeprava cestujících zabezpečována, uvedených v příloze č. 2 závazného návrhu smlouvy, kde zadavatel stanovil technické a provozní standarty, které jsou dodavatelé, pokud se chtějí účastnit zadávacího řízení na veřejnou zakázku, povinni dodržet, resp. splnit. Přitom součástí požadavků zadavatele uvedených v příloze č. 2 závazného návrhu smlouvy byly i navrhovatelem namítané požadavky na odbavovací systém.</p><p>217.     Úřad tak seznal, že předmět veřejné zakázky, tj. poskytování veřejných služeb v přepravě cestujících veřejnou linkovou dopravou s cílem zajištění dopravní obslužnosti Olomouckého kraje, oblast Jesenicko, byl v posuzovaném případě vymezen mimo jiné i prostřednictvím požadavků zadavatele uvedených v příloze č. 2 závazného návrhu smlouvy (tedy mimo jiné i prostřednictvím požadavků zadavatele na odbavovací systém, jež v návrhu ze dne 12. 12. 2016 namítal navrhovatel).</p><p>218.     Jestliže má tedy zadavatel dle § 44 odst. 1 zákona povinnost vymezit předmět veřejné zakázky v podrobnostech nezbytných pro zpracování nabídky, lze ze strany Úřadu konstatovat, že stanovením navrhovatelem namítaných požadavků na odbavovací systém v příloze č 2 závazného návrhu smlouvy, když i jejich prostřednictvím byl vymezen předmět veřejné zakázky, této povinnosti zadavatel dle jednoznačných závěrů znaleckého posudku nedostál. Úřad tak uvedenou argumentaci zadavatele odmítá.</p><p>219.     Co se týče další argumentace zadavatele týkající se skutečnosti, že v zadávacích podmínkách, resp. v dodatečných informacích k některým požadovaným informacím uvedl, že je předá až vítěznému uchazeči (konkrétně se jednalo o popis tzv. greenlist xml souboru, o informace ke komunikaci s krajskou dispečerskou aplikací a o algoritmus výpočtu tokenu), a přitom se obhajoval ochranou dat, resp. bezpečnostními důvody, uvádí Úřad následující.</p><p>220.     Ve vztahu k algoritmu výpočtu tokenu se otázkou bezpečnosti zabýval znalec ve znaleckém posudku, konkrétně v bodech 2.3.1 a 2.3.2 znaleckého posudku, přičemž uvedl toto: „Pro generování tokenu z údajů bankovní platební karty je kromě tokenizačního algoritmu obecně nutné znát také tokenizační klíč nebo klíče. Z hlediska bezpečnosti zajištění citlivých údajů v rámci odbavovacího systému není možné (ani v rámci zadávací dokumentace) zveřejnit tzv. ostré klíče, tj. klíče, které jsou v systému reálně používané pro tokenizaci. V případě jejich zveřejnění, resp. úniku, by došlo k zásadnímu narušení bezpečnosti systému s dalekosáhlými dopady (ztráta reputace, možné porušení zákona o ochraně osobních informací, finanční ztráty). Situaci je však pro účely výběrového řízení možné řešit poskytnutím tzv. testovacích klíčů (klíče stejných parametrů obsahujících však jiné hodnoty) (…).“ a dále, že „[s]kutečností je, že ani tokenizační algoritmus ani tokenizační klíče nebyly v zadávací dokumentaci popsány, což bylo zdůvodněno bezpečnostními hledisky (…). Ke zdůvodnění objednatele k neposkytnutí tokenizačního algoritmu, kde objednatel zdůvodňuje neposkytnutí algoritmu bezpečností odbavovacího systému, lze říct následující: bezpečnost odbavovacího systému tak, jak jsou chápány použité bezpečnostní nástroje (hašovací funkce, tokenizační klíč), by měla být zajištěna prostřednictvím utajení tokenizačního klíče nebo klíčů. Vzhledem ke skutečnosti, že použití nestandartního algoritmu se z důvodu následné špatné HW kompatibility nepředpokládá, není důvod neposkytnout odkaz na jeden nebo více standardizovaných algoritmů, ze kterých jeden bude v odbavovacím systému použit (…). K poskytnutí tokenizačního klíče nebo klíčů v rámci zadávací dokumentace: jak bylo uvedeno výše, není možné zveřejnit tzv. ostré klíče, protože na jejich utajení je založena bezpečnost odbavovacího systému, bylo by to zásadní narušení jeho bezpečnosti. Vzhledem k potřebě znalosti parametrů tokenizačního klíče pro stanovení odhadu náročnosti implementace tokenizace do HW dodavatele odbavovacího systému (a to i v případě zajištění dodávky tohoto HW externím dodavatelem) lze tuto potřebu řešit poskytnutím tzv. testovacích klíčů (klíče stejných parametrů obsahujících však jiné hodnoty) (…).“ S ohledem na právě uvedené tak sice lze dát zadavateli v jeho argumentaci prostřednictvím bezpečnosti ohledně předání informací o algoritmu výpočtu tokenu až vítěznému uchazeči za pravdu, nicméně ve světle uvedeného závěru znaleckého posudku tato argumentace nemůže obstát, jelikož zadavatel měl možnost poskytnout v zadávacích podmínkách odkaz na jeden nebo více standardizovaných algoritmů, ze kterých jeden bude v odbavovacím systému použit a dále tzv. testovací klíče, čímž by dostál své povinnosti vyplývající mu z § 44 odst. 1 zákona a zároveň by vyhověl požadavku bezpečnosti, nicméně zadavatel této možnosti nevyužil.</p><p>221.     K tomuto Úřad dále uvádí, že nemůže obstát ani argumentace zadavatele bezpečnostními hledisky pro neposkytnutí informací k popisu tzv. greenlist xml souboru a ani informací ke komunikaci s krajskou dispečerskou aplikací, resp. pro jejich poskytnutí až vítěznému uchazeči. Úřad v této souvislosti podotýká, že § 152 zákona zadavateli umožňuje v zadávacích podmínkách stanovit požadavky a podmínky týkající se ochrany určitých informací, údajů či dokladů, které předává dodavateli, přičemž takto zadavatelem stanovené požadavky a podmínky ve vztahu k ochraně jím poskytovaných důvěrných informací jsou dodavatelé povinni bezvýhradně respektovat. Porušení těchto povinností a požadavků může být pro dodavatele spojeno se soukromoprávními následky, zejména v souvislosti se vznikem škody, která by porušením povinností a požadavků ve vztahu k důvěrným informacím zadavatele mohla vzniknout. Zadavatel tak měl v posuzovaném případě možnost řešit ochranu daných informací na základě § 152 zákona, čímž by zároveň dostál i své povinnosti vyplývající mu z § 44 odst. 1 zákona.</p><p>222.     Zadavatel také argumentoval v tom smyslu, že „částka na odbavovací zařízení v rámci ceny celé zakázky představuje pouze několik promile z ceny dopravního výkonu“, přičemž Úřad k tomuto uvádí následující.</p><p>223.     Úřad považuje uvedenou argumentaci za naprosto lichou, neboť dikce zákona je v tomto případě jasná. Z ustanovení § 44 odst. 1 zákona vyplývá povinnost zadavatele vymezit předmět veřejné zakázky v podrobnostech nezbytných pro zpracování nabídky, přitom zákon nerozlišuje, jak rozhodnou část tvoří jednotlivé cenové položky, ke kterým se zadávací podmínky vztahují, ve vztahu k celkové hodnotě veřejné zakázky. Tedy, aby zadavatel své povinnosti plynoucí mu z § 44 odst. 1 zákona dostál, je nutné vymezit v podrobnostech nezbytných pro zpracování nabídky všechny údaje, požadavky i podmínky, resp. zadávací podmínky, ať už se tyto zadávací podmínky týkají jakkoli marginální cenové položky ve vztahu k hodnotě celé veřejné zakázky.</p><p>224.     V rámci svého vyjádření ze dne 14. 5. 2018 zadavatel uvedl, že „má důvod se domnívat, že znalecký posudek je vypracován osobami, kteří nemají zcela přesné a konkrétní informace o praktické realizaci projektů v oblasti odbavení cestujících. Z posudku plyne formalismus a pouze teoretické znalosti pojmů, bez praktických zkušeností o implementaci těchto systému v provozu. Je pravděpodobné, že jiný znalec bude mít i jiný názor a pohled, než je uvedeno v tomto posudku.“ Jako příklad faktické realizace zadavatel uvedl projekt Multikanálového odbavovacího systému, který má mimo jiné umožnit využití bankovní karty jako nosiče časového jízdného, tedy dle zadavatele se jedná o stejnou funkcionalitu, která byla specifikována v rámci zadávacích podmínek k veřejné zakázce. Zadavatel uvedl, že „[v] rámci tohoto projektu výše uvedené společnosti byly schopny předložit dopravcům cenové nabídky na realizaci již v průběhu měsíce ledna 2018, i když v této době nebyla známa specifikace whitelistu ani jeho distribuce a popis datových toků, popis SAM modulu, předávání dat do clearingového centra, proces odbavení, kontrola mobilní aplikace a další technické informace. Tyto informace byly poskytnuty po podpisu NDA (smlouva o utajení informací) (…).“, k čemuž Úřad uvádí následující.</p><p>225.     Předně Úřad uvádí, že nemá žádné důvody pochybovat o tom, že znalec – České vysoké učení technické v Praze, fakulta dopravní, Ústav soudního znalectví v dopravě – je v oborech znalecké činnosti: doprava a spoje, na které se specializuje, jednoznačným odborníkem, který jistě disponuje dle slov zadavatele přesnými a konkrétními informacemi o praktické realizaci projektů v oblasti odbavení cestujících. Ostatně ani samotný zadavatel neuvedl žádné konkrétní důvody, na základě kterých by Úřad mohl usoudit opak. Úřad zde dodává, že znalecký ústav, který znalecký posudek vypracoval, je uznávaná univerzita a Úřad tak nemá nejmenších pochybností, že by se jednalo o osobu bez dostatečné odborného zázemí. K samotnému hodnocení znaleckého posudku Úřad odkazuje ke své argumentaci uvedené výše.</p><p>226.     Dále k argumentaci zadavatele prostřednictvím odkazu na projekt Multikanálového odbavovacího systému, který má mimo jiné umožnit využití bankovní karty jako nosiče časového jízdného, tedy dle zadavatele se jedná o stejnou funkcionalitu, která byla specifikována v rámci zadávacích podmínek k veřejné zakázce, Úřad uvádí, že projekt Multikanálového odbavovacího systému a zadávací řízení na veřejnou zakázku mají i přes podmínky obdobného charakteru (viz funkcionalita – využití bankovní karty jako nosiče časového jízdného) svá konkrétní odlišná specifika a má jimi být dosaženo uspokojení odlišných potřeb. Tudíž z porovnání podmínek stanovených u daného projektu a v rámci zadávacího řízení na předmětnou veřejnou zakázku, i když jsou tyto podmínky obdobného charakteru (viz funkcionalita – využití bankovní karty jako nosiče časového jízdného) nelze a priori činit závěry o dostatečnosti informací poskytnutých v zadávacích podmínkách na předmětnou veřejnou zakázku, tedy zároveň o vymezení předmětu posuzované veřejné zakázky v podrobnostech nezbytných pro zpracování nabídky. S ohledem na právě uvedené tak Úřad dané argumentaci zadavatele nemůže přisvědčit.</p><p>227.     Dále zadavatel v rámci své argumentace uvedené v jeho vyjádření ze dne 14. 5. 2018 uvedl, že „má písemně potvrzeno od několika odborných subjektů, že jsou schopni na základě poskytnutých informací předložit cenové nabídky. Tyto důkazy již zadavatel Úřadu poskytnul v předchozích vyjádřeních.“, k čemuž Úřad uvádí následující.</p><p>228.     Jak již Úřad uvedl výše, po zrušení napadeného rozhodnutí a vrácení věci Úřadu k novému projednání se v dalším průběhu správního řízení nepodařilo vyvrátit rozpor mezi jednotlivými tvrzeními společností BUSE s.r.o. a Bustec s.r.o., jelikož jak společnost BUSE s.r.o. ve svém vyjádření ze dne 2. 8. 2017 tak i společnost Bustec s.r.o. ve svém vyjádření ze dne 27. 7. 2017 setrvaly na svých předchozích vyjádřeních a shodně odmítly jakýkoliv rozpor v jejich předchozích vyjádřeních, přičemž společnost BUSE s.r.o. již na další žádosti Úřadu o informace ze dne 4. 8. 2017 a dne 22. 8. 2017 nereagovala a dále z dodavatelů navržených zadavatelem v jeho vyjádření ze dne 27. 7. 2017 (tj. společnost Merchant Payment Acquiring Services s.r.o. a společnost Diebold Nixdorf s.r.o.) reagoval na žádosti Úřadu o informace pouze jeden z nich. Úřad tak nemohl skutková zjištění opřít o vyjádření společností BUSE s.r.o. a Bustec s.r.o. ani jiných dodavatelů (tj. těch, které navrhoval zadavatel ve vyjádření ze dne 27. 7. 2017), tudíž Úřad zároveň nemohl posoudit reálnou schopnost potenciálních dodavatelů na základě konkrétně stanovených požadavků zadavatele podat nabídku v zadávacím řízení na veřejnou zakázku. Vzhledem k tomu, že má Úřad dle zásady materiální pravdy zakotvené v § 3 správního řádu povinnost zjistit stav věci, o němž nejsou důvodné pochybnosti a v rámci posuzování schopnosti potenciálních dodavatelů na základě konkrétně stanovených požadavků zadavatele podat nabídku v zadávacím řízení na veřejnou zakázku důvodné pochybnosti o stavu věci nadále přetrvávaly, přistoupil Úřad v souladu se závěry druhostupňového rozhodnutí k posouzení způsobu stanovení požadavků zadavatelem, tj. zda zadávací podmínky v rozsahu, v jakém byly uvedeny v zadávací dokumentaci, byly vymezeny dostatečně tak, aby byli potenciální dodavatelé schopni na jejich základě podat odborně a cenově precizní a tedy i vzájemně porovnatelné nabídky. Ve světle právě uvedeného tak daný argument zadavatele již nemůže obstát.</p><p>229.     K další argumentaci zadavatele rovněž uvedené v jeho vyjádření ze dne 14. 5. 2018, v jejímž rámci zadavatel uvedl následující: „V posudku je také uvedeno (kapitola 8. Dobíjení karet řidičem), že předložená dokumentace karty ODISKA je nedostatečná. S tímto tvrzením také nelze souhlasit. V rámci Moravskoslezského kraje proběhlo mnoho veřejných soutěží, kdy součástí byla tato dokumentace a proti této dokumentaci nebyly vzneseny žádné připomínky jak ze strany dopravců, tak ze strany dodavatelů odbavovacích systémů.“, Úřad uvádí toto.</p><p>230.     Zadavatel dle Úřadu nemůže z jím tvrzené skutečnosti, že v rámci Moravskoslezského kraje proběhlo mnoho veřejných soutěží, kdy součástí byla tato dokumentace a proti této dokumentaci nebyly vzneseny žádné připomínky jak ze strany dopravců, tak ze strany dodavatelů odbavovacích systémů, činit a priori závěr o dostatečnosti dokumentace karty ODISKA. Dodavatelé, resp. uchazeči o veřejné zakázky mají dánu možnost vznést námitky či dotazy k zadávacím podmínkám, nikoliv ovšem povinnost. Pokud tedy v zadavatelem uvedených případech nebyly vzneseny ať už ze strany dopravců či dodavatelů odbavovacích systémů žádné „připomínky“, nelze z této skutečnosti automaticky dospět k závěru, že dokumentace karty ODISKA je dostatečná. Uvedený argument zadavatele tak nic nedokazuje o souladu jeho postupu se zákonem a není současně ani schopen vyvrátit či alespoň zpochybnit uvedený závěr znaleckého posudku.</p><p>231.     Úřad tak s ohledem na výše uvedené uzavírá, že zadavatel nedodržel postup stanovený v § 44 odst. 1 zákona ve spojení se zásadou transparentnosti uvedenou v § 6 odst. 1 zákona, když v zadávacím řízení na veřejnou zakázku nevymezil předmět veřejné zakázky v podrobnostech nezbytných pro zpracování nabídky, neboť v zadávacích podmínkách neposkytl dostatečné informace v souvislosti s požadavky na následující funkcionality – akceptace časových kuponů na bankovních platebních kartách; komunikace s dispečerskou aplikací; zajištění komunikace se systémem e-shopu KIDSOK; integrace požadovaného systému odbavení (clearing); aplikační rozhraní a způsob komunikace odbavovacího systému s dispečerským systémem KIDSOK; požadavky na sledování polohy vozidel a odesílání dat o odbavení, případně další funkce v návaznosti na dispečink; dobíjení karet řidičem, čímž zároveň byla naplněna první podmínka pro uložení nápravného opatření spočívající v nedodržení postupu stanoveného pro zadání veřejné zakázky ze strany zadavatele.</p><p>232.     Úřad dále přistoupil k posouzení toho, zda byla naplněna podmínka podstatného vlivu na výběr nejvhodnější nabídky. K této otázce se vyjádřil např. Krajský soud v Brně v rozsudku č. j. 62 Af 120/2013-156 ze dne 26. 3. 2015, když uvedl, že „dospěje-li tedy žalovaný k závěru, že zadavatel ZVZ porušil, pak je dále rozhodující, zda takový úkon podstatně ovlivnil nebo mohl ovlivnit výběr nejvhodnější nabídky, tj. zda v příčinné souvislosti s porušením ZVZ ze strany zadavatele došlo nebo alespoň mohlo dojít k výběru jiné nabídky, než jak by bylo učiněno, pokud by zadavatel zákon neporušil. Podstatnost ovlivnění pořadí je tu třeba v zásadě dovozovat z výsledku posouzení skutečnosti, zda existuje alespoň potenciální možnost, že v důsledku porušení ZVZ zadavatelem se může stát vítězem zadávacího řízení jiná osoba, než by se jím stala za situace, pokud …“. Není tedy rozhodující, zda k ovlivnění výběru nejvhodnější nabídky skutečně došlo, ale postačí eventuální možnost ovlivnění. Lze tedy shrnout, že v případě, kdy zadavatel nedodrží postup stanovený zákonem, postačuje k uložení nápravného opatření potenciální možnost, že k podstatnému ovlivnění výběru nejvhodnější nabídky mohlo dojít. Stejné závěry vyplývají rovněž z vlastní rozhodovací činnosti Úřadu, kdy se v obdobném duchu vyjádřil předseda Úřadu, a to konkrétně např. ve svém rozhodnutí č. j. ÚOHS-R128/2014/VZ-19203/2014/321/MMl ze dne 12. 9. 2014.</p><p>233.     K podmínce podstatného vlivu na výběr nejvhodnější nabídky, respektive k jeho potencialitě tedy Úřad s ohledem na ustálenou rozhodovací praxi soudů a jeho vlastní rozhodovací činnost uvádí, že výše uvedené ve výsledku mohlo mít alespoň potenciální vliv na výběr nejvhodnější nabídky, neboť Úřad nemůže vyloučit, že pokud by na trhu existoval subjekt, který by měl zájem o plnění veřejné zakázky, neúčastnil by se pro nejasnost, resp. nedostatečnost informací stanovených v zadávacích podmínkách zadávacího řízení na veřejnou zakázku. Naopak, pokud by zadávací podmínky byly stanoveny v souladu se zákonem, tedy v podrobnostech nezbytných pro zpracování nabídky, není vyloučeno, že by zadavatel obdržel i nabídky jiných uchazečů, kteří by potenciálně mohli nabídnout plnění za výhodnějších podmínek, než tomu bylo v tomto případě. Úřad k tomuto dodává, že nejasnost, resp. nedostatečnost informací stanovených v zadávacích podmínkách zadávacího řízení na veřejnou zakázku prokazatelně znemožnila podat nabídku minimálně jednomu dodavateli, a to navrhovateli.</p><p>234.     Úřad tedy konstatuje, že podmínka pro uložení nápravného opatření spočívající v existenci alespoň potenciálního vlivu na výběr nejvhodnější nabídky je v daném případě naplněna, neboť postup zadavatele mohl podstatně ovlivnit výběr nejvhodnější nabídky.</p><p>235.     Pokud jde o poslední podmínku, Úřad konstatuje, že zadavatel dosud neuzavřel smlouvu na veřejnou zakázku. Jsou tak naplněny všechny zákonné podmínky pro to, aby Úřad mohl uložit nápravné opatření ve smyslu § 118 odst. 1 zákona.</p><p>236.     Vzhledem k výše uvedenému Úřad konstatuje, že zadavatel nedodržel postup stanovený v § 44 odst. 1 zákona ve spojení se zásadou transparentnosti uvedenou v § 6 odst. 1 zákona, když v zadávacím řízení na veřejnou zakázku nevymezil předmět veřejné zakázky v podrobnostech nezbytných pro zpracování nabídky, neboť v zadávacích podmínkách neposkytl dostatečné informace v souvislosti s požadavky na následující funkcionality – akceptace časových kuponů na bankovních platebních kartách, komunikace s dispečerskou aplikací, zajištění komunikace se systémem e-shopu KIDSOK, integrace požadovaného systému odbavení (clearing), aplikační rozhraní a způsob komunikace odbavovacího systému s dispečerským systémem KIDSOK, požadavky na sledování polohy vozidel a odesílání dat o odbavení, případně další funkce v návaznosti na dispečink; dobíjení karet řidičem, kdy tímto postupem mohl podstatně ovlivnit výběr nejvhodnější nabídky, a dosud nedošlo k uzavření smlouvy.</p><p>K dalším námitkám navrhovatele</p><p>237.     Ke zbylým námitkám navrhovatele uvedeným v jeho návrhu ze dne 12. 12. 2016, tj. neporovnatelnosti předložených nabídek a možnému zvýhodnění dodavatele TELMAX s. r. o., příp. stávajících dopravců ARRIVA MORAVA a. s. a First Transport Lines a. s., Úřad uvádí, že s ohledem na skutečnosti, že jednak s ohledem na tu skutečnost, že Úřad tyto námitky vnímá jako důsledky pochybení zadavatele – nesprávně nastavených zadávacích podmínek a také s ohledem na základní zásady činnosti správních orgánů, konkrétně zásadu rychlosti a hospodárnosti zakotvených v § 6 správního řádu, již nepovažuje za nutné uvedené námitky navrhovatele přezkoumávat.</p><p>IV.          ULOŽENÍ NÁPRAVNÉHO OPATŘENÍ</p><p>238.     Dle ustanovení § 118 odst. 1 zákona uloží Úřad nápravné opatření tím, že zruší zadávací řízení nebo soutěž o návrh nebo jen jednotlivý úkon zadavatele, nedodrží-li zadavatel postup stanovený pro zadání veřejné zakázky nebo pro soutěž o návrh, přičemž tento postup podstatně ovlivnil nebo mohl ovlivnit výběr nejvhodnější nabídky nebo návrhu, a dosud nedošlo k uzavření smlouvy.</p><p>239.     Úřad konstatuje, že zadavatel nedodržel postup stanovený v § 44 odst. 1 zákona ve spojení se zásadou transparentnosti uvedenou v § 6 odst. 1 zákona, když v zadávacím řízení na veřejnou zakázku nevymezil předmět veřejné zakázky v podrobnostech nezbytných pro zpracování nabídky, neboť v zadávacích podmínkách neposkytl dostatečné informace v souvislosti s požadavky na následující funkcionality – akceptace časových kuponů na bankovních platebních kartách, komunikace s dispečerskou aplikací, zajištění komunikace se systémem e-shopu KIDSOK, integrace požadovaného systému odbavení (clearing), aplikační rozhraní a způsob komunikace odbavovacího systému s dispečerským systémem KIDSOK, požadavky na sledování polohy vozidel a odesílání dat o odbavení, případně další funkce v návaznosti na dispečink; dobíjení karet řidičem, kdy tímto postupem mohl podstatně ovlivnit výběr nejvhodnější nabídky, a dosud nedošlo k uzavření smlouvy.</p><p>240.     Nedodržení zákonem stanoveného postupu ze strany zadavatele mohlo podstatně ovlivnit výběr nejvhodnější nabídky, jelikož pokud by postupoval v souladu s § 44 odst. 1 a s § 6 odst. 1 zákona, mohl obdržet i jiné, pro zadavatele výhodnější, nabídky od potenciálních dodavatelů.</p><p>241.     Úřad uvádí, že při rozhodování podle § 118 odst. 1 zákona je povinen na základě zjištěných skutečností uvážit, jaké nápravné opatření má zvolit k dosažení nápravy stavu.</p><p>242.     Vzhledem k tomu, že v šetřeném případě zadavatel pochybil již při vymezení zadávacích podmínek, a nezákonný postup uvedený ve výroku I. rozhodnutí mohl podstatně ovlivnit výběr nejvhodnější nabídky, přičemž dosud nedošlo k uzavření smlouvy, rozhodl Úřad o zrušení zadávacího řízení, jak je uvedeno ve výroku II. tohoto rozhodnutí.</p><p>V.            NÁKLADY ŘÍZENÍ</p><p>243.     Podle § 119 odst. 2 zákona je součástí rozhodnutí Úřadu podle § 118 zákona též rozhodnutí o povinnosti zadavatele uhradit náklady správního řízení (dále jen „náklady řízení“). Náklady řízení se platí paušální částkou, kterou stanoví prováděcí předpis. Vyhláška č. 328/2006 Sb., kterou se stanoví paušální částka nákladů řízení o přezkoumání úkonů zadavatele pro účely zákona o veřejných zakázkách (dále jen „vyhláška“), stanoví v § 1 odst. 1 vyhlášky, že paušální částku nákladů řízení o přezkoumání úkonů zadavatele, je zadavatel povinen uhradit v případě, že Úřad rozhodl podle § 118 zákona o zrušení zadání veřejné zakázky nebo jen jednotlivého úkonu zadavatele, a to ve výši 30.000,- Kč.</p><p>244.     Vzhledem k tomu, že tímto rozhodnutím došlo ke zrušení celého zadávacího řízení, rozhodl Úřad o uložení povinnosti zadavatele uhradit náklady řízení, jak je uvedeno ve výroku III. tohoto rozhodnutí.</p><p>245.     Náklady řízení jsou splatné do dvou měsíců od nabytí právní moci tohoto rozhodnutí na účet Úřadu pro ochranu hospodářské soutěže zřízený u pobočky České národní banky v Brně číslo 19-24825621/0710, variabilní symbol – 2016000747.</p><p>Poučení</p><p>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. Podle § 117c odst. 1 písm. b) zákona se rozklad a další podání účastníků učiněná v řízení o rozkladu činí v elektronické podobě podepsané uznávaným elektronickým podpisem.</p><p>otisk úředního razítka</p><p>JUDr. Eva Kubišová</p><p>místopředsedkyně</p><p>Obdrží</p><p>1.             Koordinátor Integrovaného dopravního systému Olomouckého kraje, příspěvková organizace, Jeremenkova 1211/40b, Hodolany, 779 00 Olomouc</p><p>2.             JUDr. Michal Lorenc, Žerotínova 1132/34, 130 00 Praha – Žižkov</p><p>Vypraveno dne</p><p>viz otisk razítka na poštovní obálce nebo časový údaj na obálce datové zprávy</p></div>", "next": 0}