- Přehledy IS
- APS (25)
- BPM - procesní řízení (23)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (31)
- CRM (52)
- DMS/ECM - správa dokumentů (19)
- EAM (17)
- Ekonomické systémy (68)
- ERP (87)
- HRM (28)
- ITSM (6)
- MES (33)
- Řízení výroby (36)
- WMS (28)
- Dodavatelé IT služeb a řešení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (40)
- Dodavatelé CRM (37)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (63)
- Informační bezpečnost (43)
- IT řešení pro logistiku (48)
- IT řešení pro stavebnictví (26)
- Řešení pro veřejný a státní sektor (27)
CRM systémy
Plánování a řízení výroby
AI a Business Intelligence
DMS/ECM - Správa dokumentů
HRM/HCM - Řízení lidských zdrojů
EAM/CMMS - Správa majetku a údržby
Účetní a ekonomické systémy
ITSM (ITIL) - Řízení IT
Cloud a virtualizace IT
IT Security
Logistika, řízení skladů, WMS
IT právo
GIS - geografické informační systémy
Projektové řízení
Trendy ICT
E-commerce B2B/B2C
CAD/CAM/CAE/PLM/3D tisk
Přihlaste se k odběru zpravodaje SystemNEWS na LinkedIn, který každý týden přináší výběr článků z oblasti podnikové informatiky | ||
Problémy veřejných zakázek v IT (1. díl)
Definice funkcí, změnová řízení, rozšiřování licencí
V rámci svých přednášek s tématikou softwarových smluv se v souvislosti s veřejnými IT zakázkami často setkávám s otázkami na možné pochybení zadavatele při definici požadavků na typ licence, pochybení při vymezení funkcí softwaru, problematický požadavek na neomezenou odpovědnost za škodu či požadavky na customizaci či servis softwaru. Ze strany veřejných zadavatelů je poukazováno na problémy, které jim působí svázanost zákonem o veřejných zakázkách v podobě nutnosti podstoupit složité zadávací řízení v případě rozšíření stávajícího systému či servisní činnosti bez možnosti zadat zakázku stávajícímu dodavateli. Je tak evidentní, že dodávky softwaru a s tím spojených služeb v rámci veřejných zakázek přináší celou řadu zásadních problémů. Na některé z nich se budu snažit najít odpověď v následujícím textu. Nepochybuji ovšem, že těch složitostí je podstatně více než zde můžeme probrat, plynou totiž z individuální povahy každé zakázky.
Definice funkcí softwaru v zadávací dokumentaci
Podle § 6 zákona je zadavatel povinen při postupu podle zákona č. 137/2006 Sb., o veřejných zakázkách (dále jen „ZVZ“) dodržovat zásady transparentnosti, rovného zacházení a zákazu diskriminace. Je obvyklé, že v rámci požadavků zadavatele na dodávku softwaru se definuje jeho funkcionalita. Samozřejmě pokud byla již před vyhlášením veřejné zakázky provedena analýza, pak tyto požadavky budou velmi konkrétní a mohou nahrávat konkrétnímu dodavateli softwaru. Takto příliš konkrétně formulované („na míru šité“) požadavky mohou ve svém důsledku znamenat omezení počtu potenciálních uchazečů a z toho plynoucí diskriminaci ve smyslu § 6 ZVZ. Taková zadávací dokumentace by byla protiprávní a bylo by možné proti ní podat dle zákona námitky. Pokud zadavatel námitkám nevyhoví, pak má uchazeč možnost podat ve lhůtě 10 dnů návrh na zahájení řízení o přezkoumání úkonů zadavatele u Úřadu pro ochranu hospodářské soutěže a zadávací lhůta neběží. Úřad pak zkoumá soulad technických kvalifikačních předpokladů, přiměřenost podmínky seznamu významných služeb, požadavků osvědčení o vzdělání a odborné kvalifikaci a dalších podmínek zadávací dokumentace, a to z pohledu možné diskriminace.
Jestliže se vyhlašuje veřejná zakázka ještě před samotnou analýzou, pak definice požadavků na funkcionalitu by měla být formulačně postavena na vymezení základních funkcí, které jsou schopny pod sebe podřadit v následné specifikaci softwaru již funkce konkrétní. Tato detailní specifikace samozřejmě může mít dopad na cenu, nicméně s tím musí při své kalkulaci uchazeč (dodavatel) počítat.
Změnová řízení v rámci veřejné zakázky
Dalším velkým problém je u veřejných zakázek na dodávky softwaru v IT zcela standardní změnové řízení. Není neobvyklé, že v průběhu vývoje či samotné implementace obě smluvní strany dojdou k potřebě doplnění funkcionality či její změny, která bude mít dopad na znění smlouvy, ať už v rovině finanční nebo časové. Zákon umožňuje změnu smlouvy po jejím uzavření pouze dle § 82 odst. 7 ZVZ, podle něhož zadavatel nesmí umožnit podstatnou změnu práv a povinností vyplývajících ze smlouvy, kterou uzavřel s vybraným uchazečem. Za podstatnou se považuje taková změna, která by rozšířila předmět veřejné zakázky nebo např. měnila ekonomickou rovnováhu smlouvy ve prospěch vybraného uchazeče. V těchto mantinelech tedy lze realizovat změnové řízení. Toto však nemusí být dostatečný prostor pro rozsáhlejší změnové řízení. Proto lze tento problém řešit pouze dostatečně kvalitní analýzou nebo „vágnější“ formulací funkcionality softwaru, v jejímž rámci se změny budou sjednávat, pokud lze takové změny alespoň částečné předvídat. Dle mého názoru, tam kde zůstanou zachovány podstatné funkce softwaru a dojde pouze ke změnám v méně podstatných funkcích (které jsou v rámci původní zadávací dokumentace), pak lze hovořit o nepodstatné změně smlouvy a tím pádem zcela přípustné. Stejně tak odůvodněné navýšení ceny, které nepřesáhne cenu nabídnutou uchazečem v druhém pořadí, by nemělo měnit ekonomickou rovnováhu smlouvy.
Požadavek na výhradní licenci
Zadavatelé mnohdy trvají na tom, aby jim ze strany dodavatele softwaru byla udělena výhradní licence. Ta znamená, že kromě zadavatele nikdo jiný nesmí software či jeho část (funkční) dále využívat. Tento požadavek se z pohledu fungování licenční politiky velkých nadnárodních výrobců jeví jako zcela neopodstatněný. Nejenom že dochází k jejich diskriminaci a automatickému vyřazení z důvodů standardizace licenčních podmínek těchto výrobců např. pro celou EU, ale žádná z těchto globálních firem, které nabízejí kvalitní produkty, nebude ochotna měnit své licenční podmínky z důvodu požadavku jediné státní či jiné instituce „malého státu uprostřed Evropy“. Pokud by veřejný zadavatel trval na omezení šíření daného softwarového produktu ve prospěch např. konkurenčního subjektu (např. státní firma vs. soukromá), pak zcela nic nebrání, aby v rámci nevýhradní licence byl sjednán zákaz poskytnutí obdobného či shodného softwaru konkurenčnímu subjektu pod sankcí smluvní pokuty.
Požadavek na neomezenou odpovědnost za škodu
Požadavek zadavatele na neomezenou odpovědnost za škodu je rovněž velmi problematický, a to z několika důvodů. Tím prvním je skutečnost, že většinou unifikované licenční podmínky velkých výrobců obsahují limitaci náhrady škody a většinou nepřipouštějí smluvní modifikaci národními distributory (uchazečem). Dalším důvodem je, že neomezená odpovědnost za škodu neřeší z pohledu její vymahatelnosti prakticky nic. Jestliže totiž vznikne škoda, pak je nutné prokázat ze strany objednatele, že jde o škodu způsobenou konkrétní vadou softwaru, že tato vada nebyla způsobena jinou skutečností (např. telekomunikačním spojením, špatným temperováním serveru, jiným souvisejícím softwarem, jednáním konkrétního uživatele atd.), dále že škoda je v příčinné souvislosti s konkrétní vadou, že objednatel splnil prevenční povinnosti, že škoda byla způsobena v konkrétní výši, kterou je nutné přesně vyčíslit dle reálných podkladů. Soudní spory týkající se škod v IT jsou navíc tak složité a i znalci těžko prokazatelné, že po několika letech soudního řízení konkrétní dodavatel už nemusí dávno existovat, pakliže bude vědět, že jemu taková vysoká škoda hrozí. A jak praví stará zásada, kde nic není, ani smrt nebere. Navíc mít omezenou odpovědnost za škodu např. na částku 50 mil. Kč vůči velké nadnárodní firmě je přece jen výhodnější než mít neomezenou odpovědnost vůči malé české firmě s majetkem sotva pár mil. Kč. Lze tedy doporučit zadavateli přistoupit na rozumnou limitaci náhrady škody, dbát na krytí např. ve formě pojištění, které může být ve vyšších částkách.
Požadavky na neomezenou odpovědnost za škodu jsou omezením pro celou řadu subjektů, jejichž licenční podmínky odpovědnost za škodu limitují, a limitace náhrady škody by tak měla být spíše dílčím kritériem pro výběr uchazeče, když výši limitace by měl vždy doplnit uchazeč, a to s ohledem na limitaci danou výrobcem softwaru v licenčních podmínkách.
Úschova zdrojových kódů
Escrow neboli úschova zdrojových kódů je velmi efektivní nástroj, který umožňuje jednak zadavateli dostupnost zdrojových kódů softwaru v případě insolvence či jiných potíží dodavatele softwaru nebo při prodlení s poskytováním servisní činnosti. Stejně tak lze úschovu využít s ohledem na Úřadem níže uvedené výklady problematiky úprav softwaru a jeho servisu. Na druhé straně úschova zdrojových kódů chrání dodavatele softwaru před zneužitím samotným zadavatelem, resp. konkrétním zaměstnancem ve prospěch spřízněných osob. Proto požadavek na předání zdrojových kódů zadavateli jakožto podmínka dodávky softwaru se z pohledu výrobců může jevit jako nepřiměřený. Ne všichni výrobci (natož nadnárodní) zpřístupňují své zdrojové kódy (alespoň nikoliv v základní úpravě) zákazníkům. Opodstatnění toto má u nadstandardních úprav softwaru (customizace, další moduly vytvořené na míru), kdy i zde někteří výrobci umožňují zpřístupnění. V těchto případech je zcela namístě úschova zdrojových kódů, jestliže je poskytována odpovídajícími subjekty.
Úpravy softwaru zadavatelem
Někteří zadavatelé výslovně požadují možnost realizovat úpravy ve vlastní režii, tzn. bez účasti dodavatele. To však je pro dodavatele velmi rizikové, když takový zásah do softwaru představuje nebezpečí vzniku vady, kterou by dodavatel měl povinnost odstranit, nemluvě o povinnosti k úhradě smluvní pokuty či náhrady škody. Většina dodavatelů takovou situaci řeší dvojím způsobem. Buď objednatel akceptuje ztrátu odpovědnosti za vady a odstraňování vad bude probíhat v placeném servisním režimu, nicméně bez odpovědnosti za škodu, nebo veškeré úpravy musí být odsouhlaseny dodavatelem, a pokud odsouhlaseny nebudou, pak jím budou realizovány.
Rozšíření systému o další licence, opční právo
V tomto směru je nutné rozlišovat, zda předmětem rozšíření licencí je software, který byl vytvořen na míru nebo jde o standardní software, který je dodáván vícero dodavateli. U standardního softwaru je nutné podstoupit opět odpovídající zadávací řízení dle zákona o veřejných zakázkách a není možné dodavatele, byť provádí servisní činnost, upřednostnit před jinými dodavateli licencí. Stejně tak i u softwaru, který byl customizován a customizaci daného softwaru nemůže s ohledem na absenci dostupnosti zdrojových kódů provést jiný subjekt, pak je nutné s ohledem na níže uvedené závěry Úřadu o nemožnosti svázat licenčními podmínkami zadavatele postupovat rovněž podle příslušného zadávacího řízení. Výsledkem takového řízení by měla být dodávka dalších licencí již používaného softwaru nebo dodávka nového softwaru. Tyto závěry ovšem považuji za dosti pochybné, když při potřebě doplnění licencí customizovaného SW v hodnotě desítek či stovek mil. Kč bude nutné realizovat nové zadávací řízení. Navíc, pokud by jeho předmětem bylo doplnění licencí softwaru, který byl opravdu natolik customizován, že jedinou alternativou je celý systém nahradit, pak takové řešení by bylo velmi neekonomické a neefektivní. Proto doporučuji u takového typu softwaru řešit rozšiřování licencí již v původním rozsahu veřejné zakázky. Řešením tak může být tzv. opční právo dle § 99 ZVZ, kterým se rozumí právo zadavatele na poskytnutí dalších dodávek, služeb, jejichž zadání si zadavatel vyhradil v zadávacích podmínkách původní veřejné zakázky. Opční právo je zadavatel oprávněn využít pouze ve vztahu k dodavateli, kterému zadal původní veřejnou zakázku. Zadat veřejnou zakázku na základě využití opčního práva může zadavatel pouze v jednacím řízení bez uveřejnění. Nicméně s využitím opčního práva a s kalkulací ceny v rámci tohoto opčního práva musí zadavatel počítat již při vyhlašování veřejné zakázky a při vyhodnocování nabídek uchazečů.
Závěr
Ze shora uvedeného je patrné, že jak uchazeči, tak zadavatelé veřejných zakázek v IT se potýkají s celou řadou problémů. Zadavatelé by však měli rozumně přistupovat k řešení svých požadavků a ne vždy lpět na tom, co jim nepřinese ve svém důsledku nic než prázdnou jistotu (např. neomezená odpovědnost za škodu) či bude znamenat porušení zákazu diskriminace (např. trváním na výhradní licenci). Uchazečům lze zase doporučit, aby v rámci soutěžení veřejné zakázky dostatečně z právního pohledu posuzovali podmínky zadavatele, na nedostatky zadávací dokumentace zadavatele upozornili, případně se bránili postupem dle zákona o veřejných zakázkách v námitkovém či soudním řízení.
JUDr. Lukáš Jansa Autor článku je advokátem ve společnosti Jansa, Mokrý, Otevřel & partneři s.r.o., advokátní kancelář. |
prosinec - 2024 | ||||||
Po | Út | St | Čt | Pá | So | Ne |
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 | 1 | 2 | 3 | 4 | 5 |
31.3. | HANNOVER MESSE 2025 |
9.4. | Digital Trust |
Formulář pro přidání akce
11.12. | Webinář: Dodržování směrnic, compliance, QMS |