Hodnocení demo prostředí v IT veřejných zakázkách: užitečný nástroj, nebo cesta k netransparentnosti?
Při zadávání veřejných zakázek v oblasti IT se zadavatelé stále častěji dostávají do situace, kdy samotný text nabídky neumožňuje dostatečně spolehlivě posoudit skutečnou kvalitu nabízeného řešení. U informačních systémů, softwarových platforem, portálových řešení, service desků, systémů spisové služby či jiných specializovaných aplikací totiž bývá rozdíl mezi deklarovanými vlastnostmi a reálnou použitelností systému mimořádně výrazný. Dodavatel může v nabídce bez větších obtíží popsat, že jeho řešení obsahuje určitou funkcionalitu, podporuje konkrétní workflow nebo umožňuje provedení určitého procesu. Mnohem obtížnější však je ověřit, zda je daná funkcionalita skutečně smysluplně implementována, zda je uživatelské rozhraní přehledné, zda uživatel nemusí pro jednoduchý úkon absolvovat nepřiměřené množství kroků a zda deklarovaná vlastnost není přítomna pouze formálně, aniž by byla v praxi dobře použitelná.
Článek se věnuje právním aspektům využití demo prostředí v zadávacích řízeních na IT plnění, přičemž autory lze zařadit mezi analytiky pohybující se na pomezí komentáře k judikatuře a praktického návodu pro zadavatele. Základní teze článku spočívá v tom, že demo prostředí lze v zadávacím řízení využít, avšak jeho právní přípustnost závisí na tom, zda zadavatel přesně vymezí jeho funkci, tedy zda slouží jako verifikační nástroj k ověření souladu na... více
Právě proto je pochopitelné, že zadavatelé u IT plnění často uvažují o využití demo prostředí. Jestliže mají vynaložit významné veřejné prostředky na digitální řešení, je z jejich pohledu logické chtít nabízený systém nejen formálně posoudit z hlediska naplnění zadávacích podmínek, ale také jej vidět, případně si ověřit, jak funguje při plnění typických úkonů. Chtějí zjistit, jak se v systému uživatel pohybuje, jak reaguje na zadání, jak jsou uspořádány jednotlivé obrazovky, zda je práce s ním intuitivní a zda deklarované vlastnosti nejsou pouze marketingovým popisem řešení, které je ve skutečnosti technicky nebo uživatelsky nedotažené. Taková úvaha je z věcného i ekonomického hlediska legitimní. Současně však právě zde začíná jedno z nejcitlivějších míst celého zadávacího procesu.
Problém totiž nespočívá v samotné myšlence, že má zadavatel možnost nabízené řešení vidět. Riziko vzniká až ve chvíli, kdy není právně a procesně přesně uchopeno, jakou roli má demo prostředí v zadávacím řízení plnit, co přesně má být jeho prostřednictvím posuzováno nebo hodnoceno, v jakém okamžiku má být hodnocené řešení fixováno a jaká je vazba mezi demo prostředím a obsahem nabídky. Právě v těchto otázkách se střetává praktická potřeba „systém opravdu vidět“ se základními zásadami zadávání veřejných zakázek, zejména se zásadou transparentnosti a rovného zacházení.
Tři základní modely práce s demo prostředím
Z právního hlediska je vhodné na úvod odlišit tři základní modely, s nimiž se lze v praxi setkat. Prvním je situace, kdy je demo prostředí součástí nabídky pro účely posouzení splnění technických podmínek. Zadavatel v takovém případě požaduje, aby dodavatel již v nabídce předložil určitou formu funkčního nebo alespoň částečně funkčního zachycení nabízeného řešení pro účely posouzení splnění technických podmínek. Druhým modelem je demo prostředí jako nástroj k ověření pravdivosti údajů uvedených v nabídce. Demo prostředí se zde samo nestává součástí nabídky v tom smyslu, že by bylo hodnoceným obsahem nabídky, ale slouží k tomu, aby si zadavatel ověřil, že to, co dodavatel v nabídce tvrdí, je skutečně reálně dostupné a funkční. Typicky může jít o předložení v rámci součinnosti vybraného dodavatele před uzavřením smlouvy nebo v rámci objasňování nabídky dle § 46 ZZVZ. Třetím modelem je demo prostředí jako kritérium hodnocení nabídek.
Právě třetí model je z pohledu zásad zadávání veřejných zakázek nejrizikovější. Pokud totiž zadávací podmínky nejsou nastaveny dostatečně jasně a jednoznačně, může vzniknout prostor pro úpravy demo prostředí i po uplynutí lhůty pro podání nabídek. Jestliže by se takové úpravy dotkly parametrů, které jsou předmětem hodnocení, znamenalo by to, že zadavatel ve skutečnosti hodnotí nabídku v podobě, jež již neodpovídá jejímu stavu ke dni podání nabídky. Tím by byla narušena zásada neměnnosti nabídky v hodnoceném parametru ve smyslu § 46 ZZVZ a v důsledku toho i zásada transparentnosti a rovného zacházení.
Je proto nezbytné, aby zadavatel už při přípravě zadávacích podmínek přesně věděl, zda chce demo prostředí použít jako nástroj pro potvrzení tvrzených technických parametrů nabízeného řešení, nebo jako hodnoticí kritérium. Smíšení těchto modelů bez jasného vymezení jejich funkce představuje samo o sobě významné právní riziko. Čím méně je totiž zřejmé, co je vlastně předmětem posouzení a kdy má být dané řešení „zafixováno“, tím obtížněji lze následně obhájit, že zadavatel postupoval transparentně a vůči všem dodavatelům stejně.
Demo prostředí a požadavek neměnnosti nabídky
Velmi důležité vodítko v tomto směru poskytuje např. rozhodnutí Úřadu pro ochranu hospodářské soutěže („ÚOHS“) ze dne 8. 3. 2021, sp. zn. ÚOHS-S0434/2020/VZ (potvrzeno rozkladovým rozhodnutím předsedy ÚOHS ze dne 17. 5. 2021, sp. zn. ÚOHS-R0059/2021/VZ). Z něj vyplývá, že prezentace řešení může sloužit k ověření údajů uvedených v nabídce, nikoli k jejich následnému rozšíření. Rozhodující je vždy stav řešení ke dni podání nabídky. V praxi to znamená, že pokud zadavatel umožní prezentaci demo prostředí, musí zajistit, aby prezentované řešení odpovídalo tomu, co bylo obsahem nabídky, a nedocházelo k jeho dodatečnému rozšiřování nebo úpravám v rozsahu, který by mohl ovlivnit posouzení či hodnocení nabídky. Jakékoli odchylky od tohoto principu mohou vést k závěru o porušení zásady transparentnosti a rovného zacházení.
V posuzované věci zadavatel požadoval, aby součástí nabídky byla kompletní prezentace prototypu, a současně připustil živou prezentaci, avšak pouze jako ověření pravosti údajů již obsažených v nabídce. Podstatné přitom bylo, že živá prezentace měla odpovídat tomu, co bylo předloženo v nabídce, a nesměla být oproti nabídce rozšířena. Rozhodný byl stav ke dni podání nabídky, nikoli případná pozdější technická možnost řešení dále upravovat.
Tento závěr je pro celé téma hodnocení demo prostředí zásadní. Ukazuje, že zadavatel může s demo prostředím pracovat, avšak pouze za předpokladu, že je zřejmé, že tím nevzniká prostor pro dodatečné dopracování soutěženého řešení. Software je totiž svou povahou dynamický, snadno konfigurovatelný a rychle upravitelný. Právě proto je v jeho případě riziko dodatečných změn výrazně vyšší než u mnoha jiných druhů plnění. Pokud zadavatel nestanoví, že demo prostředí musí odrážet stav řešení ke dni podání nabídky, pokud nevymezí konkrétní okruh funkcionalit a workflow, které mají být předvedeny, a pokud výslovně nezakáže jejich pozdější rozšiřování nebo úpravy ovlivňující hodnocené parametry, vytváří tím značný prostor pro netransparentnost a v zásadě tím dodavatelům umožňuje do demo prostředí zasahovat i po uplynutí lhůty pro podání nabídek.
Současně však nestačí pouze deklarovat, že ke změnám dojít nesmí. Je nejen potřeba, aby ke změně nedošlo, ale zejména zajistit, aby k ní dojít ani nemohlo, případně aby bylo alespoň možné spolehlivě ověřit, že ke dni hodnocení nabídek s předkládaným řešením manipulováno nebylo. Právě zde se ukazuje, že právní formulace a technické nastavení musí jít ruku v ruce. Bez této vazby by i dobře míněné požadavky mohly v praxi selhat.
Když se demo prostředí stává předmětem hodnocení
Vedle otázky neměnnosti nabídky je druhým velkým tématem subjektivita kvalitativních kritérií, zejména tam, kde chce zadavatel hodnotit aspekty jako uživatelská přívětivost, intuitivnost, logika workflow, přehlednost rozhraní nebo ergonomie práce se systémem. Taková kritéria nejsou sama o sobě nepřípustná. Naopak právě v IT zakázkách může být jejich použití zcela rozumné, protože čistě číselně měřitelné parametry často nevystihují skutečnou kvalitu systému z pohledu budoucích uživatelů.
Problém však nastává tehdy, když jsou tato kritéria ponechána v příliš abstraktní rovině. Pojmy jako „intuitivní“, „uživatelsky přívětivé“ nebo „moderní“ sice působí srozumitelně, ale bez bližší konkretizace ponechávají hodnotitelům příliš široký prostor pro uvážení, což může učinit výsledek hodnocení nepřezkoumatelným. Dodavatelé pak nejsou předem jednoznačně seznámeni s tím, jaké parametry budou ve skutečnosti hodnoceny a jaké vlastnosti mají pro získání vyššího bodového ohodnocení akcentovat. Právě zde vzniká riziko nepřezkoumatelnosti a podezření ze svévole zadavatele či hodnoticí komise.
Odborná literatura i rozhodovací praxe přitom dlouhodobě vycházejí z toho, že subjektivní kritéria jsou možná, ale jen tehdy, pokud jsou popsána dostatečně určitě a nevzbuzují pochybnosti o možném svévolném hodnocení. U demo prostředí to platí dvojnásob. Zatímco u písemných parametrů předložených v nabídce lze často relativně snadno doložit, z čeho bodové hodnocení vycházelo, u živého předvedení systému je riziko neuchopitelnosti a nejednotného posuzování výrazně vyšší.
Proto je vhodné, aby zadavatel abstraktní kvalitativní pojmy rozložil do konkrétnějších pozorovatelných prvků. Může jít například o počet kroků potřebných k provedení běžné operace, konzistenci navigace napříč systémem, logiku přechodů mezi jednotlivými obrazovkami, srozumitelnost validačních nebo chybových hlášek, úroveň kontextové nápovědy, přítomnost vyhledávání, přehlednost formulářů, způsob filtrování nebo rychlost, s jakou je uživatel schopen dojít k cílovému úkonu. Takové zpřesnění sice nezmění kvalitativní hodnocení v čistě objektivní matematické srovnání, může však významně snížit prostor pro svévoli a zvýšit obhajitelnost výsledku v případě námitek nebo přezkumu před ÚOHS.
Praktický význam strukturovaných hodnoticích pravidel
V praxi se lze setkat i s případy, kdy zadavatel pracuje s demo prostředím jako s hodnoticím kritériem a snaží se jeho posouzení strukturovat prostřednictvím dílčích parametrů a bodovacích škál. Takový přístup může přispět ke zvýšení transparentnosti hodnocení, zejména pokud jsou jednotlivé aspekty kvality řešení předem rozděleny a popsány a pokud je průběh prezentace řádně dokumentován.
Ani takto propracovaný model však není bez rizika. I zde totiž zůstává otázkou, zda jsou použité kvalitativní pojmy skutečně rozloženy do dostatečně konkrétních pozorovatelných znaků a zda je z dokumentace zadavatele následně patrné, proč bylo jedno řešení hodnoceno jako „velmi dobré“ a jiné jen jako „dobré“. Právě tento aspekt bývá v přezkumu klíčový. Nestačí totiž, aby zadavatel měl vnitřní představu o tom, co považuje za kvalitnější řešení. Tato úvaha musí být z dokumentace zadávacího řízení zpětně srozumitelně rekonstruovatelná.
Jinými slovy, čím více je demo prostředí využíváno k vlastnímu hodnocení nabídek, tím vyšší musí být nároky na předem stanovená pravidla, na vnitřní konzistenci hodnoticího mechanismu i na kvalitu následného odůvodnění. Zadavatel si v tomto směru nemůže vystačit s obecnou formulací, že komise posoudí kvalitu řešení podle odborného dojmu. Takový přístup by byl pro přezkum jen obtížně obhajitelný.
Demo prostředí jako verifikační nástroj
Z hlediska právní opatrnosti představuje bezpečnější model situace, kdy demo prostředí neslouží jako samostatné kritérium hodnocení, ale pouze jako nástroj k ověření souladu nabídky se skutečností. Vybraný dodavatel v takovém případě před uzavřením smlouvy zpřístupní zadavateli demo prostředí za účelem ověření, zda skutečně nabízí požadované a již případně hodnocené funkcionality.
Z pohledu zadávání veřejných zakázek lze tento model považovat za model, který je pro aplikaci obecně „snazší“ z hlediska transparentnosti než bodové hodnocení živého demo prostředí po podání nabídky. Kvalita nabízeného řešení zde ale do soutěže vstupuje pouze omezeně, protože demo prostředí nepřináší samo o sobě konkurenční výhodu v podobě vyššího bodového ohodnocení. Zadavatel tímto způsobem získává praktickou možnost systém vidět, s výhodou toho, že tím výrazně nerozšiřuje prostor pro obranu směřující proti subjektivnímu hodnocení nebo proti tomu, že hodnotil řešení v jiné podobě, než v jaké bylo nabídnuto.
To ovšem neznamená, že by i v tomto modelu mohl zadavatel rezignovat na jasné vymezení pravidel. I zde je třeba přesně určit, co má být v demo prostředí ověřováno, jaká je vazba mezi deklaracemi v nabídce a předváděným řešením a jaké budou důsledky toho, pokud se ukáže, že deklarované vlastnosti v demo prostředí ověřit nelze. Výhodou však je, že zadavatel zde nehodnotí širší kvalitativní dojem z řešení, ale pouze soulad mezi tvrzením dodavatele a realitou.
Technická a organizační standardizace předvedení
Zcela samostatnou, avšak v praxi velmi významnou otázkou je organizace a technická standardizace samotného testu nebo prezentace nabízeného řešení. Právě zde totiž velmi snadno vznikají nerovné podmínky mezi dodavateli. Rozdílná délka prezentace, odlišná technická infrastruktura, použití vlastního hardwaru, rozdílná kvalita internetového připojení, odlišné testovací účty nebo možnost zásahu administrátora „na pozadí“ mohou mít na výsledek větší dopad, než se na první pohled zdá.
Je proto vhodné, aby zadavatel těmto aspektům věnoval pozornost již při přípravě zadávacích podmínek a samotného procesu hodnocení. Čím standardizovanější budou podmínky prezentace, tím menší bude riziko, že výsledné hodnocení bylo ovlivněno technickými okolnostmi, které s kvalitou nabízeného řešení věcně nesouvisí. V případě demo prostředí totiž může být i relativně drobná odchylka v průběhu testování vnímána jako zásah do rovnosti soutěžních podmínek.
Současně by zadavatelé neměli podceňovat otázku, kdo má k demo prostředí po podání nabídky přístup a jaké zásahy může provádět. Právě tam, kde je demo prostředí provozováno v cloudovém prostředí dodavatele, je riziko dodatečných zásahů přirozeně vyšší. Jestliže má mít požadavek na neměnnost řešení skutečný význam a validitu, musí být doplněn i odpovídajícími technickými a procesními opatřeními.
Jak omezit možnost změn a jak je odhalit
Pokud má být princip neměnnosti demo prostředí reálně vymahatelný, nestačí jej pouze deklarovat v zadávací dokumentaci. Je nutné jej doplnit konkrétními opatřeními, která jednak omezí možnost změn, jednak umožní jejich případnou detekci. V praxi se proto jako vhodné jeví požadovat, aby demo prostředí bylo zpřístupněno v režimu, který neumožňuje zásahy dodavatele do hodnocených funkcionalit. Může jít například o omezení přístupových práv, vyloučení administrátorských oprávnění nebo zákaz aktualizací a změn konfigurace po podání nabídky.
Vedle toho je důležité zajistit i auditovatelnost demo prostředí, tedy možnost zpětně ověřit, zda k zásahu do systému nedošlo. Toho lze dosáhnout například prostřednictvím logování změn, evidence nasazení nových verzí či jiných technických zásahů. Praktický význam může mít rovněž identifikace konkrétní verze řešení, například označením buildů nebo jiným způsobem, který umožní porovnat stav systému v okamžiku podání nabídky a v okamžiku jeho zobrazení pro účely hodnocení.
Nejde přitom o to, aby zadavatel v zadávací dokumentaci detailně předepsal kompletní technickou architekturu řešení. Podstatné je spíše to, aby zvolil taková opatření, která budou přiměřená povaze předmětu plnění a která mu umožní obhájit, že s demo prostředím po lhůtě pro podání nabídek nebylo manipulováno způsobem relevantním pro hodnocení nebo posouzení nabídky.
Vazba mezi nabídkou a demo prostředím
Z hlediska právního posouzení je zásadní i vazba mezi obsahem nabídky a samotným předvedením demo prostředí. Předvedení a testování nesmí sloužit k doplnění nebo rozšíření nabídky, ale pouze k ověření toho, co bylo v nabídce již deklarováno, případně k hodnocení těch vlastností, které měly být podle zadávacích podmínek fixovány již ke dni podání nabídky. Zadavatel by proto měl v zadávací dokumentaci výslovně stanovit, že prezentované řešení musí odpovídat stavu popsanému v nabídce a nesmí obsahovat nové nebo upravené funkcionality, které by mohly ovlivnit hodnocení nebo posouzení.
Praktickým nástrojem k naplnění tohoto požadavku může být vytvoření předem definovaného rámce hodnocení či ověření, například ve formě testovacích scénářů nebo přesně vymezeného seznamu funkcionalit, které mají být v demo prostředí předvedeny. Tím se výrazně snižuje prostor pro dodatečné „vylepšování“ řešení a současně se posiluje přezkoumatelnost celého procesu. Zadavatel tím zároveň dává všem dodavatelům předem srozumitelnou informaci o tom, co bude v demo prostředí relevantní.
Neméně důležitým aspektem je i dokumentace samotného průběhu hodnocení nebo ověřování demo prostředí. Vzhledem k tomu, že zejména u kvalitativního hodnocení zpravidla existuje určitá míra subjektivního posouzení, je nezbytné, aby byl celý proces transparentně zachycen. V praxi se proto doporučuje nejen podrobné odůvodnění bodového hodnocení jednotlivých nabídek, ale i zaznamenání samotného průběhu testování, například ve formě audiovizuálního záznamu.
Takový postup může významně přispět k obhajitelnosti postupu zadavatele v případném přezkumném řízení. Nestačí totiž jen konstatovat, že komise určité řešení považovala za přehlednější nebo intuitivnější. Z dokumentace by mělo být patrné, z jakých konkrétních skutečností tento závěr vyplynul, jak byl zaznamenán průběh prezentace a jak byly aplikovány předem stanovené hodnoticí parametry.
Dopad požadavku na demo prostředí na lhůtu pro podání nabídek
Zadavatelé by neměli podceňovat ani dopad požadavku na demo prostředí na přiměřenost lhůty pro podání nabídek. Pokud zadávací dokumentace vyžaduje vytvoření funkčního prototypu, demo prostředí nebo jiného sofistikovaného podkladu pro prezentaci řešení, je zjevné, že příprava nabídky bude časově i ekonomicky výrazně náročnější. V takové situaci nelze bez dalšího vycházet z toho, že postačí zákonná minimální lhůta pro podání nabídek.
Rozhodovací praxe správních soudů i ÚOHS přitom opakovaně zdůrazňuje (např. v rozhodnutí ÚOHS ze dne 23. 2. 2024, sp. zn. ÚOHS-S0753/2023/VZ), že lhůta není přiměřená jen proto, že formálně splní minimální zákonné požadavky. Musí reflektovat rozsah a složitost zakázky i reálnou náročnost zpracování nabídky. Pokud tedy zadavatel požaduje, aby dodavatelé pro účely účasti v zadávacím řízení připravili demo prostředí nebo jiný technicky náročný výstup, měl by tomu přizpůsobit i délku lhůty pro podání nabídek. Jiný postup může vyvolat pochybnosti o tom, zda soutěžní podmínky byly nastaveny přiměřeně a zda nevedly k nepřiměřenému omezení hospodářské soutěže nebo zvýhodňování určitých dodavatelů.
Doporučení pro zadavatele
Z výše uvedeného plyne několik doporučení. Zadavatel by si měl především hned na počátku ujasnit, proč demo prostředí vůbec požaduje. Pokud mu jde zejména o ověření, že nabídka odpovídá skutečnosti a že deklarované funkcionality skutečně existují, bude zpravidla vhodnější pracovat s demo prostředím jako s verifikačním nástrojem. Pokud naopak chce demo prostředí skutečně hodnotit a na jeho základě ovlivnit pořadí nabídek, musí být podstatně obezřetnější. Musí totiž předem určit, co je hodnoceným obsahem nabídky, jak bude zajištěna vazba mezi nabídkou a demo prostředím, které vlastnosti musí být fixovány ke dni podání nabídky a jak zabrání jejich pozdějším úpravám.
V případě hodnocení demo prostředí by mělo být dále stanoveno, že hodnocené demo prostředí nesmí být po uplynutí lhůty pro podání nabídek měněno. Není například vhodné, aby zadavatel umožnil pouze předložení přihlašovacích údajů do prostředí, které zůstává i po uplynutí lhůty plně v dispozici dodavatele, aniž by současně nastavil mechanismy umožňující ověřit, zda s ním nebylo manipulováno.
Závěrem
Klíčovou otázkou tedy není, zda demo prostředí jako takové v zadávacím řízení použít lze. Rozhodující je, zda je zadavatel schopen jeho využití právně i procesně uchopit tak, aby bylo zřejmé, co má být jeho prostřednictvím ověřováno nebo hodnoceno, v jakém okamžiku je relevantní stav řešení fixován a jak je zajištěno, že po tomto okamžiku nedochází k nepřípustným změnám. Legitimita využití demo prostředí je proto podmíněna tím, zda zadavatel dokáže zajistit jeho faktickou i právní neměnnost, transparentní pravidla jeho využití a dostatečnou dokumentaci průběhu hodnocení či ověření.
Demo prostředí jako součást nabídky dodavatele samo o sobě problémem není. Problém vzniká až tehdy, je-li demo prostředí vymezeno neurčitě, proměnlivě nebo je jeho využití nedostatečně zdokumentováno. Zadavatelé by je proto neměli vnímat jako pouhý doplněk, který jim pomůže udělat si lepší představu o nabízeném řešení. Jakmile se demo prostředí stává součástí hodnocení nebo podmínkou pro závěr o kvalitě nabízeného řešení, je třeba s ním pracovat jako s plnohodnotnou součástí soutěžního mechanismu se všemi důsledky pro transparentnost, rovné zacházení, přezkoumatelnost a neměnnost nabídky. Právě v tom spočívá rozdíl mezi legitimním a užitečným nástrojem pro posouzení kvality IT řešení a mezi postupem, který může být v přezkumu úspěšně napaden jako netransparentní nebo nepřezkoumatelný.
JUDr. Martin Flaškár,
advokát
Mgr. Denisa Přichystalová,
advokátka
Chrenek, Toman, Kotrba advokátní kancelář spol. s r.o.
Těšnov 1/1059
110 00 Praha 1
Tel: +420 221 875 402-9
E-mail: kancelar@chtk.cz
© EPRAVO.CZ – Sbírka zákonů, judikatura, právo | www.epravo.cz
