Source: https://rowan.legal/hodnoceni-funkcniho-prototypu-sw-is/
Timestamp: 2020-08-14 02:29:38+00:00

Document:
Hodnocení funkčního prototypu SW/IS – ROWAN LEGAL
Autoři: JUDr. Jiří Votrubec, Mgr. Ing. Kristýna Trávníčková
Vyšlo: Veřejné zakázky 5/2018
Prototyp ve veřejné zakázce na software či informační systém jako předmět hodnocení považujeme za vhodný nástroj pro zajištění dodání kvalitního plnění. Prototyp lze (v teoretické rovině) využít téměř u každé veřejné zakázky na software či informační systém, a to při dodržení základních zásad zadávacího řízení a pravidel pro stanovení hodnocení dle ZZVZ. Při hodnocení prototypu musí zadavatel zejména vymezit jasně a srozumitelně hodnotící kritéria, aby bylo zřejmé, co přesně bude posuzováno a jaké vlastnosti budou hodnoceny lépe. Dále je vhodné uvést podrobný popis způsobu hodnocení (například bodovou škálou), metody, na jejichž základě bude prototyp hodnocen, a prostředí, ve kterém bude prototyp instalován a testován. Zadavatel je povinen stanovit lhůtu pro podání nabídek takovým způsobem, aby všichni dodavatelé, kteří se chtějí zadávacího řízení zúčastnit, měli dostatek času pro vytvoření požadovaného prototypu. Předmětem hodnocení by měly být pouze ty parametry, které považuje zadavatel za významné ve vztahu k prototypu samotnému, které odpovídají charakteru a složitosti veřejné zakázky a které umožňují zadavateli objektivně prototyp vyhodnotit. Hodnotící kritéria mohou být subjektivní jako například uživatelská přívětivost nebo kvalita návrhu architektury, nicméně na jejich hodnocení jsou kladeny vyšší nároky, nebo objektivní, která jsou matematicky měřitelná jako počet možných způsobů vyhledávání. Pro stanovení způsobu hodnocení doporučujeme přizvat odborníky, kteří se poté budou na samotném hodnocení podílet (například coby hodnotící komise). Průběh testování a hodnocení musí být poté vždy transparentně zachycen v dokumentaci o zadávacím řízení.
Veřejné zakázky související s informačními systémy nebo software obecně jsou v poslední době jednou z nejvíce se rozvíjejících oblastí veřejných zakázek, která s sebou však přináší nové aspekty související s jejich zadáváním v souladu se zákonem č. 134/2016 Sb., o zadávání veřejných zakázek (dále jen „ZZVZ“). Ve své praxi se stále častěji setkáváme s požadavkem zadavatele na předložení prototypu poptávaného systému, na jehož základě by zadavatel mohl rozhodnout o výběru dodavatele, jenž mu předloží prototyp nejlépe naplňující jeho požadavky. Zadavatelé si však často nejsou jisti, zda mohou předložení prototypu požadovat, případně jakým způsobem a v jakém rozsahu mohou tento postup realizovat. Účelem následujícího článku je tedy vyjasnění otázek souvisejících s hodnocením prototypu, aby zadavatelé mohli tohoto institutu využívat v souladu se ZZVZ.
Zadavatel může pro hodnocení nabídek v zadávací dokumentaci stanovit (zjednodušeně řečeno) jakákoli hodnotící kritéria, přičemž při jejich vymezení je vázán toliko pravidly stanovenými ZZVZ. Základní zásadou, jež musí být při vymezení hodnotící kritérií dodržena, je, že se hodnotící kritéria musí vztahovat k předmětu veřejné zakázky, přičemž musí vyjadřovat objektivní a ověřitelné skutečnosti s předmětem veřejné zakázky související.[1] Za objektivní a ověřitelné skutečnosti je nutno považovat skutečnosti, které jsou objektivním a ověřitelným způsobem vyjádřitelné a seznatelné, tj. jedná se o takové skutečnosti, z nichž lze bezpečně zajistit údaj, který má sloužit k porovnání.[2] Může se tedy jednat jak o objektivní, tak i subjektivní kritéria hodnocené na základě volního uvážení zadavatele, stěžejní povinností zadavatele však je dostatečně podrobně tato kritéria vymezit.
Předmětem hodnocení tak může být i funkční prototyp software či informačního systému. Funkční prototyp je v kontextu ZZVZ považován za vzorek požadovaného plnění, přičemž ZZVZ dává zadavateli možnost zvolit, zda bude požadovat prototyp jako součást technické kvalifikace dle § 79 odst. 2 písm. k) ZZVZ, zda jej učiní předmětem hodnocení nebo jej bude požadovat v rámci dalších podmínek pro uzavření smlouvy dle § 104 ZZVZ. Záleží pouze na uvážení zadavatele, který z uvedených postupů zvolí, nicméně každý z těchto postupů skýtá určité výhody i nevýhody. Předmětem tohoto článku však není podrobný popis rozdílů mezi jednotlivými přístupy, proto autoři tohoto článku pouze stručně uvádějí, že v případě využití prototypu jako součásti kvalifikace zadavatel musí vymezit určité neměnné parametry prototypu a poté pouze posuzuje, zda byly splněny či nikoli. Jestliže prototyp vykazuje určité nedostatky, mohou být tyto nedostatky postupem dle § 46 ZZVZ odstraněny (zhojeny). Ustanovení § 46 odst. 1 ZZVZ totiž umožňuje, aby zadavatel vyzval účastníka k objasnění předložených údajů, dokladů, vzorků nebo modelů nebo doplnil další nebo chybějící údaje, doklady, vzorky nebo modely. Prototyp dodaný v souladu s požadavky zadavatele jako součást kvalifikace dodavatele svědčí o schopnosti dodavatele splnit předmět veřejné zakázky.
Prototyp, který je předmětem hodnocení, je zadavatelem posuzován z hlediska způsobilosti stát se předmětem plnění dle veřejné zakázky. Zadavatel tak může na základě provedeného hodnocení vybrat prototyp s lepšími než minimálně stanovenými parametry, nicméně na zadávací podmínky ve vztahu k hodnocenému prototypu jsou kladeny vyšší nároky. V případě jakéhokoli nedostatku v předloženém prototypu však nelze využít postupu dle § 46 ZZVZ k jejich odstranění, jelikož § 46 odst. 2 ZZVZ ve větě druhé stanoví, že nabídka může být doplněna na základě žádosti podle odstavce 1 o údaj, doklady, vzorky nebo modely, které nebudou hodnoceny podle kritérií hodnocení. U prototypu, jenž je předmětem hodnocení, je tak na základě uvedeného možnost jeho následných úprav, doplnění či objasnění vyloučena.
Zadavatel může dále požadovat předložení prototypu až ve fázi před uzavřením smlouvy. V případě tohoto postupu je prototyp vyžadován pouze od vybraného dodavatele, prototyp tak nemusejí předkládat všichni účastníci zadávacího řízení již ve své nabídce, ale předkládá jej pouze vybraný dodavatel až na základě výzvy zadavatele před uzavřením smlouvy. Zadavatel může zvolit tento postup zejména v případě, kdy by vyžadování prototypu od všech účastníků v zadávacím řízení bylo nepřiměřeně zatěžující nebo zbytečné. Výhodou vyžadování prototypu až před uzavřením smlouvy je, že povinnost doložení prototypu nemusí zadavatel oproti jeho vyžadování v rámci kvalifikace nebo hodnocení, jak bude rozvedeno dále, reflektovat při stanovení lhůty pro podání nabídek. I v tomto případě může zadavatel v případě určitých nedostatků využít institutu žádosti o objasnění či doplnění dle § 46 ZZVZ. Tento postup však skýtá riziko, že bude vybraným dodavatelem předložen prototyp v nedostatečné kvalitě nesplňující zadávací podmínky a zadavatel bude nucen vybraného dodavatele vyloučit. V takovém případě bude muset provést výběr dodavatele opakovaně, což je administrativně náročnější než v případě, kdy by dotčeného dodavatele vyloučit již na základě prototypu předloženého v rámci kvalifikace. Nadto se může zadavatel dostat do situace, kdy vybraný dodavatel je jediným účastníkem řízení, jelikož ostatní účastníky zadavatel vyloučil a po vyloučení vybraného dodavatele tak zadavatel bude muset přistoupit ke zrušení zadávacího řízení.
Nyní se ale vraťme a nadále se soustřeďme již jen na problematiku hodnocení prototypu. V případě, že se zadavatel rozhodne učinit předmětem hodnocení prototyp informačního systému nebo software, musí zejména vymezit požadavky na toto hodnocení transparentním způsobem, tedy uvést přesnou specifikaci hodnotících kritérií, podrobný popis způsobu hodnocení a metody, na jejichž základě bude prototyp hodnocen. Rozhodovací praxe Úřadu pro ochranu hospodářské soutěže (dále jen „ÚOHS“) v tomto kontextu opakovaně konstatovala, že nejzásadnější otázkou při stanovení dílčích hodnotících kritérií je, aby tyto respektovaly základní zásady transparentnosti a nediskriminace, odpovídaly charakteru a složitosti veřejné zakázky a současně umožňovaly zadavateli nabídky vyhodnotit objektivně. Proto je povinností zadavatele, aby poskytl v zadávacích podmínkách relevantní, přesné a úplné údaje o způsobu hodnocení nabídek, které dodavatelé mohou zohlednit při rozhodování o své účasti v zadávacím řízení a při následné přípravě svých nabídek.[3] Současně musí být rozhodnutí zadavatele o výběru dodavatele na základě tohoto hodnocení zpětně přezkoumatelné, tzn. že musí být zcela zřejmý postup, na jehož základě zadavatel dospěl k výběru nejvhodnější nabídky.
Uvedené obecné závěry je pak nutné aplikovat na nastavení způsobu hodnocení prototypu. Při dodržení těchto obecných principů a všech zásad zadávacího řízení dle § 6 ZZVZ je však možné prototyp v zásadě (a opět s určitou mírou zjednodušení) učinit předmětem hodnocení u každé veřejné zakázky na dodávku informačního systému či software. V této souvislosti lze uvést, že zadávací podmínky stanovující způsob hodnocení se budou lišit s ohledem na skutečnost, zda bude zadavatel poptávat zcela inovativní specifický systém vytvořený na míru zadavatele nebo standardizovaný systém s normativními funkcemi. Standardizovaným systémem je v tomto kontextu chápan systém, který mají dodavatelé obvykle již se základními běžnými funkcionalitami vytvořený a pouze tento systém upravují na základě odlišných požadavků zadavatele, příp. jej pouze naplní daty zadavatele. Jako příklad lze uvést různorodé systémy pro registraci určitých informací či ukládání dat nebo například odbavovací systémy dodávané městům, krajům či státu za účelem odbavení cestujících ve veřejné dopravě. Systém tvořený na míru zadavatele je systémem vytvářeným tzv. na zelené louce, jehož základem není obdoba systému vyrobeného v minulosti. Takovým systémem je většinou systém velkého rozsahu, pracnosti a náročnosti; může jím být například systém vytvořený pro plnění specifických úkolů pro ústřední orgány státní správy.
Jestliže bude zadavatel jako předmět hodnocení u systému na míru požadovat prototyp s určitými specifickými požadavky, musí nejprve zvážit, jak dlouho vytvoření tohoto prototypu potenciálním účastníkům zadávacího řízení potrvá. S ohledem na tuto skutečnost musí zadavatel stanovit lhůtu pro podání nabídek takovým způsobem, aby všichni dodavatelé, kteří se chtějí zadávacího řízení zúčastnit, měli dostatek času pro vytvoření požadovaného prototypu. V případě, že zadavatel není schopen tuto lhůtu sám určit, lze doporučit obrátit se na nezávislého odborníka či znalce, který přiměřenost lhůty posoudí, přičemž podklad od odborníka či znalce je poté vhodným důkazem pro obhájení postupu zadavatele v eventuálním správním řízení před ÚOHS. V případě nedostatku informací na straně zadavatele ohledně délky lhůty doporučujeme stanovit lhůtu vždy spíše v delší než zvažované délce, aby bylo postaveno na jisto, že všichni dodavatelé jsou schopni v této lhůtě požadovaný prototyp vytvořit.
Zadavatel by měl dále posoudit, zda náklady na vytvoření prototypu s jeho specifickými požadavky nejsou pro dodavatele nepřiměřeně vysoké. Jestliže zadavatel požaduje dodání prototypu, jehož vytvoření vyžaduje zvýšenou pracnost, musí dodavatel na jeho vytvoření vynaložit určité náklady, přičemž nemá jistotu, že veřejnou zakázku získá a vynaložené náklady se mu vrátí. Nejistá návratnost této investice by tak mohla odradit (zejména) menší dodavatele na trhu a zvýhodnit velké dodavatele, jichž by se případná ztráta spočívající v těchto nákladech významným způsobem nedotkla. Jaké náklady jsou nepřiměřeně vysoké, bude přitom vždy záležet na konkrétním případě, nicméně lze obecně říci, že přiměřenost nákladů je nutno posoudit vzhledem k předmětu veřejné zakázky a její předpokládané hodnotě. V případě, že by náklady na vytvoření prototypu mohly být shledány nepřiměřenými, může zadavatel buď snížit svoje požadavky na dodaný prototyp a tím i snížit nákladovost vytvoření tohoto prototypu, nebo může stanovit, že náklady na vytvoření prototypu účastníkům zadávacího řízení proplatí, a to například v určité fixní výši nebo za určitý počet člověkodnů atd. V tomto případě však musí zadavatel v zadávacích podmínkách zcela jednoznačně definovat, jakým dodavatelům uvedené náklady proplatí, za jakých okolností k proplacení přistoupí, a musí přesně uvést, jakým způsobem musí být náklady vyčísleny a v jaké výši budou proplaceny. Zadavatel tak například stanoví, že prototyp musí přinejmenším obsahovat určité funkcionality a další funkcionality nad rámec těchto povinných budou předmětem hodnocení. Tyto hodnocené funkcionality se však budou u prototypů jednotlivých dodavatelů lišit. Proto je vhodné v takovém případě stanovit, že náklady budou hrazeny pouze u povinných funkcionalit, aby byly dodrženy zejména zásady transparentnosti a rovného zacházení, tj. aby bylo zřejmé, co přesně bude zadavatelem hrazeno a současně, aby dodavatelům nebyly hrazeny rozdílné náklady.
V případě jakéhokoli systému či software by měly být předmětem hodnocení pouze takové parametry prototypu, které jsou pro zadavatele u poptávaného informačního systému nebo software významné. Uvedený závěr vyplývá opět ze zásady přiměřenosti, z níž lze dovodit, že hodnotící kritéria musí být nastavena přiměřeně ve vztahu k předmětu veřejné zakázky včetně rozsahu a náročnosti následného plnění.[4] Před samotným nastavením zadávacích podmínek by tak měl zadavatel zvážit, které funkcionality systému jsou pro něj zásadní, a proto je bude u hodnoceného prototypu požadovat předvést, a současně posoudit, zda vyšší úroveň hodnocené funkcionality má konkrétní dopad na poptávaný informační systém či software. Zadavatel by tak neměl hodnotit v rámci prototypu například takovou funkcionalitu, kterou poté při využívání dodaného systému bude využívat pouze zřídka nebo mu pro jeho potřeby zcela postačuje její základní funkce. Zadavatel by měl být vždy schopen odůvodnit, proč určité parametry prototypu jsou pro něj z hlediska realizace veřejné zakázky významné a učinil je tak předmětem hodnocení.
Pro transparentní hodnocení prototypu je vhodné v zadávací dokumentaci uvést, jaké základní parametry a požadavky musí dodaný prototyp vždy splňovat a poté určit konkrétní parametry, které budou hodnoceny. Kritéria, na základě kterých bude prototyp hodnocen, musí být vymezena jasně a srozumitelně, aby bylo ze zadávacích podmínek zcela zřejmé, co přesně bude posuzováno, jaké vlastnosti prototypu budou hodnoceny lépe, a případně může zadavatel také uvést, jaké vlastnosti jsou nežádoucí. Předmětem hodnocení by dále neměly být též takové hodnoty prototypu, které se nevztahují k vlastnostem informačního systému jako takového, ale k zajištění bezproblémového průběhu realizace veřejné zakázky. Takovým kritériem by mohlo být například posuzování prototypu vzhledem k možným implementacím dat ze stávajícího informačního systému do systému nového, jelikož se jedná pouze o posouzení zavedení systému do prostředí zadavatele, nikoli o parametry a vlastnosti systému samotného. Postup při implementaci dat tak nemá žádný vliv na kvalitu systému a využívání systému v průběhu jeho životnosti.
Hodnotící kritéria musí být vždy vymezena tak, aby podle nich podané nabídky mohly být porovnatelné a naplnění kritérií ověřitelné.[5] Aby byly nabídky vzájemně porovnatelné, nesmí nastavení hodnocení prototypu připouštět více rozdílných výkladů, které by zapříčinily více možných výsledků hodnocení. Takovým problematickým hodnotícím kritériem by mohlo být například obecně vymezené kritérium technická kvalita prototypu. Bez uvedení další specifikace si může každý dodavatel toto kritérium vyložit odlišně, jeden dodavatel se například zaměří na celkovou architekturu prototypu, jiný dodavatel na funkční vlastnosti prototypu, další dodavatel se pak bude snažit předložit prototyp s co nejvíce možnými funkcionalitami. Takové nabídky budou vzájemně neporovnatelné, jelikož odlišné aspekty prototypu v rámci jednoho dílčího subkritéria nebude možné transparentně hodnotit. Při nedostatečném či nejasném vymezení hodnocení se tak zadavatel vystavuje riziku, že budou podány tak rozdílné nabídky, že je nebude schopen vzájemně porovnat a hodnotit, a bude tak nucen přistoupit po otevření obálek s nabídkami ke zrušení zadávacího řízení, jelikož takovou vadu zadávacích podmínek již nelže po otevření nabídek napravit.
Obecně lze dále hodnotící kritéria pro hodnocení prototypu rozdělit v souladu s § 116 odst. 2 ZZVZ na subjektivní a objektivní. Objektivními kritérii jsou matematicky vyjádřitelné či měřitelné skutečnosti nebo skutečnosti, u kterých lze hodnotit míru naplnění. Jako příklad lze uvést například u informačního systému na vytvoření registru maximální objem dat, které může registr obsahovat, či počet možných způsobů vyhledávání (podle příjmení, podle adresy, podle věkové kategorie). Zadavatel může také pro hodnocení stanovit určité nepovinné funkcionality, při jejichž splnění získá dodavatel při hodnocení prototypu předem stanovený počet bodů.
Zadavatel však může prototyp hodnotit při dostatečném vymezení těchto kritérií v souladu s výše uvedeným i na základě subjektivních kritérií jako například uživatelská přívětivost prototypu, kvalita návrhu architektury či technologická propracovanost prototypu. Hodnocení subjektivní kritérií je vždy závislé na osobě, která toto hodnocení provádí, přičemž s ohledem na toto subjektivní hledisko hodnocení jsou na stanovení takové hodnocení v zadávací dokumentaci kladeny vyšší nároky[6], tak aby bylo zcela zřejmé, jaký prototyp bude hodnocen v rámci tohoto subjektivního kritéria lépe než prototyp ostatních účastníků. Hodnocení na základě subjektivních kritérií je tak nejen náročnější z hlediska jeho vymezení, ale i z hlediska samotného provedení hodnocení. Pro vymezení hodnotících kritérií tak autoři článku doporučují, aby zadavatel k přípravě této části zadávací dokumentace přizval také odborníky, kteří se poté budou na samotném hodnocení podílet (ke stanovení hodnotící komise je pojednáno dále). Tímto postupem lze zajistit, aby hodnotící komise (či jiný orgán nebo útvar provádějící hodnocení nabídek) následně při hodnocení hodnotila ty parametry, které sama zvolila a považovala v daném ohledu za významné, a tím se vyvarovat i případných problémům ve fázi samotného hodnocení. Nastavení hodnocení na základě subjektivních hodnotících kritérií je však rizikovější i v tom ohledu, že bývá častěji napadnuto námitkami ze strany neúspěšných účastníků zadávacího řízení a bývá častějším důvodem pro zrušení provedeného hodnocení z důvodu nepřezkoumatelnosti provedeného hodnocení. Častými pochybeními v rozporu se ZZVZ je například vágní a netransparentní popis hodnocení v rozporu se ZZVZ, vybočení z mantinelů hodnocení stanoveného v zadávací dokumentaci či dodatečné doplňování způsobu hodnocení až v rámci probíhajícího hodnocení. S ohledem na tato rizika autoři tohoto článku doporučují v případech, kdy zadavatel nebude schopen zajistit pro sestavení hodnocení v zadávací dokumentaci a současně pro hodnocení v rámci hodnotící komise osobu s odbornou znalostí dané problematiky (tj. v daném případě nejlépe experta či rovnou znalce s patřičnou IT odborností), využít pro hodnocení prototypu číselně vyjádřitelná objektivní kritéria. Nicméně i u objektivních kritérií by vymezení hodnocení v zadávací dokumentaci a následné hodnocení měla provádět osoba s odborností alespoň určité úrovně.
Samotné provedení takového hodnocení a jeho zachycení ve zprávě o hodnocení nabídek může být velmi náročné. Jak již bylo uvedeno, při vytváření zadávacích podmínek by měl zadavatel hodnocení subjektivních kritérií nastavit co nejvíce transparentně a co nejblíže vymezit, co bude předmětem hodnocení. Nicméně se však může i přes snahu o co nejpodrobnější vymezení hodnotících kritérií dostat do situace, kdy bude například hodnotit grafickou propracovanost prototypu, přičemž jedna nabídka bude graficky propracovaná v jednom aspektu a druhá nabídka bude technicky lépe propracovaná v jiném aspektu. Zadavatel musí vždy transparentně uvést, z jakých důvodů považuje jednu z těchto nabídek za technicky propracovanější, přičemž nejen že se nemůže žádným způsobem odchýlit od způsobu hodnocení stanoveného v zadávací dokumentaci, ale ani nesmí dodatečně tento způsob doplňovat jako například dodatečně stanovit bodovou škálu hodnocení.
Popis způsobu hodnocení by tedy měl být již součástí zadávacích podmínek. V tomto ohledu zadavatelům doporučujeme, aby si v zadávací dokumentaci jasným a jednoznačným způsobem stanovili, jak bude subjektivní či objektivní hodnotící kritérium hodnoceno. Často využívaný způsob je v rámci každého dílčího subkritéria hodnoceného u prototypu využít bodovací stupnici v rozsahu 0 až 100, přičemž zadavatel sestaví pořadí nabídek od nejvhodnější k nejméně vhodné. Nejvhodnější nabídka získá 100 bodů v daném subkritériu a dalším nabídkám budou přiřazena taková bodová hodnocení, která vyjadřují míru splnění dílčího kritéria ve vztahu k nejvhodnější nabídce. Zadavatel však může například vymezit bodové rozmezí a slovně popsat, co musí nabídka obsahovat, aby dosáhla počtu bodů v uvedeném rozmezí. Zadavatel může též stanovit hodnotící dílčí kritérium tak, že stanoví dobrovolné funkcionality, které prototyp nemusí nutně umět, ale v případě jejich splnění získá dodavatel při hodnocení prototypu určitý počet bodů.
Přestože ZZVZ stanoví povinnost zadavatele zajistit hodnocení nabídek prostřednictvím hodnotící komise pouze u veřejných zakázek s předpokládanou hodnotou vyšší než 300 000 000 Kč, doporučujeme ustanovit hodnotící komisi v případě hodnocení prototypu i u zakázek s nižší předpokládanou hodnotou, přičemž taková hodnotící komise by měla být složena z osob, které mají odborné znalosti o dané problematice, aby bylo zajištěno transparentní a objektivní hodnocení. Tato objektivnost hodnocení by totiž mohla být narušena například při posouzení dílčího hodnotícího subkritéria uživatelské přívětivosti prototypu poptávaného nového informačního systému, kdy by toto subkritérium hodnotili zaměstnanci zadavatele, kteří využívají a jsou zvyklí na stávající informační systém. V takovém případě by mohl být v zadávacím řízení na nový informační systém neodůvodněně zvýhodněn dodavatel stávajícího systému, jelikož zaměstnanci jsou zvyklí na stávající systém a jeho ovládání.
Vzhledem ke specifickým vlastnostem prototypu by zadavatel v zadávací dokumentaci měl dále stanovit i způsob předání prototypu, jelikož se může dostat do situace, kdy prototyp z důvodu své velikosti nebude moci být součástí nabídky podávané prostřednictvím elektronického nástroje. Zadavatel by tak měl uvést, jakým způsobem a na jakém nosiči má být prototyp zadavateli předán. K předání prototypu by však mělo vždy dojít do konce lhůty podání nabídek.
V zadávací dokumentaci zadavatel musí stanovit, jakým způsobem bude hodnocení prototypu provádět, tedy také v jakém prostředí zadavatele bude prototyp instalován a testován. V případě nekonkretizování prostředí zadavatele totiž může být předložen prototyp splňující veškeré požadavky zadavatele, ale zadavatel si naplnění těchto požadavků nebude moci ověřit a prototyp hodnotit. Jak již bylo přitom výše uvedeno, zadavatel nemůže postupem dle § 46 ZZVZ dodavatele vyzvat, aby prototyp upravil takovým způsobem, kterými zajistil jeho funkčnost i v prostředí zadavatele. Nevymezení prostředí zadavatele by tak bylo takovou vadou zadávací dokumentace, která by odůvodňovala zrušení zadávacího řízení.[7]
Prototyp je tedy obvykle hodnocen na základě testování v prostředí zadavatele. Zadavatel však může požadovat namísto předložení prototypu pouze předložení výsledku výstupu, jenž osvědčuje výsledek zkoušek prototypu a naplnění jednotlivých dílčích hodnotících kritérií. Tento postup může zadavatel zvolit zejména u kvantitativně měřitelných hodnocení, u dílčích subjektivních kritérií jako je například uživatelská přívětivost či grafická propracovanost prototypu by hodnocení na základě výsledků zkoušek nebylo zjevně dost dobře možné. V této souvislosti taktéž upozorňujeme, že v případě umožnění předložení pouhého výstupu vypovídajícího o vlastnostech prototypu nemůže zadavatel předmětem hodnocení učinit taková kritéria, která se zdánlivě vztahují k informačnímu systému coby předmětu veřejné zakázky, ale ve skutečnosti mají vypovídací hodnotu pouze o nabídce dodavatele. Takovým nesprávným kritériem je například „detailnější“ popis architektury prototypu nebo „srozumitelnější“ popis používání prototypu.
Zadavateli dále pro testování prototypu doporučujeme v zadávací dokumentaci vyhradit, aby současně s prototypem byl doručen i manuál popisující způsob jeho použití pro potřeby jeho testování. Manuál je vhodným nástrojem k tomu, aby se členové hodnotící komise mohli důkladně seznámit s funkčností prototypu a i z toho důvodu, aby při hodnocení např. neopomněli nějaké funkce prototypu, které by bez předložení takového manuálu ani nemuseli odhalit. Takový požadavek je tak zcela přiměřený a souladný se ZZVZ, a to samozřejmě za předpokladu, že povinnost vytvoření manuálu bude zohledněna při stanovení lhůty pro podání nabídek.[8] Zadavatel také může k testování prototypu přizvat zástupce dodavatele. Dodání manuálu k prototypu, případně účast zástupce dodavatele při testování, tak může zajistit zejména hladký a bezproblémový průběh testování prototypu a jeho hodnocení. Zástupce dodavatele by v takovém případě měl v průběhu hodnocení sloužit pouze jako podpůrný element pro případy, že hodnotící komise bude potřebovat radu ohledně ovládání prototypu. Zástupce dodavatele by tak mě při testování toliko přihlížet a případně vyčkat na dotaz hodnotící komise, přičemž nesmí hodnotící komisi podsouvat své názory či ji navádět k jakýmkoli závěrům. Zástupce dodavatele by tak měl být pozván na testování prototypu výlučně za účelem řádného provedení testování a zamezení tomu, aby byly některé funkcionality opomenuty nebo řádně ozkoušeny. Přítomností zástupce dodavatele totiž nesmí dojít k jakékoli změně parametrů prototypu. Jestliže tedy bude přítomen zástupce dodavatele, tak pro vyvarování se jakýchkoli pochybností by měl být zamezen jakýkoli styk dodavatele s již dříve dodaným prototypem.
Průběh testování musí být vždy transparentně zachycen v dokumentaci o zadávacím řízení, přičemž samotné hodnocení prototypu je poté uvedeno ve zprávě o hodnocení nabídek. Tato zpráva musí být účastníkům zadávacího řízení doručena spolu s oznámením o výběru dodavatele, přičemž je základním podkladem pro kontrolu zákonnosti provedeného hodnocení ze strany účastníků, a případně i následně ze strany ÚOHS. Pro zajištění zákonnosti a přezkoumatelnosti postupu zadavatele tak musí zpráva o hodnocení nabídek obsahovat veškeré významné skutečnosti hodnocení provedeného v souladu se zadávacími podmínkami.
Závěrem tohoto článku shrnujeme, že zadavatel může hodnotit parametry prototypu u takřka každé veřejné zakázky na informační systém či software, přičemž při nastavení zadávacích podmínek musí vyjma dodržení základních zásad zadávacího řízení zejména dbát na to, aby byl popis způsobu a metody hodnocení dostatečně podrobný a transparentní, hodnocené parametry prototypu byly z pohledu předmětu veřejné zakázky významné a naplnění dílčích hodnotících kritérií u hodnoceného prototypu objektivně ověřitelné.
Autoři tohoto článku věří, že požadavek na dodání funkčního prototypu coby předmětu hodnocení se bude vyskytovat v zadávacích řízeních čím dál častěji, a to zejména s ohledem na rozvoj informačních technologií a související potřeby zadavatelů. Současně autoři článku doufají, že k tomuto rozvoji přispěli alespoň drobným dílem i tímto článkem, že zadavatelům objasnili případné nejasnosti související s tímto institutem a že uvedli způsob, jakým mohou zadavatelé u hodnocení dotčeného prototypu postupovat.
[1] Viz § 39 odst. 3 ZZVZ.
[2] DVOŘÁK, D. a kol.: Zákon o zadávání veřejných zakázek. Komentář. 1. vyd. Praha: C. H. Beck, 2017. str. 245.
[3] Rozhodnutí ÚOHS č. j. ÚOHS-S149/2013/VZ-16452/2013/514/ZČa ze dne 29. 8. 2013.
[4] PODEŠVA, V. a kol.: Zákon o zadávání veřejných zakázek. Zákon o registru smluv. Komentář. 1.vyd. Praha: Wolters Kluwer ČR, 2016. str. 153.
[5] § 116 odst. 3 ZZVZ.
[6] Rozsudek Nejvyššího správního soudu, č. j. NSS 1 Afs 8/2011-112 ze dne 2. 2. 2011.
[7] Obdobně viz rozhodnutí ÚOHS, č. j. ÚOHS-S0453,S0658/2016/VZ-46586/2016 /532/KSt ze dne 15. 11. 2017.
[8] viz rozhodnutí ÚOHS, č. j. ÚOHS-S71/2012/VZ-6285/2012/510/MOn ze dne 18. 10. 2012.
Compliance management systém jako podmínka pro vyvinění z trestní odpovědnosti právnické osoby Miloš Olík jedním z autorů ICCA International Handbook

References: § 79
 § 104
 § 46
 § 46
 § 46
 § 46
 § 46
 § 6
 § 116
 § 46
 § 39
 § 116