V této kapitole se dozvíte:
Vendor lock-in, česky proprietární uzamčení, představuje situaci, kdy se zákazník stane závislým na produktech či službách jednoho konkrétního dodavatele, což sebou zpravidla nese zvýšené náklady či jiné komplikace při přechodu ke konkurenci (na jiné produkty nebo služby). Obecně se v angličtině hovoří o tzv. path dependance, kdy minulá rozhodnutí mají přímý vliv na okruh reálných možností v budoucnu. V kontextu digitalizace veřejné správy jde o situaci, kdy zadavatel, zpravidla orgán veřejné moci, nese v důsledku této závislosti zvýšené náklady při rozvoji a úpravách stávajícího ICT řešení nebo dokonce při pořízení zcela nového ICT řešení a s tím spojené migrace dat, a to na základě svého dřívějšího rozhodnutí.
Pro dodavatele vendor lock-in obvykle představuje výhodu, jelikož si udrží příjmy od zadavatele, který by jinak mohl přejít ke konkurenci. Pro orgán veřejné moci má toto „uzamčení“ ovšem obvykle nepříznivý dopad; jeho důsledkem může být kromě vyšších nákladů nízká efektivita, nízká míra interoperability nebo řešení neodpovídající technickému pokroku či novým zákonným požadavkům (byť někteří zadavatelé mohou ve vendor lock-in spatřovat i výhodu v podobě uzamčení „historických cen“ bez inflačních doložek apod.).
To způsobuje mimo jiné ztíženou kontrolu, ať už interní, autoritativní, nebo ze strany běžné veřejnosti. Snaha o budování proprietárního uzamčení často vychází od dodavatelů. Jsou to totiž právě oni, kterým toto uzamčení obecně svědčí. Rigidní vztah se zadavatelem jim může přinést zejména další, navazující zakázky nebo je alespoň může postavit do lepší vyjednávací pozice o smluvně nedostatečně upravených podmínkách stávajícího plnění. Budování vendor lock-in ze strany dodavatelů je tak nezřídka poháněno vidinou jejich vyšší ziskovosti.
Závislost na jednom dodavateli vede k řadě negativních dopadů:
Vázaností zadavatele na jediného dodavatele je omezována hospodářská soutěž, neboť jedním z hlavních projevů proprietárního uzamčení jsou vysoké náklady na změnu dodavatele (nicméně obvykle současně ještě větší náklady spojené se setrváváním ve stavu vendor lock-in, které se navíc postupně kumulují). Tento stav působí rozpor se zásadami 3E při veřejném investování. Tomuto stavu by se mu mělo předcházet, a to nejlépe ještě před sestavováním zadávací dokumentace, tedy ve fázi plánování a přípravy zadání, neboť pozdější řešení již vzniklého stavu závislosti zpravidla není příliš efektivní.
Ačkoli fenomén vendor lock-in nemusí nutně souviset s ICT odvětvím, je třeba konstatovat, že ICT zakázky jsou k proprietárnímu uzamčení zvláště náchylné, a to zejména z následujících důvodů:
Zamezení vzniku proprietárního uzamčení by mělo být klíčovou prioritou při zadávání veřejných zakázek v oblasti ICT.
Přestože je vendor lock-in již několik let často diskutovaným pojmem v oblasti veřejných zakázek zaměřených na ICT služby, stále neexistuje univerzální a vyčerpávající definice tohoto fenoménu.
Obecně lze vendor lock-in chápat jako situaci, kdy zákazník, který využívá určitou službu nebo produkt, pociťuje obtíže při přechodu k nabídce konkurence, tzn. jde o situaci závislosti zákazníka na produktu či službě jednoho konkrétního dodavatele, neboť změna na produkty jiného dodavatele by byla příliš nákladná nebo komplikovaná. Tento typ „uzamčení“ a „exkluzivního postavení určitého dodavatele“ je obvykle způsoben proprietárními technologiemi dodavatele, které nejsou kompatibilní s technologiemi jiných dodavatelů. Podle alternativního výkladu se vendor lock-in chápe jako situace, kdy zákazník pociťuje vysokou míru závislosti na produktech nebo službách určitého dodavatele a nemá možnost efektivně přejít k jinému poskytovateli.
V kontextu veřejných zakázek lze vendor lock-in definovat jako dlouhodobou závislost na specifickém dodavateli, která přesahuje rámec jedné jednotlivé veřejné zakázky, a to z právních či technických důvodů. Na právní důvody mířil Úřad pro ochranu hospodářské soutěže ve svém Informačním listu z roku 2017:
CITACE:
Hovoříme-li o vendor lock-inu, pak mluvíme mimo jiné o neschopnosti zadavatele změnit či zpřístupnit dílo vytvořené dodavatelem bez jeho souhlasu nebo poplatků (tzv. exit costs). Zadavatel je jako uživatel díla v situaci, kdy je s ohledem na jiná pravidla, která též musí v oblasti veřejné správy dodržovat, zcela závislý na službě konkrétního dodavatele. Proto se mluví o proprietárním uzamčení zadavatele, který není schopen změnit své existující řešení jednoduše a bez shora uvedených výstupních nákladů, které jsou kvůli jeho závislosti na dodavateli mnohdy přemrštěně vysoké.
(Informační list Úřadu pro ochranu hospodářské soutěže č. 1/2017, str. 22)
Zde je nutné jinak rozlišovat dodavatele i výrobce, kdy software může mít jednoho „výrobce“ a přitom více dodavatelů – distributorů. Už jen z logiky věci horší situací je, pokud „výrobce“ je zároveň jediným dodavatelem na trhu nebo ho zastupuje jediný výhradní dodavatel. I tak je nutno při zadávání nadlimitních veřejných zakázek pamatovat na ustanovení § 89 odst. 5 a 6 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, v platném znění (dále jen „ZZVZ“):
CITACE:
(5) Není-li to odůvodněno předmětem veřejné zakázky, zadavatel nesmí zvýhodnit nebo znevýhodnit určité dodavatele nebo výrobky tím, že technické podmínky stanoví prostřednictvím přímého nebo nepřímého odkazu na
a) určité dodavatele nebo výrobky, nebo
b) patenty na vynálezy, užitné vzory, průmyslové vzory, ochranné známky nebo označení původu.
(6) Odkaz podle odstavce 5 písm. a) nebo b) může zadavatel použít, pokud stanovení technických podmínek podle odstavce 1 nemůže být dostatečně přesné nebo srozumitelné. U každého takového odkazu zadavatel uvede možnost nabídnout rovnocenné řešení.
Vendor lock-in může mít různé příčiny. Nejčastěji se rozlišují následující dvě oblasti příčin vzniku:
V praxi vendor lock-in obvykle vzniká kombinací několika technických i právních faktorů. Je důležité si uvědomit, že každá situace vendor lock-in je jedinečná. Lze ovšem zobecnit, že prvotním zdrojem jsou následující faktory na straně orgánu veřejné moci:
DŮLEŽITÉ_
Snažte se zjistit, jestli lidé zodpovědní za vedení a rozpočet projektu mají odpovídající technické zkušenosti. S výjimkou těch úplně nejmenších úřadů má prakticky každý někoho technicky orientovaného, kdo může vedení projektu doplnit – ačkoliv naopak prakticky nikdo k tomuto účelu nezaměstnává přímo softwarové vývojáře.
(Průvodce světem řízení státních IT projektů, Digitální Česko, str. 26-27)
Kompetenční centra Digitální a informační agentury provedla výzkum mezi ministerstvy zaměřený na zadávání veřejných zakázek v oblasti ICT. Ačkoli česká právnická literatura obvykle problém vendor lock-in zmiňuje v souvislosti se špatným nastavením práv duševního vlastnictví, z výzkumu vyplynulo, že v praxi se tento problém u nových zakázek již neobjevuje. Šlo o specifický problém, který se objevoval v 90. letech, nicméně u starších systémů, které nadále fungují, však bohužel stále přetrvává. V případě nových systémů však jednotlivá ministerstva umí vhodně nastavit autorskoprávní ochranu; přispěl k tomu rovněž seznam XXX, který je dostupný v Národním architektonickém plánu. Problém proprietárního uzamčení v případě nových systémů tak souvisí spíše s technickými důvody.
Z pohledu práva veřejných zakázek a judikatury Nejvyššího správního soudu je pak obzvlášť důležité, zda byl vendor lock-in vytvořen zadavatelem na bázi nezaviněné či zaviněné exkluzivity:
Technické příčiny vendor lock-in se týkají především specifikace a struktury informačního systému a jeho schopnosti komunikovat s jinými informačními systémy či software. Z širšího hlediska lze mezi nejvýznamnější technické příčiny vendor lock-in zařadit následující faktory:
V této souvislosti je důležité, aby zadavatelé již při přípravě projektu zohlednili tyto možné technické bariéry a přijali opatření pro minimalizaci rizik vendor lock-in. Jedním z doporučení je větší využívání otevřených standardů, open-source technologií (systémů) a modulárního plánování, které snižují závislost na konkrétních dodavatelích a konkrétních software, jinými slovy v co největší míře standardizovat informační systém (tedy ještě jinými slovy, co nejméně jej šít na míru zadavateli). Standardizace umožňuje zadavateli využít širší okruh dodavatelů ICT systémů a snižuje omezení při následném rozvoji a údržbě systému. Toto opatření sice zcela neodstraní riziko vendor lock-in, ale výrazně ho eliminuje a poskytne zadavateli větší flexibilitu. Open-source systémy mohou zadavateli nabídnout více možností, protože jsou otevřené, avšak i tyto systémy mají své limity, které se odvíjí od specifických požadavků systému.
Další vhodnou strategií je zmíněný modulární přístup k vývoji systému (namísto monolitického). Namísto toho, aby byl systém postaven jako jednolitý celek, může být vytvořen jako síť modulů (tj. na sobě nezávislých komponent) kolem centrálního jádra (připojených pomocí ideálně standardizovaných nebo aspoň velmi dobře zdokumentovaných a licenčně dobře ošetřených API/datových konektorů). Tento přístup usnadňuje výměnu, úpravy, přidávání a odebírání jednotlivých modulů, což zadavateli umožňuje postupně přizpůsobovat systém bez nutnosti kompletní závislosti na jednom dodavateli.
Tato kombinace standardizace a modulárního přístupu, spolu s využitím open-source řešení, může výrazně snížit riziko technického vendor lock-in a ponechat zadavateli více možností při rozvoji a správě informačního systému.
Právní příčiny vzniku vendor lock-in mají zásadní vliv na omezení volnosti zadavatele při vývoji a údržbě informačního systému. Tyto příčiny často vyplývají z nedostatečného zajištění právních náležitostí při uzavírání smluv s dodavateli softwaru nebo služeb. Právní rámec musí být pečlivě nastaven, aby zadavatel nezůstal závislý na jednom dodavateli a měl možnost vyjednávat či změnit dodavatele bez zbytečných překážek. Klíčovými faktory v tomto ohledu jsou zejména otázky práv duševního vlastnictví (autorských práv), licenčních podmínek a smluvních ujednání o přístupu ke zdrojovým kódům a dalším technickým informacím.
Jednou z hlavních právních příčin vendor lock-in je absence adekvátní licence k softwaru, který zadavatel využívá. Pokud zadavatel nedisponuje plnohodnotnou licencí k software nebo jeho klíčovým částem, je závislý na původním dodavateli, který vykonává majetková autorská práva k tomuto softwaru. Tento stav výrazně omezuje možnosti zadavatele provádět změny v softwaru, upravovat ho, nebo jej rozvíjet prostřednictvím jiného dodavatele.
Také neexistence vypracovaného exit plánu (exit strategie) a smluvní zajištění součinnosti vybraného dodavatele v souvislosti s migrací co do předání všech potřebných dat a jejich formátu / standardu, technické a provozní dokumentace (včetně např. i dokumentace dat) a komentovaného zdrojového kódu a dalšího know-how je častým právním nedostatkem, který vede k vendor lock-in, protože zadavatel nemá předem jasně definované podmínky a postupy, a to jak technické, tak i právní (a tím ani předem smluvně zajištěnou součinnost od vybraného dodavatele pro přechod k novému budoucímu dodavateli nebo k sobě samému). V opačném případě se takový přechod může zadavateli výrazně prodražit, protože zpřístupnění zdrojových kódů a další služby bývají naceněny původním dodavatelem, což může výrazně zvýšit náklady a efektivně tak i bránit úniku z vendor lock-in.
Podle zákona č. 121/2000 Sb., autorského zákona, je vývoj softwaru chráněn jako výsledek duševní činnosti autora. Tento zákon stanovuje, že práva k softwaru náleží jeho tvůrci, pokud není dohodnuto jinak. Proto je pro zadavatele nezbytné, aby smlouvy s dodavateli zahrnovaly specifické podmínky pro udělení licencí a možnosti využívání softwaru po ukončení smluvního vztahu. Pokud toto není ošetřeno, může se stát, že zadavatel nebude mít dostatečná oprávnění k tomu, aby mohl systém rozvíjet, a to sám nebo ve spolupráci s novým dodavatelem.
Autorská práva jsou zásadním aspektem softwarových systémů. Když ICT systém vyvíjí externí subjekt, obvykle vzniká autorské dílo, které patří dodavateli. Zadavatel získává pouze uživatelská práva, která mu umožňují software používat, ale ne jej upravovat nebo rozšiřovat. Proto je při pořizování softwaru zásadní zajistit, aby smlouva s dodavatelem zahrnovala práva na úpravy a změny softwaru. Toto zahrnuje především možnost přístupu ke komentovaným a přehledně strukturovaným a tím i srozumitelným zdrojovým kódům, které jsou reálně nezbytné pro úpravy a rozšiřování software, kdy bez těchto informací je následný vývoj velmi obtížný, a s tím související práva na úpravy a rozvoj software, buď vlastními silami, nebo prostřednictvím třetích stran, případně je vhodné si v souladu s ustanovením § 100 ZZVZ vyhradit v rámci zadávací dokumentace i změnu dodavatele v průběhu plnění veřejné zakázky. Tj. důležité si v rámci zadávací dokumentace a smlouvy zakotvit možnosti, aby jiné subjekty mohly převzít správu a rozvoj systému.
Pokud zadavatel tato práva nemá zajištěna, ocitá se ve stavu vendor lock-in, kdy je zcela závislým na původním dodavateli, který může nadále kontrolovat všechny změny a úpravy systému.
Licenční podmínky často stanovují, jakým způsobem může zadavatel software používat. Zadavatelé, kteří nemají dostatečně jasně specifikované licenční podmínky, se mohou snadno dostat do situace, kdy jim bude znemožněno software dále rozvíjet, zejména pokud dodavatel omezuje možnost poskytnout software třetím stranám pro úpravy a servis. Zadavatel by měl vždy usilovat o získání licence, která zahrnuje práva na úpravy, distribuci a další rozvoj softwaru.
Právní příčiny vzniku vendor lock-in tak lze shrnout do několika klíčových bodů:
Tyto faktory představují zásadní překážky pro zadavatele při snaze o únik z vendor lock-in a je nezbytné je pečlivě zohlednit při sjednávání smluv s dodavateli softwaru a ICT služeb.
Hospodářskou soutěž také omezuje skutečnost, pokud si dodavatel v rámci svého distribučního modelu ponechá výhradní práva duševního vlastnictví (majetková autorská práva) ke svému produktu, který pak v rámci vypsané veřejné zakázky nemohou nabídnout i další dodavatelé.
Právní vendor lock-in tak vyžaduje revizi smluvních podmínek, vyjednání širších licenčních práv, zabezpečení přístupu k zdrojovým kódům a detailní plán pro ukončení spolupráce s aktuálním dodavatelem.
Vymezení druhů vendor lock-in je založeno na analýze jednotlivých příčin vzniku a jejich rozdělení do základních kategorií, které odpovídají různým typům tohoto jevu. Rozlišení různých druhů vendor lock-in je nezbytné, protože každý typ vendor lock-in vyžaduje odlišné přístupy k jeho řešení, v závislosti na konkrétních příčinách, které jej způsobily.
Druhy vendor lock-in
Z předešlé části jsme identifikovali několik hlavních příčin vzniku vendor lock-in, na základě kterých lze vendor lock-in typově rozdělit zejména na:
Rozlišovat lze teoreticky i ekonomický vendor lock-in, pokud je například jediným oprávněným distributorem dotčeného software pro určitý trh jen jediný licencovaný subjekt. V takovém případě lze hovořit o tzv. ekonomickém monopolu[2]:
Nezmíněnou formou uzamčení je např. ještě „osobní uzamčení z důvodu subjektivních preferencí“. Toto uzamčení je ve veřejném zadávání ale nepřípustné (s možnou výhradou postupů dle § 89/5 a 6 ZZVZ).
Vendor lock-in může vzniknout i u tzv. early adopters, tedy když někdo nasadí nějaký nový „revoluční“ systém, o kterém jinak ještě nejsou na trhu žádné další bližší informace.
Většinou je reálně příčinou stavu vendor lock-in vždy kombinace několika faktorů. Především musí být na straně dodavatele dána potřeba opakovaného plnění, která je v prostředí ICT reprezentována zejména údržbou existujícího informačního systému či jeho konstantním vývojem.
Dále se zpravidla jedná o specifické konkurenční prostředí, ve kterém na straně dodavatelů působí maximálně pár subjektů, přičemž poskytované plnění je natolik unikátní, že neumožňuje jednoduché přesoutěžení zakázky.
Z pohledu veřejného zadávání ICT zakázek obecně můžeme narážet na různé problémy. Zde jsou některé z nejčastějších, přičemž každý z těchto problémů může vést ke stavu vendor lock-in:
V této kapitole se dozvíte o:
Důsledky stavu vendor lock-in mohou být pro veřejného zadavatele závažné. Mezi nejzávažnější patří:
Aby zadavatelé předešli stavu vendor lock-in, mohou do zadávacích podmínek zahrnout požadavky na otevřené standardy, přístup k licencím, nebo dokonce přístup ke zdrojovému kódu a komentáře k němu, který jim umožní větší svobodu při správě a budoucích úpravách systému.
Z pohledu ekonomické analýzy práva (Law and Economics), americké právní doktríny zaměřující se na efektivitu právních pravidel, lze vendor lock-in chápat jako situaci, která narušuje optimální fungování trhů a snižuje efektivitu alokace zdrojů. Z ekonomického hlediska vendor lock-in vede k tržním selháním v několika klíčových aspektech:
Právní regulace, které usilují o minimalizaci vendor lock-inu, by tedy měly směřovat k redukování transakčních nákladů, podpoře konkurence a posílení právní ochrany zadavatelů v kontraktačních procesech. Prevence vendor lock-inu je proto v rámci ekonomické analýzy práva vnímána jako nástroj zlepšení efektivity a alokace zdrojů ve veřejném sektoru a na trhu obecně.
Vendor lock-in je zrádný fenomén, jelikož z počátku si ho vůbec zadavatel nemusí všimnout, podobně jako u jiných typů závislostí. Z počátku ve většině případů systémy fungují, jak mají a panuje s nimi spokojenost. Po nějaké době se začnou objevovat komplikace v podobě omezení, nefunkčností a různých problémů. Většinu těchto komplikací způsobuje konkrétní dodavatel – v podobě nereagování na jeho straně, popř. nezájmu o proaktivní podporu anebo si diktuje pro zadavatele nevýhodné cenové podmínky (pokud není tato otázka výslovně řešena ve smlouvě pro zadavatele příhodněji). Zadavatelé pak následně zjistí, že jsou uvězněni v daném řešení a postupně se více přizpůsobují systému, místo aby se systém přizpůsoboval jim. Následkem toho se zadavatel stává více závislý a platí více a více finančních prostředků a situace se po nějaké době stane stejně pro něj stejně neudržitelnou, že ji musí aktivně řešit.
Na úvod uvedeme příklad řešení situace vendor lock-in, který si mohou pamatovat hlavně starší generace – týká se mobilních operátorů v České republice. Dříve přechod k jinému poskytovateli mobilních služeb znamenal, že si zákazník musel změnit telefonní číslo, což s sebou neslo mnoho obtíží a nákladů – od nutnosti informovat kontakty až po tisk nových materiálů. Tento problém už dnes naštěstí neexistuje, ale dosažení současného stavu si vyžádalo dlouhý proces a značné úsilí. Obdobně to platí pro informační systémy, které bývají specifické a unikátní, což jejich náhradu činí velmi složitou. Například přechod na nový systém, implementace sta nebo export dat bývá náročný úkol.
Dobrým příkladem uzavřeného ekosystému je technologie Apple, nebo situace kolem Microsoft Office, kde, přestože vznikají různé alternativy, jsou tyto často nekompatibilní s produkty od společnosti Microsoft. V důsledku toho jsou uživatelé často nuceni zůstat u tohoto softwaru. Podobně čelí zadavatelé vendor lock-in situacím, kdy jsou závislí na odborných znalostech dodavatele, který má detailní přehled o poskytované službě i vnitřních procesech zadavatele, což jim znemožňuje snadno přejít k jinému dodavateli.
Dalším závažným problémem je právní závislost na dodavateli, což je běžné zejména právě ve veřejném sektoru. Mnozí zadavatelé nemají právně ošetřeno vlastnictví klíčových komponent systému, což jim brání v jeho případné úpravě nebo změně. Vendor lock-in výrazně omezuje možnosti zadavatele, pokud jde o manipulaci se stávajícím systémem. To ale neznamená, že žádné možnosti neexistují. Jedním z řešení je podle zákona využití jednacího řízení bez uveřejnění, čemuž se věnuje kapitola 2.3. této metodiky. Tento postup sice neřeší základní problém, ale může být dočasným řešením, zejména pokud zadavatel nemá dostatek času na jinou variantu a je fakticky nucen tak zadat zakázku tomu samému dodavateli. Je však důležité zvážit riziko, včetně pokuty od ÚOHS (anebo i zrušení zadávacího řízení, pokud smlouva ještě nebyla uzavřena, včetně potenciálních rizik reputačních), pokud zadavatel nebude schopen dostatečně odůvodnit svůj postup. Rizikem je i možné dovození porušení rozpočtové kázně ve smyslu § 44 zákona č. 218/2000 Sb., o rozpočtových pravidlech, v platném znění, a s tím spojený odvod za porušení rozpočtové kázně dle § 44a daného zákona, případně nevyplacení dotace nebo její části dle § 14e daného zákona.
Alternativním řešením jsou ještě „povolené“ nepodstatné změny závazku ve smyslu § 222 ZZVZ.
Další možností je zcela nové řešení systému, což se může jevit jako vhodné, ale je nutné vzít v úvahu časovou a finanční náročnost tohoto postupu. Problémy mohou také vzniknout v oblasti technické proveditelnosti datového přenosu a dalších nákladů. Jako nejvýhodnější se tedy může jevit kombinace obou variant – zadání zakázky na rozšíření stávajícího systému s možností zapojení současného dodavatele i dalších potenciálních dodavatelů. Tento přístup může přinést úsporu času a finančních prostředků, zejména v oblasti vývoje nového systému.
Lze tedy konstatovat, že únik z vendor lock-in je možný, ale pravděpodobně bude náročný a zdlouhavý.
Shrnutí typických situací vedoucí k potřebě úniku z vendor lock-in
Existuje několik klíčových okolností, které mohou zadavatele přimět k hledání úniku z vendor lock-in. Mezi nejčastější patří:
Dodatečné rozvojové práce
Změny a v průběhu času měnící se požadavky jsou neuralgickým bodem vývoje každého software. Téměř neexistuje ICT produkt, který by byl odevzdán přesně podle zadání, aniž by vyvstala potřeba toto zadání v průběhu prací nebo i později upravovat či upřesňovat. Vágní či chybné zadání může způsobit zvýšené náklady na straně zadavatelů (nejen z důvodů vendor lock-in), ale může představovat problém i pro dodavatele.
Z pohledu zadavatelů jsou ohledně budoucích dodatečných rozvojových prací klíčovými faktory zejména:
Zadávání veřejných zakázek, v oblasti informačních technologií zvlášť, je velice složitou a komplikovanou disciplínou, jelikož se vedle sebe často střetávají protichůdné požadavky na poptávaný předmět veřejné zakázky od různých organizačních jednotek zadavatele, dále zadavatel často nemá potřebnou odbornost při specifikaci předmětu veřejné zakázky, a v neposlední řadě často nemá i potřebný časový prostor na vypracování precizní zadávací dokumentace.
Výše uvedené může následně v zadávacím řízení způsobit řadu zcela zásadních obtíží (právních i technických). Pokud se je zadavateli nepodaří vhodným způsobem vyřešit, zadělává si do budoucna zvoleným postupem na vendor lock-in, a to i v prostředí, kde existuje více potenciálních dodavatelů, resp. i možných ICT řešení. Nepodaří-li se proprietárnímu uzamčení předejít a chce-li zadavatel např. objednat rozvojové práce v rozsahu přesahující nepodstatné změny závazku ze smlouvy na veřejnou zakázku (ve smyslu § 222 ZZVZ), řešení může spočívat i ve využití jednacího řízení bez uveřejnění (JŘBU), ovšem pouze za splnění podmínek stanovených zákonem a dále i dovozovaných judikaturou správních soudů, popř. i rozhodovací praxí orgánu dohledu (ÚOHS), nebo zadáním nové zakázky na zcela nový informační systém na „zelené louce“ (mimo JŘBU).
Při zadání zakázky „na zelené louce“ je však třeba brát v potaz i nákladovost takového řešení včetně fakticky minimálně částečně i znehodnocení původní investice a nelze opomenout ani výraznou konkurenční výhodu stávajícího dodavatele v takovém případném novém zadávacím řízení, bude-li předmět zakázky obdobný tomu stávajícímu, a to z důvodu znalosti potřeb/infrastrukturního prostředí zadavatele, nebo nižších nákladů a menšího času nutného na vývoj (a tím opět nižších nákladů) z důvodu už jednou de facto vyvinutého řešení, čímž je možné nabídnout i výrazně nižší nabídkovou cenu než konkurence a tím efektivně odmazat hospodářskou soutěž; zde pak i hodně záleží na případných hodnotících kritériích takové navazující veřejné zakázky, aby zadavatel vliv nabídkové, pořizovací ceny na celkové hodnocení utlumil (při dodržení zákonných pravidel pro hodnocení nabídek); případně lze stanovit v zadávací dokumentaci nebo ve výzvě k podání nabídek i mimořádně nízkou nabídkovou cenu).
Každé řešení stavu vendor lock-in představuje větší či menší výhody nebo nevýhody. Největším rizikem zpravidla bývá riziko neúměrně vysokých nákladů při ukončení smlouvy se stávajícím dodavatelem. Oproti tomu však stojí riziko dalšího zhoršení stavu vendor lock-in při pokračování čerpání služeb ze stávající nevýhodné smlouvy.
V nové smlouvě na veřejnou zakázku je pak také zásadní správně definovat požadavky na otevřenost a interoperabilitu (tedy míru vzájemné propojenosti a informační spolupráce mezi jednotlivými systémy), aby se zabránilo opětovnému stavu vendor lock-in.
Nelze však opomenout ani využití případných zákonných omezení autorského práva k počítačovému programu dle § 66 autorského zákona.
Na základě výše uvedeného proto zadavatelé využívají k zadání požadované úpravy informačního systému zpravidla jednací řízení bez uveřejnění (JŘBU) podle ustanovení § 63 odst. 3 písm. c) ZZVZ (tj. že veřejná zakázka může být splněna pouze určitým dodavatelem, neboť je to nezbytné z důvodu ochrany výhradních práv včetně práv duševního vlastnictví) a níže popsaného odst. 4 ZZVZ.
V případě toliko technických příčin vendor lock-in by v úvahu přicházel postup dle § 63 odst. 3 písm. b) ZZVZ, tj. že veřejná zakázka může být splněna pouze určitým dodavatelem, neboť z technických důvodů neexistuje hospodářská soutěž (zadavatel se totiž může dostat do stavu vendor lock-in i při maximálně širokém licenčním oprávnění (které má z hlediska pravidel 3E jinak také svou nevýhodu – zpravidla platí rovnice, že čím větší přístup -> tím větší obchodní riziko pro dodavatele -> tím dražší).
Lze si pochopitelně představit i kombinaci naplnění obou formálních podmínek dle uvedeného písm. b) a c). Neexistenci jiného dodavatele přitom je nutno prokázat v kontextu nikoliv pouze ČR, ale domníváme se v kontextu všech států dle ustanovení § 6 ZZVZ, tedy členských států Evropské unie, Evropského hospodářského prostoru nebo Švýcarské konfederace, nebo i jiných států, které mají s Českou republikou nebo s Evropskou unií uzavřenu mezinárodní smlouvu zaručující přístup dodavatelům z těchto států k zadávané veřejné zakázce.
JŘBU je tak možné využít, při splnění zákonných podmínek, jako nástroj řešení vendor lock-in zejména v situacích, kdy související veřejná zakázka je natolik specifická, že pouze jediný subjekt v podobě stávajícího dodavatele je schopen ji splnit (například kvůli zmiňovaným specifickým technickým podmínkám či duševním právům). JŘBU představuje formu zadávání veřejné zakázky s minimální úrovní transparentnosti a formalizace, přičemž by mělo být využíváno pouze v naprosto výjimečných případech. I při jeho výjimečném užití však téměř vždy nachází nepochopení ze strany dozorového úřadu – tedy ÚOHS a správních soudů, jež označují takový postup za rozporný se ZZVZ. Důvodem jeho omezeného použití je především fakt, že snižuje prostor pro hospodářskou soutěž, kdy zadavatel oslovuje předem daný okruh dodavatelů – či pouze jedno jediného. Tento postup je totiž jediným typem nadlimitního zadávacího řízení, které nevyžaduje zákonnou povinnost uveřejnit oznámení o zahájení řízení, což je jinak standardní postup při jiných formách zadávacích řízení. V rámci tohoto typu řízení oslovuje zadavatel pouze omezený počet dodavatelů, který sám určí, a v některých situacích může vyzvat k účasti jen jednoho dodavatele. Tento přístup přirozeně omezuje hospodářskou soutěž. I když však není JŘBU veřejně soutěženo, je nezbytné udržovat transparentní proces zadání zakázky a dokumentovat všechny kroky, které vedly k výběru konkrétního dodavatele. Základní zásady dle § 6 ZZVZ musí být nadále dodrženy.
K problematice právních a technických důvodů, ačkoliv v rovině ještě předchozího zákona o veřejných zakázkách, se vyjádřil v minulosti už Nejvyšší správní soud, a to ve svých dvou rozsudcích ze dne 11. 1. 2013:
CITACE:
„Výše citované ustanovení vychází tedy z předpokladu, že předmět veřejné zakázky je natolik specifický, že může být realizován pouze jedním dodavatelem - a to především z technických důvodů, resp. z důvodu ochrany výhradních práv. Ochrana výhradních práv připadá v úvahu zejména v situaci, kdy zadavatel získal v minulosti licenční oprávnění, které je nezbytné pro pořízení dalšího plnění, a dodavatel nemá vůli udělit autorskoprávní nebo jinou licenci jiné osobě, která by plnění mohla zadavateli poskytnout. Technické důvody, které má § 23 odst. 4 písm. a) zákona č. 137/2006 Sb., o veřejných zakázkách, na mysli, mohou spočívat např. v požadavku zadavatele na zajištění kompatibility, v požadavku odůvodněném také technickými okolnostmi, pro které by plnění od jiného dodavatele vyvolalo nepochybně vyšší náklady nebo značné riziko nefunkčnosti již pořízeného plnění (zde informačního systému). Důvodem pro aplikaci tohoto ustanovení je skutečný a prokazatelný stav technické neslučitelnosti či provozních problémů, které by vznikly z důvodu změny dodavatele; uvedené je typické právě mimo jiné i pro oblast informačních technologií.“
(rozsudky Nejvyššího správního soudu ze dne 11. ledna 2013, č.j. 5 Afs 42/2012 – 53 a 5 Afs 43/2012 – 54)
Využití JŘBU postupem dle výše uvedeného § 63 odst. 3 písm. b) nebo c) (formální podmínky) je však dle ZZVZ podmíněno zároveň kumulativním, tedy současným splněním dvou dalších materiálních podmínek stanovených v § 63 odst. 4 ZZVZ (přitom všechny tyto podmínky musí být splněny k okamžiku zahájení JŘBU[3]):
První materiální podmínkou dle § 63 odst. 4 ZZVZ je, že pro zadání veřejné zakázky nelze využít jiného přiměřeného řešení, tj.:
Spíše se přikláníme k výkladu, že v případě ekonomické argumentace by podle našeho názoru vyšší cena musela činit alternativu minimálně podstatně “nepřiměřeně” dražší, ideálně až za hranicí reálných ekonomických možností zadavatele (nejde-li o synonymum), a to s ohledem na celkové náklady životního cyklu, nutnost integrace, technických rizik a dopadů na efektivitu plnění původní i navazující veřejné zakázky. Zadavatel by musel své rozhodnutí velmi důkladně odůvodnit a musel by podle nás prokázat, že neúměrně vyšší cena (nebo obdobně neúměrné technické potíže) spojené s případnou alternativou jsou objektivním faktorem, které mu fakticky znemožňují volit takové alternativní řešení, tj. i konat transparentní soutěž, a že v případě zadání řešení stávajícímu dodavateli nejde jen o subjektivní preferenci zadavatele.
CITACE:
„Jednací řízení bez uveřejnění lze využít, pokud jsou důvody pro jeho použití objektivní, tedy nezávislé na vůli zadavatele. Není sporu o tom, že pokud by se zadavatel svým vlastním zaviněným postupem dostal do situace, kdy musel přidělit zakázku pouze jedné určité společnosti, porušil by tím zákon o veřejných zakázkách. Zadavatel se tak nemůže dovolávat existence pouhého jediného dodavatele (právně nebo fakticky) schopného realizovat předmět veřejné zakázky, pakliže sám tento „stav exkluzivity“ vytvořil, a to navíc teprve ve chvíli, kdy již není možné nastalou situaci dostupnými právními prostředky změnit.“
„…Přestože lze najít v obou případech styčné body při posuzování zákonnosti postupu zadavatele, je třeba v nyní posuzovaném případě, oproti případu pronajatých pozemků, jakož i případů, na něž odkazuje stěžovatel, velmi pečlivě vážit, zda postup zadavatele je skutečně zaviněný, či pouze nešikovný, neboť předmět veřejné zakázky zde je nepoměrně složitější, resp. jedná se o zakázku specializovanou“.
(rozsudky Nejvyššího správního soudu ze dne 11. ledna 2013, č.j. 5 Afs 42/2012 – 53 a 5 Afs 43/2012 – 54)
K otázce přičitatelnosti se vyjádřil Soudní dvůr EU ve svém jednom z recentních rozsudků následovně:
CITACE:
31. Zadavatel je proto povinen učinit vše, co od něj lze rozumně očekávat, aby se vyhnul použití čl. 31 bodu 1 písm. b) směrnice 2004/18 a využil řízení, které bude otevřenější hospodářské soutěži. S tímto požadavkem by přitom bylo neslučitelné, kdyby takovému zadavateli bylo umožněno toto ustanovení použít, když je mu vytvoření nebo zachování stavu exkluzivity, jehož se za tímto účelem dovolává, přičitatelné, například proto, že k dosažení výsledku sledovaného dotyčnou zakázkou nebylo nezbytné, aby tento zadavatel takový stav exkluzivity vytvořil, nebo proto, že měl k dispozici skutečné a z finančního hlediska přiměřené prostředky k tomu, aby takový stav ukončil.
38. Je na předkládajícím soudu, aby ověřil, zda s ohledem na okolnosti uzavření původní smlouvy, a zejména na okolnosti charakteristické pro období mezi 1. květnem 2004 a 1. březnem 2016, byl stav exkluzivity, jehož se dovolává GFŘ k tomu, aby odůvodnilo použití čl. 31 bodu 1 písm. b) směrnice 2004/18, přičitatelný jemu samotnému zejména proto, že mělo k dispozici skutečné a z finančního hlediska přiměřené prostředky k ukončení tohoto stavu exkluzivity v průběhu uvedeného období před tím, než se rozhodlo využít jednacího řízení bez uveřejnění.
39. S ohledem na výše uvedené důvody je třeba na položenou otázku odpovědět tak, že čl. 31 bod 1 písm. b) směrnice 2004/18 musí být vykládán v tom smyslu, že veřejný zadavatel nemůže použití jednacího řízení bez uveřejnění ve smyslu tohoto ustanovení odůvodnit ochranou výhradních práv, pokud je důvod takové ochrany přičitatelný jemu. Tato přičitatelnost se posuzuje nejen na základě skutkových a právních okolností, za jakých byla uzavřena smlouva na původní plnění, ale rovněž na základě všech okolností charakteristických pro období mezi datem uzavření této smlouvy a datem, kdy zadavatel zvolí řízení, které má být použito pro zadání navazující veřejné zakázky.
(rozsudek Soudního dvora EU ve věci C‑578/23 ze dne 9. ledna 2025)
Na výše uvedený rozsudek Soudního dvora EU ve věci C-578/23 navázal i Nejvyšší správní soud ČR ve svém rozsudku č.j. 5 As 64/2022-57 ze dne 7. 3. 2025, když ve svém odůvodnění tohoto rozsudku konstatuje:
CITACE:
[30] Podle Soudního dvora je proto nezbytné se zabývat nejen skutkovými a právními okolnostmi, za jakých byla uzavřena smlouva na původní plnění, nýbrž i všemi okolnostmi v období mezi datem uzavření této smlouvy a datem, kdy zadavatel zvolí jednací řízení bez uveřejnění, které má být použito pro zadání navazující veřejné zakázky (bod 39). Pokud by totiž zadavatel měl skutečnou možnost stav exkluzivity ukončit v období před tím, než se rozhodl jednací řízení bez uveřejnění využít, nebyla by materiální podmínka naplněna. Může tak nastat situace, kdy při uzavření původní smlouvy dojde k oprávněnému založení stavu exkluzivity, avšak v mezidobí před zadáním navazující veřejné zakázky dojde ke změně okolností, v důsledku kterých se zadavatel může ze stavu exkluzivity vymanit a navazující nebo zcela novou veřejnou zakázku zadat v některé z otevřenějších forem zadávacího řízení. Pokud by i přesto použil jednací řízení bez uveřejnění, nebyla by materiální podmínka naplněna. Stav exkluzivity by mu totiž byl přičitatelný. Z rozsudku Česká republika – Generální finanční ředitelství tak jednoznačně vyplývá, že se zadavatel nemůže stavem exkluzivity hájit do nekonečna, pokud má možnost se z něj vymanit.
[31] Výše uvedené závěry Soudního dvora se bez dalšího použijí na veřejné zakázky, u kterých stav exkluzivity vznikl po přistoupení ČR k Evropské unii v roce 2004. Jak totiž uvedl Soudní dvůr v bodě 35 rozsudku, „je třeba připomenout, že v souladu se zásadou okamžitého a úplného použití ustanovení unijního práva na nové členské státy měla Česká republika ode dne přistoupení k Evropské unii dosáhnout souladu se směrnicí Rady 93/36/EHS ze dne 14. června 1993 o koordinaci postupů při zadávání veřejných zakázek na dodávky (Úř. věst. 1993, L 199, s. 1; Zvl. vyd. 06/02, s. 110), která byla zrušena a nahrazena směrnicí 2004/18 a znění jejího čl. 6 odst. 3 písm. b) bylo převzato do čl. 31 bodu 1 písm. b) směrnice 2004/18“.
[41] Právní názor Soudního dvora v rozsudku Česká republika – Generální finanční ředitelství však výrazně mění pohled na hodnocení materiální podmínky jednacího řízení bez uveřejnění tak, jak jej dosud vnímala část judikatury Nejvyššího správního soudu (viz předchozí část tohoto rozsudku) a jak jej vnímaly správní orgány a krajský soud. To je pro nyní posuzovanou věc klíčové a nelze dospět k závěru, že by již uzavření původní smlouvy samo o sobě vedlo k tomu, že by právní předchůdce stěžovatele nemohl zadat nyní posuzovanou zakázku v jednacím řízení bez uveřejnění. Je tak třeba zkoumat, zda trvání stavu exkluzivity je způsobeno jednáním či nečinností stěžovatele (případně jeho právního předchůdce) po uzavření původní smlouvy.
(rozsudek Nejvyššího správního soudu ČR ve svém rozsudku č,j. 5 As 64/2022-57 ze dne 7. 3. 2025)
Obdobně se vyjadřoval předtím už i Krajský soud v Brně ve svém rozsudku ze dne 21. 12. 2021, sp. zn.: 29 Af 12/2018-108, ačkoliv byl tento rozsudek výše uvedeným rozsudkem Nejvyššího správního soudu zrušen (byť Nejvyšší správní soud s tímto názorem KS v Brně nijak nepolemizuje).
CITACE:
(46.) …. Při objektivním hodnocení splnění podmínek pro zadávání předmětné veřejné zakázky v JŘBU provedeném se zohledněním aktuální znalosti všech skutkových okolností tak měl žalobce dospět k jednoznačnému závěru, že onou případnou nevědomostí již ani nelze argumentovat, neboť se během času změnila ve vědomost, že daný informační systém je již poměrně dlouho provozován a provozován má být i nadále. Jinak obecně řečeno, při zadávání navazující veřejné zakázky není hlavním předmětem činnosti zadavatele zjišťování a hodnocení izolovaného skutkového a právního stavu ke dni zadávání původní zakázky, resp. uzavírání původní smlouvy, ale primárně vyhodnocení celkové situace v okamžiku zadání navazující veřejné zakázky v JŘBU, přičemž podmínky pro její zadání je třeba posuzovat s ohledem na zákonnou úpravu účinnou v době jejího zadávání a se zohledněním rozhodovací praxe žalovaného a soudů známé v tu dobu….
(zrušený rozsudek Krajského soudu v Brně ze dne 21. 12. 2021, sp. zn.: 29 Af 12/2018-108)
S ohledem na výše uvedenou recentní judikaturu jsme toho názoru, že současná, resp. budoucí judikatura by měla na otázku (ne)existence materiální podmínky nezaviněné exkluzivity pohlížet tak, že zadavatel musí ustát důkazní břemeno, že tato podmínka zde byla nadále i ke dni zahájení JŘBU, tj. že zadavatel neměl skutečnou možnost tento stav nezaviněné (právní a / nebo technické) exkluzivity v mezidobí ode dne jeho vzniku do dne zahájení JŘBU ukončit s tím, že možnou výjimkou mohou být stavy exkluzivity vzniklé do přistoupení ČR do EU dne 1. května 2004.
Podmínky pro užití JŘBU je přitom třeba vykládat restriktivně, k tomu existuje dnes už ustálená tuzemská i evropská judikatura (byť týkající se třeba ještě předchozího zákona o veřejných zakázkách, resp. předchozí evropské zadávací směrnice).
CITACE:
„Nadto i tuzemská rozhodovací praxe v případech podmínek pro použití jednacího řízení bez uveřejnění akcentuje potřebu jejich restriktivního výkladu. I Nejvyšší správní soud v rozsudku ze dne 28. 11. 2012, čj. 1 Afs 23/2012-102, z tohoto pojetí vycházel a konstatoval, že z druhů zadávacích řízení, které upravuje § 21 ZVZ, je jednací řízení bez uveřejnění v porovnání s ostatními postupy bezesporu postupem nejméně formalizovaným a nejméně kontrolovatelným (jedním z důvodů je např. skutečnost, že zadavatel v rámci tohoto postupu přímo oslovuje konkrétního zájemce bez jakkoliv formalizovaného výběru; dále je zadavatel oprávněn dohodnout s vyzvanými zájemci i jiné podmínky plnění veřejné zakázky, než které byly uvedeny ve výzvě k jednání či v zadávací dokumentaci apod.). I z takto podaného východiska je tedy důvodu vycházet.“
(rozsudek Krajského soudu v Brně ze dne 3. 10. 2013, čj. 62 Af 48/2012-160, dostupný ve Sbírce rozhodnutí Nejvyššího správního soudu 3179/2015, https://sbirka.nssoud.cz/cz/2015-3)
CITACE:
„78. V této souvislosti je dále nutno podotknout, že charakter technických důvodů opravňujících zadavatele zadat veřejnou zakázku v jednacím řízení bez uveřejnění musí být takový, aby tyto důvody ve svém důsledku znamenaly jednoznačnou a nezpochybnitelnou nezbytnost zadání předmětné veřejné zakázky právě vybranému dodavateli. Z dokladů prokazujících existenci technických důvodů pro použití jednacího řízení bez uveřejnění, aby mohly být považovány za relevantní podklady obsahující odborné technické hodnocení prokazující technickou výlučnost vybraného dodavatele, musí vyplývat, jaké konkrétní technické důvody (které by měly být jasně a přesně popsány) existují a vedou k tomu, že předmět šetřené veřejné zakázky nemůže realizovat jiný dodavatel, než právě vybraný dodavatel.
79. V návaznosti na výše uvedené Úřad opakovaně zdůrazňuje, že otázku splnění podmínek pro zadání veřejné zakázky v jednacím řízení bez uveřejnění je nutné posuzovat restriktivně…..
210…. Úřad přitom nikterak netvrdí, že obviněný by byl nucen za účelem prokázání výše uvedených skutečností si nechat zpracovat právě odborný či znalecký posudek (ačkoliv v případě zadávání veřejné zakázky v jednacím řízení bez uveřejnění s odkazem na technické důvody podle § 63 odst. 3 písm. b) zákona se takový postup z hlediska prokázání existence technických důvodů jeví jako nanejvýš vhodný), nicméně obviněný je povinen předložit Úřadu takové doklady, z nichž jednoznačně vyplývá splnění veškerých zákonem požadovaných podmínek pro možné použití jednacího řízení bez uveřejnění. V šetřeném případě však nelze akceptovat pouhé konstatování obviněného o možném vzniku nepřiměřených technických obtíží v případě realizace dané veřejné zakázky jinou osobou, než vybraným dodavatelem Nowatron Elektronik, když obviněný tyto nepřiměřené technické obtíže dostatečně podrobně nespecifikuje a nezpochybnitelným způsobem neprokazuje, z jakého důvodu tyto jednotlivé konkrétní technické obtíže znemožňují realizaci předmětu plnění dané veřejné zakázky jiným dodavatelem.“
(rozhodnutí Úřadu pro ochranu hospodářské soutěže ze dne 19. června 2019, č. j.: ÚOHS-S0171,0172,0173,0174/2019/VZ-17200/2019/541/Oko)
Nebo obdobně na zmíněné evropské úrovni:
CITACE:
„Úvodem je třeba připomenout, že jednací řízení má výjimečnou povahu, jelikož čl. 6 odst. 2 a 3 směrnice 93/36 taxativně a výslovně vyjmenovává jediné výjimky, pro které je povoleno použití jednacího řízení (rozsudek ze dne 8. dubna 2008, Komise v. Itálie, C 337/05, Sb. rozh. 2008, s. I 2173, bod 56 a citovaná judikatura).
Je třeba rovněž připomenout, že podle ustálené judikatury musí být tato ustanovení, jakožto odchylky od pravidel určených k zajištění účinnosti práv uznaných právem Společenství v oblasti veřejných zakázek, vykládána restriktivně….“
(rozsudek Soudního dvora EU ze dne 15. října 2009, Komise v. Německo, C‑275/08, EU:C:2009:632, body 57 až 64, dostupný v plném znění v německém a francouzském jazyce zde)
Klíčové dokumenty k doložení JŘBU:
V případném přezkumném řízení o naplnění podmínek JŘBU tak bude také nejspíše i zkoumáno, zda zadavatel učinil dostatečná preventivní opatření za účelem vyloučení budoucí závislosti na jediném dodavateli ve formě např. vyhrazených změn závazku dle § 100 ZZVZ. Zadavatel může též čelit dotazům na provedení případného seriózního šetření na úrovni EU s cílem identifikovat možné alternativní dodavatele (viz výše citované rozsudky Soudního dvora EU sp. zn. C‑275/08 bod 63 a sp. zn. C‑578/23, bod 30).
Pro tyto účely by měl zadavatel disponovat zprávou o průzkumu trhu, která by dokumentovala, že na trhu neexistuje jiný vhodný dodavatel, který by byl schopen nabídnout srovnatelné služby nebo řešení, resp. ani přiměřenou alternativu nebo náhradu poptávaného plnění, a to z hledisek technických i ekonomických, tzn. i včetně příslušných technických a ekonomických analýz.
Obecně tedy navíc platí, že důkazní břemeno leží na zadavateli (lze tedy doporučit pamatovat na to již při přípravě JŘBU a opatřit si všechny relevantní důkazy) a zákonné podmínky pro jeho umožnění je třeba vykládat zásadně restriktivním způsobem.
K důkaznímu břemenu v otázce použití JŘBU (byť ještě podle starého zákona) se ÚOHS a Krajský soud v Brně vyjádřily následovně:
CITACE:
„Úřad přitom zcela jistě není povinen jakkoliv vyvracet tvrzení zadavatele o neporušení § 23 odst. 4 písm. a) zákona, neboť je to zadavatel, koho stíhá povinnost tato tvrzení prokázat, a pokud je není schopen prokázat, pak se má za to, že v souladu se zákonem nepostupoval. Přísnost takové konstrukce je pak mimo jiné dána právě snahou o eliminaci používání tohoto druhu zadávacího řízení, a to v zájmu zachování co nejvíce transparentní hospodářské soutěže. K tomu pro úplnost podotýkám, že Úřad je skutečně, jak v rozkladu tvrdí zadavatel, povinen pečlivě zkoumat podklady poskytnuté zadavatelem za účelem obhájení jeho postupu, avšak tyto podklady musí požívat kvality důkazů prokazujících tvrzené skutečnosti, nikoliv obsahovat pouhé konstatování bez náležitého osvědčení existence podmínek pro uplatnění § 23 odst. 4 písm. a) zákona.“
(rozhodnutí Úřadu pro ochranu hospodářské soutěže, č.j. R0064/2016/VZ-39883/2016/323/KKř, ze dne 29. září 2016)
„[192] Z výše uvedené judikatury dále vyplývá, že důkazní břemeno ohledně existence okolností opravňujících k použití jednacího řízení bez uveřejnění leží na tom, kdo se jich dovolává – v daném případě tedy na zadavateli. Je to dáno specifičností a výjimečností jednacího řízení bez uveřejnění. Zadavatel musí být schopen bez sebemenších pochybností prokázat, že jím zvolený postup byl v souladu se zákonem. Nadto je třeba konstatovat, že pokud došlo k přezkumu postupu zadavatele ze strany žalovaného, tento musí splnění podmínek pro použití jednacího řízení bez uveřejnění, jsou-li zpochybňovány, postavit na jisto, a pokud je to nezbytné i vlastním dokazováním. Zejména v případě sporných odborných otázek se nemůže spolehnout na vyjádření pouze z jedné ze stran, popř. si účelově vybrat z různých odborných vyjádření pouze ta fakta, která se jemu hodí.“
(rozhodnutí Krajského soudu v Brně, č.j. 31 Af 54/2012 – 443, ze dne 9. 4. 2013)
V případě, že se přesto zadavatel rozhodne jít cestou JŘBU, doporučujeme, aby učinil součástí zadávací dokumentace přílohy ve formě dokladů, či jiných informací, které prokazují, že vyvinul snahu předejít zadání veřejné zakázky v JŘBU tím, že se snažil najít cest pro zadání veřejné zakázky v jednom z transparentnějších zadávacích řízení (např. že se pokusil od stávajícího dodavatele dosáhnout potřebného rozšíření licenčního ujednání nebo získání dokumentace k programovému rozhraní – API).
Z hlediska přípustnosti budoucího JŘBU, resp. zejména z hlediska zvýšení pravděpodobnosti obstání takového postupu v následném případném přezkumném řízení, se jeví také vhodné, aby zadavatel disponoval ještě z fáze před zadáním původní veřejné zakázky interním analytickým dokumentem (např. v rámci analýzy celého uvažovaného životního cyklu uvažovaného předmětu veřejné zakázky a předpokládaných nákladů spojených s každou fází životního cyklu), schváleným výkonným orgánem zadavatele na některém ze svých zasedání (z hlediska i časové průkaznosti vzniku takového dokumentu), ze kterého bude vyplývat, že budoucí změny informačního systému nejsou předpokládány (například z důvodu, že jde o software řešící spíše jen nějakou jednorázovou, časově omezenou a tudíž i neměnnou potřebu zadavatele, u které se nepřepokládají požadavky na budoucí úpravy).
Doporučit lze i vyhotovení rizikové, resp. dopadové analýzy z hlediska dopadů nezadání dotčené zakázky v JŘBU na kontinuitu provozu, byť provozní důvody samy o sobě nejsou dostatečně validním argumentem pro JŘBU, jak níže dále komentujeme.
Odůvodnění použití JŘBU musí být vždy součástí písemné zprávy zadavatele dle § 217 ZZVZ.
Bylo již zmíněno, dozorové orgány se na použití JŘBU dívají přísnou optikou, a tak zadavatelé zkoušejí „kreativně“ zadat veřejnou zakázku v jiném druhu zadávacího řízení, nejčastěji v otevřeném řízení (kam se přihlásí například i dceřiná společnost stávajícího dodavatele). V tomto zadávacím řízení zadavatel obdrží pouze jedinou nabídku, což vyvolává důvodně otázky ohledně reálnosti soutěže mezi dodavateli, ze které by měl zadavatel těžit, i zákonnosti takového postupu a může pochopitelně vést k podaným námitkám a i následnému přezkumu ze strany ÚOHS.
Přesto lze nalézt i rozhodnutí pro zadavatele s pozitivním závěrem:
CITACE:
„……Výše citované ustanovení vychází tedy z předpokladu, že předmět veřejné zakázky je natolik specifický, že může být realizován pouze jedním dodavatelem - a to především z technických důvodů, resp. z důvodu ochrany výhradních práv. Ochrana výhradních práv připadá v úvahu zejména v situaci, kdy zadavatel získal v minulosti licenční oprávnění, které je nezbytné pro pořízení dalšího plnění, a dodavatel nemá vůli udělit autorskoprávní nebo jinou licenci jiné osobě, která by plnění mohla zadavateli poskytnout. Rovněž technické důvody, které má cit. ustanovení na mysli, mohou spočívat např. v požadavku zadavatele na zajištění kompatibility, v požadavku odůvodněném také technickými okolnostmi, pro které by plnění od jiného dodavatele vyvolalo nepochybně vyšší náklady nebo značné riziko nefunkčnosti již pořízeného plnění (zde informačního systému). Důvodem pro aplikaci tohoto ustanovení je skutečný a prokazatelný stav technické neslučitelnosti či provozních problémů, které by vznikly z důvodu změny dodavatele. Nutno konstatovat, že uvedené je typické právě mimo jiné i pro oblast informačních technologií. Zakázku, o kterou se v případě žalobce jednalo, lze dle názoru Nejvyššího správního soudu považovat za specializovanou veřejnou zakázku, u níž lze postup, který uplatnil žalobce, shledat opodstatněným.“
„….Dalším klíčovým faktorem je proměnlivost úkolů zadavatele. Pokud zadavatel připravuje software tak, aby software splnil v dané chvíli objektivně stanovené úkoly a byl po uplynutí určité doby životnosti vyřazen, zajisté tomu přizpůsobí i zadávací podmínky. Nelze tedy, jak to učinil stěžovatel, konstatovat bez dalšího, že zadavatel nenaplnil materiální podmínku ustanovení § 23 odst. 4 písm. a) zákona o veřejných zakázkách, když si v předcházející zakázce sám vytvořil právní omezení.“
(rozsudky Nejvyššího správního soudu ze dne 11. ledna 2013, č.j. 5 Afs 42/2012 – 53 a 5 Afs 43/2012 – 54)
Teoreticky lze zadat zakázku v JŘBU podle ZZVZ také z důvodu krajně naléhavých okolností, které zadavatel nemohl předvídat a ani je nezpůsobil, a nelze-li dodržet lhůty pro otevřené řízení, užší řízení nebo jednací řízení s uveřejněním. Dle našeho názoru však už jen díky nehmotné povaze software nelze o této (i jinak krajní) zákonné možnosti dost dobře uvažovat. Navíc dle rozhodovací praxe platí, že z tohoto důvodu nelze zadat zakázku na dobu překračující období takové krajní naléhavosti, resp. na dobu, kterou bude zadavatel nezbytně potřebovat, aby předmětné plnění do budoucna poptal v rámci některého z „otevřenějších“ druhů zadávacích řízení (rozsudek KS Brno 62 Af 68/2017-209)[5]. Důkazní břemeno i v tomto případě leží na zadavateli.
Pro úplnost zmiňujeme, že ani provozní důvody v podobě nutnosti zajištění kontinuity provozu nemohou bez dalšího jako legitimní důvod JŘBU obstát, tj. ani dopadová analýza vyhodnocující rizika, která by se materializovala, pokud by došlo k nucenému přerušení služeb, pokud by nedošlo k urychlenému zadání zakázky v JŘBU, sama o sobě nestačí.
CITACE:
„Odkaz zadavatele na dosavadního dodavatele (jeho znalostí a zkušeností získané právě na základě jejich dosavadní spolupráce) a potřebu zajištění kontinuity (zde: dodávky HW zařízení, SW vybavení a poskytování souvisejících IT služeb) nemůže bez dalšího obstát jako důvod pro použití jednacího řízení bez uveřejnění ve smyslu § 23 odst. 4 písm. a) zákona č. 137/2006 Sb., o veřejných zakázkách; nejde o technický důvod ani o důvod spočívající v ochraně výhradních práv, jež předvídá citované ustanovení, ale o důvod spíše organizačně-provozní povahy, jehož akceptace by ve výsledku vedla k nedůvodnému popření soutěžního prostředí.“
(rozsudek Krajského soudu v Brně ze dne 21. 12. 2015, čj. 30 Af 78/2013-148)
V judikatuře správních soudů, konkrétně Krajského soudu v Brně, který je orgánem soudního přezkumu pro rozhodnutí ÚOHS, se lze setkat i náhledem, že hlediska 3E, tj. přítomné principy účelnosti, hospodárnosti a efektivnosti mohou vyvážit nepřítomnost výše uvedených zákonných podmínek pro JŘBU a je pravdou, že takový postup (min. ve svém důsledku) by mohl i více odpovídat zákonu 320/2001 Sb., o finanční kontrole ve veřejné správě, v platném znění, zákonu č. 218/2000 Sb., o rozpočtových pravidlech, v platném znění, nebo zákonu č. 219/2000 Sb., o majetku České republiky, v platném znění, a jejich požadavkům na hospodárnost, neboť i v ekonomičnosti (ekonomické racionalitě) spatřuje zákon o zadávání veřejných zakázek jeden ze svých záměrů.
CITACE:
„81. Jak již soud uvedl ve výše citovaném rozsudku č. j. 62 Af 30/2018-101, pokud zadavatel s ohledem na konkrétní okolnosti v době zadávání původní veřejné zakázky musel rozumně předpokládat, že v budoucnu vznikne potřeba zadání navazujících veřejných zakázek, nicméně přesto akceptoval licenční ujednání vylučující, aby navazující veřejná zakázka mohla být splněna jiným dodavatelem než tím, který byl vybrán v původním zadávacím řízení, znemožní svým postupem zadávání navazujících veřejných zakázek v některém z „otevřenějších“ druhů zadávacího řízení a podmíní zadávání navazujících řízení v jednacím řízení bez uveřejnění s odkazem na ochranu práv duševního vlastnictví, nemusí vždy dojít k porušení zákona. Popsaná „nešikovnost“ zadavatele při zadávání původní veřejné zakázky totiž může být vyvážena hlediskem hospodárnosti, neboť postup zadavatele je nutno hodnotit i z hlediska hospodárnosti, efektivnosti a účelnosti nakládání s veřejnými prostředky. I ekonomičnost zvoleného řešení totiž odpovídá cílům zákona o zadávání veřejných zakázek (shodně viz výše citovaný rozsudek Nejvyššího správního soudu č. j. 5 Afs 42/2012-53 nebo rozsudek z 28. 3. 2018, č. j. 2 As 292/2017-34).“
„87. Soud úvodem k zásadě hospodárnosti zvoleného řešení uvádí, že se neztotožňuje se závěry předsedy žalovaného, že by její uplatnění přicházelo v úvahu až tehdy, je-li kumulativně splněna formální i materiální podmínka jednacího řízení bez uveřejnění. Pokud by obě podmínky pro použití jednacího řízení bez uveřejnění byly splněny, zadání veřejné zakázky by bylo souladné se zákonem o zadávání veřejných zakázek a nebylo by nutné prokazovat hospodárnost zvoleného řešení. Z dosavadní judikatury správních soudů vyplývá, že hledisko hospodárnosti, účelnosti a efektivnosti vynakládání veřejných prostředků může odůvodnit postup zadavatele v případě, že materiální podmínka použití jednacího řízení bez uveřejnění naplněna není (zadavatel při zadání původní zakázky nepostupoval dostatečně obezřetně), ale jeho postup ospravedlňuje ekonomická výhodnost zvoleného řešení (viz např. rozsudek Krajského soudu v Brně č. j. 62 Af 30/2018-101, bod 52, nebo rozsudek Nejvyššího správního soudu ze dne 15. 2. 2018, č. j. 5 As 26/2017-22, bod 30). Z těchto východisek ostatně vycházely i úvahy prvostupňového správního orgánu, s nimiž se soud v podstatě ztotožnil.“
„88. Aby zadavatel mohl s úspěchem argumentovat hospodárností zvoleného řešení, musel by prokázat ekonomickou výhodnost jeho postupu jako celku, tj. od zadání původní veřejné zakázky po navazující zadávací řízení formou jednacího řízení bez uveřejnění, nikoliv pouze finanční výhodnost dílčího zadávacího řízení navazujícího na nešikovný postup zadavatele při zadání původní veřejné zakázky. Jen komplexní ekonomické zhodnocení prokazující zřejmou efektivnost zadavatelova postupu mohlo vést v dané věci k závěru, že žalobce byl oprávněn zadat veřejnou zakázku v jednacím řízení bez uveřejnění podle § 63 odst. 3 písm. a) zákona o zadávání veřejných zakázek. Takové důkazy však v nyní projednávaném případě nebyly předloženy. Nutnost komplexního náhledu na zásadu hospodárnosti přitom vyplývá i z rozhodovací praxe žalovaného, který zdůrazňuje, že právě při zadávání původní veřejné zakázky „musí zadavatel velice dobře posoudit, zda je hospodárné zadat zakázku i s požadavkem například na komentovaný zdrojový kód a povolení k tomu, aby dál mohl rozvíjet zadavatel software pomocí třetí osoby či širší licenční oprávnění, čímž bude zajisté předchozí veřejná zakázka sice finančně náročnější, protože dodavatel bude požadovat finanční prostředky navíc, avšak v následujících zakázkách již nebude zadavatel závislý na jednom dodavateli, či zda již takovéto rozšíření již není pravděpodobné, a proto by byly takto vynaložené prostředky navíc nehospodárné a zadavatel přístup ke zdrojovému kódu v budoucnu nijak nevyužije“ (viz rozhodnutí žalovaného ze dne 11. 6. 2015, č. j. ÚOHS-R173/2014/VZ-13930/2015/321/IPs, bod 50).“
(rozsudek Krajského soudu v Brně ze dne 18.02.2021, č.j. 30 Af 19/2019-115)
Podobně se vyjádřil v minulosti už i Nejvyšší správní soud:
CITACE:
Nejvyšší správní soud uvádí, že je nutno na toto žalobcovo chování hledět z hlediska hospodárnosti, efektivnosti a účelnosti nakládání s veřejnými prostředky. Pokud zadavatel bude požadovat, například komentovaný zdrojový kód a povolení k tomu, aby dál mohl rozvíjet software pomocí třetí osoby či širší licenční oprávnění, tak bude zajisté předchozí veřejná zakázka finančně náročnější, protože dodavatel bude požadovat finanční prostředky navíc. Je proto otázkou účelnosti takto vynaložených veřejných prostředků, jestli je správné, aby si zadavatel vyhrazoval práva, o kterých nelze v době přípravy zadávacího řízení rozumně očekávat, že nastanou. Pokud v průběhu životnosti softwaru nastane z hlediska zadavatele objektivní změna (nová legislativa, nové manažerské rozhodnutí nadřízených orgánů), tak může nastat situace, kdy by vyloučení použití jednacího řízení bez upozornění fakticky znamenalo zákonem stanovenou povinnost zadavatele pořídit určitý software znovu a znehodnotit již vynaloženou investici na dosavadní software. Dalším klíčovým faktorem je proměnlivost úkolů zadavatele. Pokud zadavatel připravuje software tak, aby software splnil v dané chvíli objektivně stanovené úkoly a byl po uplynutí určité doby životnosti vyřazen, zajisté tomu přizpůsobí i zadávací podmínky. Nelze tedy, jak to učinil stěžovatel, konstatovat bez dalšího, že zadavatel nenaplnil materiální podmínku ustanovení § 23 odst. 4 písm. a) zákona o veřejných zakázkách, když si v předcházející zakázce sám vytvořil právní omezení.
(rozsudek Nejvyššího správního soudu, ze dne 11.01.2013, sp. zn.: 5 Afs 42/2012 – 53)
Dovolujeme se v tomto směru nicméně odkázat i na dřívější rozhodnutí ÚOHS ze dne 23. května 2014, č.j. S604/2013/VZ-10977/2014/522/PLy:
CITACE:
„73. Zadavatel ve svém vyjádření i v dokumentaci k ekonomickým důvodům dále uvádí, že při hodnocení variant přihlížel k předpokládané ceně jednotlivých variant a to zejména s ohledem na hospodárné a efektivní vynakládání veřejných prostředků.
74. K uvedenému vyjádření zadavatele Úřad uvádí, že nelze než souhlasit se snahou zadavatele, postupovat jako řádný hospodář, a tak účelně a efektivně vynakládat finanční prostředky, avšak toho může být efektivně a objektivně dosahováno pouze tehdy, jsou-li respektovány základní zásady uvedené v § 6 zákona, jež zajišťují, že zakázky budou zadávány v rámci efektivní hospodářské soutěže, což v konečném důsledku zajistí snížení cen poptávaného plnění. Uvedené však v šetřeném případě nemohlo nastat, neboť zadavatel použitím JŘBU přímo vybral dodavatele, a tím vyloučil konkurenci dalších dodavatelů.
75. K výše uvedeným zadavatelem stanoveným variantám řešení Úřad v obecné rovině uvádí, že jakkoliv odborně provedená analýza či odborný posudek nemůže plnohodnotně nahradit soutěž mezi dodavateli podle zákona, neboť pouze takový způsob výběru nejvhodnější nabídky zcela naplňuje zásady uvedené v § 6 zákona. K uvedenému Úřad dodává, že podobná analýza či posudek mohou také stěží nahradit konkrétní cenové nabídky uchazečů, které mohou být v rámci konkurenčního boje sníženy na nepředpokladatelnou úroveň. Současně je nutné dodat, že právě oblast informačních technologií je specifická svým turbulentním vývojem, přičemž nelze proto akceptovat názor, že ekonomicky zaměřená analýza je schopna předvídat a vyhodnotit veškeré technologické vývojové trendy v dané oblasti, které mohou mít zásadní cenotvorný význam“.
(rozhodnutí Úřadu pro ochranu hospodářské soutěže ze dne 23. května 2014, č.j. S604/2013/VZ-10977/2014/522/PLy)
Nakonec i Krajský soud v Brně v jednom ze svých, byť dřívějších rozhodnutí (byť v trochu jiné souvislosti) uvedl:
CITACE:
„29. Nyní posuzovaná věc nadto podle zdejšího soudu ani v praktické rovině nemůže být příkladem kolize zásad. Právě pro naplnění cíle zákona o veřejných zakázkách, tedy kontrolovatelného, hospodárného, účelného a efektivního nakládání s veřejnými prostředky, je zachování otevřené hospodářské soutěže, pro kterou je zcela nezbytné dodržet zásadu transparentnosti, rovného zacházení a zákazu diskriminace, nutným předpokladem.“
(rozsudek Krajského soudu v Brně ze dne 14. června 2018, 62 Af 3/2017-243)
Byť tedy kompenzace zaviněné exkluzivity ekonomickou racionalitou byla už českou judikaturou v některých případech aprobována, ÚOHS se k tomuto přístupu staví nebo aspoň stavěl negativně (jak ukazujeme v citovaném rozhodnutí výše, tj. ve smyslu „cenové nabídky podané v prostředí hospodářské soutěže jsou jediným dostatečně relevantním dokladem o tržní ceně“) a nenacházíme pro nějaké podobné „kompenzační“ pojetí oporu ani u Soudního dvora EU, zejména pokud je v přiměřených finančních možnostech zadavatele, aby se z takového exkluzivního stavu vymanil. A i kdyby se ÚOHS podařilo nakonec „porazit“, znamená to další právní spor navíc.
Pokud nejsou naplněny výše uvedené formální a materiální podmínky JŘBU, není podle nás ze zákona zadavatel oprávněn zadat navazující veřejnou zakázku v tomto řízení. Zadavateli v takovém případě nezbývá nic jiného, než navazující veřejnou zakázku zadat (i.) v jiném druhu zadávacího řízení, ve kterém si ošetří adekvátně licenční a technické podmínky, nebo (ii.) využije ust. § 222 odst. 4, 5 nebo 6 zákona o zadávání veřejných zakázek (tzv. nepodstatné změny závazku ze smlouvy).
Pokud bude dohledovým orgánem nakonec zjištěno, že zadavatel nedodržel podmínky pro JŘBU, jak bylo uvedeno výše, bude se na zadavatelovo jednání (uzavření nové smlouvy v JŘBU se stávajícím dodavatelem) pohlížet jako na porušení zákona (přestupek podle ust. § 268 ZZVZ, za kterou může ÚOHS udělit pokutu 10 % ceny veřejné zakázky, nebo do 20 000 000 Kč, nelze-li celkovou cenu veřejné zakázky zjistit), případně, pokud ještě nebyla uzavřena smlouva, uloženo nápravné opatření podle ust. § 263 ZZVZ v podobě zrušení zadávacího řízení nebo vyhradil-li si v zadávací dokumentaci zadavatel možnost JŘBU v rozporu s § 66 ZZVZ nebo změnu závazku v rozporu s § 100 ZZVZ, uloží ÚOHS nápravné opatření spočívající v zákazu uplatnění takové výhrady, pokud to postačuje k provedení nápravy). Nelze vyloučit ani případnou trestněprávní odpovědnost zadavatele a jeho zástupců.
Chce-li zadavatel změnit závazek dodavatele (ale i svůj) ze smlouvy na plnění veřejné zakázky, tak ze zákona vyplývá, že při jakékoli změně závazku ze smlouvy na veřejnou zakázku je třeba posoudit, zdali se jedná o změnu podstatnou, či nepodstatnou. Základní posouzení, zda se v daném případě jedná o podstatnou změnu závazku, vychází z § 222 odst. 3 ZZVZ:
CITACE:
(3) Podstatnou změnou závazku ze smlouvy na veřejnou zakázku je taková změna smluvních podmínek, která by
a) umožnila účast jiných dodavatelů nebo by mohla ovlivnit výběr dodavatele v původním zadávacím řízení, pokud by zadávací podmínky původního zadávacího řízení odpovídaly této změně,
b) měnila ekonomickou rovnováhu závazku ze smlouvy ve prospěch vybraného dodavatele, nebo
c) vedla k významnému rozšíření rozsahu plnění veřejné zakázky.
V případě podstatných změn je zadavatel povinen provést nové zadávací řízení, neboť se jedná o tak zásadní změnu, že je měněna povaha původní veřejné zakázky a je nutné umožnit účast i jiným dodavatelům (výjimku představují smlouvy, které byly uzavřeny na základě veřejné zakázky, na níž se aplikuje zákonná výjimka z povinnosti zadat veřejnou zakázku v zadávacím řízení).
V případě podstatných změn tak v plnění veřejné zakázky nelze pokračovat a pro tyto účely poskytuje ZZVZ v § 223 odst. 1 zadavateli zákonnou možnost smlouvu na veřejnou zakázku vypovědět nebo od ní odstoupit.
Mezi nejčastější nepodstatné změny, které jsou tedy zákonem povoleny, se řadí změny závazků podle odst. 4, 5 a 6 § 222 ZZVZ, konkrétně
CITACE:
(4) Za podstatnou změnu závazku ze smlouvy na veřejnou zakázku se nepovažuje změna, která nemění celkovou povahu veřejné zakázky a jejíž hodnota je
a) nižší než finanční limit pro nadlimitní veřejnou zakázku a
b) nižší než
1. 10 % původní hodnoty závazku, nebo
2. 15 % původní hodnoty závazku ze smlouvy na veřejnou zakázku na stavební práce, která není koncesí.
Pokud bude provedeno více změn, je rozhodný součet hodnot všech těchto změn.
CITACE:
(5) Za podstatnou změnu závazku ze smlouvy na veřejnou zakázku se nepovažují dodatečné stavební práce, služby nebo dodávky od dodavatele původní veřejné zakázky, které nebyly zahrnuty v původním závazku ze smlouvy na veřejnou zakázku, pokud jsou nezbytné a změna v osobě dodavatele
a) není možná z ekonomických anebo technických důvodů spočívajících zejména v požadavcích na slučitelnost nebo interoperabilitu se stávajícím zařízením, službami nebo instalacemi pořízenými zadavatelem v původním zadávacím řízení a
b) způsobila by zadavateli značné obtíže nebo výrazné zvýšení nákladů.
CITACE:
(6) Za podstatnou změnu závazku ze smlouvy na veřejnou zakázku se nepovažují dodatečné stavební práce, služby nebo dodávky od dodavatele původní veřejné zakázky, které nebyly zahrnuty v původním závazku ze smlouvy na veřejnou zakázku, pokud jsou nezbytné a změna v osobě dodavatele
V rámci posuzování přípustnosti změn závazku dle odst. 5 a 6 je třeba zohlednit i odst. 9 § 222 ZZVZ, který stanoví:
(9) Pro účely výpočtu hodnoty změny nebo cenového nárůstu se původní hodnotou závazku rozumí cena sjednaná ve smlouvě na veřejnou zakázku upravená v souladu s ustanoveními o změně ceny, obsahuje-li smlouva na veřejnou zakázku taková ustanovení. Cenový nárůst související se změnami podle odstavců 5 nebo 6 při odečtení stavebních prací, služeb nebo dodávek, které nebyly s ohledem na tyto změny realizovány, nesmí přesáhnout 30 % původní hodnoty závazku; pokud bude provedeno více změn, je rozhodný součet cenových nárůstů všech změn podle odstavců 5 a 6.
Ustanovení § 222 ZZVZ se použije přiměřeně i v souvislosti s rámcovými dohodami. Zadavatel nesmí umožnit podstatnou změnu podmínek rámcové dohody po dobu jejího trvání bez provedení nového zadávacího řízení podle ZZVZ. Zadavatel nesmí umožnit podstatnou změnu podmínek uvedených v rámcové dohodě ani při zadávání veřejných zakázek na základě takové rámcové dohody. Rámcové dohody jinak samy o sobě mohou snižovat riziko vendor lock-in, a to jsou-li uzavřeny s více účastníky.
Tato kapitola se zabývá preventivními opatřeními, aby ke stavu vendor lock-in neboli proprietárního uzamčení pokud možno vůbec nedošlo. V této kapitole se dozvíte:
Předcházení stavu vendor lock-in je klíčovým aspektem pro zajištění nezávislosti a flexibility veřejné správy při zadávání ICT veřejných zakázek. Závislost zadavatele na konkrétním dodavateli významně omezuje schopnost veřejných institucí přizpůsobit se technologickým změnám, efektivně spravovat systémy a realizovat další rozvoj. Navíc pozdější řešení již vzniklého vendor lock-inu bývá zpravidla neefektivní a velmi nákladné; o to více je prevence důležitější.
Tato kapitola se zaměřuje na praktická opatření, která mohou zadavatelé zahrnout do svých zakázek, aby minimalizovaly riziko závislosti na jediném dodavateli, neboť na prevenci vendor lock-in je třeba dbát již ve fázi přípravy zadávacího řízení a podmínky veřejné zakázky je nutné nastavit tak, aby vznik tohoto nežádoucího jevu byl v maximální možné míře omezen. Mezi hlavní preventivní nástroje patří využívání otevřeného softwaru (open source), důraz na kvalitní a úplnou dokumentaci, standardizovaná technická řešení a jasně definované exit plány. Veřejná správa musí mít plnou kontrolu nad svými daty a zajistit, aby jakýkoli přechod na nového poskytovatele byl plynulý a bezproblémový.
Zdůrazňujeme také nutnost důsledného projektového řízení a dodržování právních rámců, které chrání zadavatele před situacemi, kdy by vendor lock-in mohl vést k narušení chodu veřejných služeb nebo k vysokým dodatečným nákladům. Prevence před stavem vendor lock-in je proto základním krokem k zajištění dlouhodobé efektivity a udržitelnosti ICT systémů ve veřejné správě.
Otevřený software (open source) je považován za jeden z hlavních nástrojů předcházení stavu vendor lock-in. Mezi hlavní výhody open source patří, že chrání zadavatele před závislostí na specifickém dodavateli. Rozvíjet open source totiž může kdokoliv. V podstatě jde o software, jehož zdrojový kód je veřejně dostupný (otevřený) a každý si jej může volně upravovat, používat a šířit. Pokud je zdrojový kód veřejně dostupný, mohou se s ním navíc uchazeči o veřejnou zakázku (ať už jde o jeho rozvoj či podporu) seznámit, zhodnotit své kompetence a přihlásit se do výběrového řízení. Vzniká tak skutečné konkurenční prostředí, v důsledku čehož klesá nabídková cena.
CITACE:
Otevřeným zdrojovým kódem eGovernmentu se rozumí zdrojový kód komponenty informačního systému určený pro další využití jiným orgánem veřejné správy, zkoumání kódu, rozhraní, algoritmů a postupů odbornou veřejností, přijímání návrhů na zlepšení její funkčnosti, kvality a bezpečnosti ze strany odborné veřejnosti, který je zveřejněný prostřednictvím jednotného úložiště.
(definice open source uvedená v Národním architektonickém plánu (viz https://archi.gov.cz/znalostni_baze:otevreny_zdrojovy_kod), která dále rozvádí definici otevřeného zdrojového kódu uvedenou v § 2 písm. g) vyhlášky č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy, v platném znění: „otevřeným zdrojovým kódem eGovernmentu se pro účely dané vyhlášky rozumí zdrojový kód komponenty určený pro další využití jiným orgánem veřejné správy“)
S uvedeným souvisí i § 18 odst. 2 písm. c) dané vyhlášky, který stanoví (CITACE):
Technický správce ve fázi realizace vytvoření a rozvoje informačního systému zajišťuje zveřejnění zdrojového kódu vytvořeného během projektu v rozsahu, v jakém jej nemůže být zneužito k narušení nebo zničení informačního systému.
Větší rozšíření využití open source ve veřejné správě předpokládá zavedení principu „open source jako první možnosti“. Podle tohoto principu by orgány veřejné moci měly v případě nákupu nového software vždy preferovat open source řešení. Anglickou terminologií jde o princip open source by default. Důsledné dodržování tohoto principu znamená, že veškerý software vytvářený pro veřejnou správu na míru musí být open source, pokud to jeho povaha dovoluje. Takový kód může být sdílen a opětovně používán, čímž se výrazně snižují rizika vendor lock-inu.
CITACE:
Zavedení principu „open source jako první možnost“
Pro rozšíření využití open source ve veřejné správě, a tedy i nutnou podmínkou pro realizaci jeho výhod je žádoucí zavést princip „open source jako první možnost“. Tento princip znamená, že kdykoliv se OVM rozhodují o nákupu softwaru, měly by se zamyslet, jestli k tomuto softwaru existuje alternativa v open source verzi. Pokud existuje, je třeba zvážit, zda by tato alternativa nebyla pro pokrytí požadavků dostačující, či dokonce vhodnější. Tento princip neznamená, že OVM nemohou pořizovat proprietární software. Důležité ale je, aby rozhodnutí o jeho nákupu bylo řádně odůvodněno, a to zejména při pořizování softwaru na míru nebo pro výhradní potřeby orgánu. […]
(kapitola 1.5 akčního plánu pro boj s vendor lock-inem a rozšíření využití open source ve veřejné správě)
Zavedení tohoto principu do vládních strategických dokumentů bylo úspěšné. Princip open source by default tak našel své místo v Informační koncepci České republiky. Byl do ní doplněn v roce 2022 jako tzv. další architektonický princip P19 Otevřená řešení (Open Source). Open source se týkají i Zásady ICT řízení Z16 a Z17.
Pro úplnost je nutné uvést, že pomocí základních principů eGovernmentu EU (principy P1 až P7), dalších architektonických principů (P8 až P22) a zásad řízení ICT (Z1 až Z17) by mělo docházet k naplňování všech hlavních cílů eGovernmentu a tím i Informační koncepce ČR.
CITACE:
Otevřená řešení (Open Source)
Digitální služby a komponenty informačních systémů, realizované na míru objednatele, včetně nadstaveb a rozšíření balíkového SW, musí být vytvořeny v podobě a s licencí umožňující jejich sdílení a uveřejněny ve státním úložišti otevřeného zdrojového kódu a to nejpozději v den uvolnění první verze služby do produktivního provozu.
Přístupová rozhraní (API) a knihovny využívající centrální sdílené služby musí být poskytovány v podobě komponent s otevřeným zdrojovým kódem pro nejpoužívanější jazyky a technologie.
Při návrhu architektury řešení nového nebo významně změněného ISVS musí být správcem prokazatelně posouzena možnost využití sdílených SW komponent a sdílených služeb, aktuálně dostupných ve státním úložišti otevřeného zdrojového kódu.
(architektonický princip P19 Informační koncepce ČR)
CITACE:
Využívání otevřeného software a standardů
Stát k zamezení vysokým dlouhodobým nákladům a rizikům používá otevřený software a otevřené standardy. Proto správce ISVS využije stávajících otevřených projektů nebo nechá nový zdrojový kód otevřený a znovu využitelný, publikuje ho pod příslušnými licencemi anebo pro konkrétní část kódu poskytne přesvědčivé vysvětlení, proč to nelze provést. Pokud využití otevřeného kódu není pro realizaci ISVS možné či vhodné, pak pro taková řešení postupuje podle zásady o vyváženém partnerství s dodavateli.
Při užívání otevřených řešení je zároveň nutné zohledňovat dlouhodobou udržitelnost těchto řešení, možnosti jejich rozvoje, bezpečnosti a jejich znalosti v IT i uživatelské komunitě.
(Zásada řízení ICT 16 Informační koncepce ČR)
CITACE:
Řízení architektury
Architektura jednotlivých ICT řešení musí být navržena podle byznys architektury agendy, v kontextu k architektuře celého OVS a celého eGovernmentu, jak je popsáno v Národním architektonickém plánu. Zejména musí být zohledněny sdílené služby OVS a eGovernmentu a potenciál dalšího sdílení.
Každý subjekt je povinen udržovat svůj model architektury v aktuálním stavu, úrovni detailu dle své velikosti a v konzistentním stavu s povinným obsahem stanoveným Národním architektonickým plánem, který reprezentuje společné sdílené služby a prvky architektury a zároveň v konzistentním stavu s obsahem své Informační koncepce.
(Zásada řízená ICT č. 4., Informační koncepce České republiky)
CITACE:
Podpora vyváženého partnerství s dodavateli
Správce ISVS musí zajistit, aby vždy disponoval zdrojovými kódy ISVS, detailní dokumentací a udržovanými aktuálními znalostmi k ISVS, licenčními právy k ISVS (právy k užívání autorského díla) a vlastní způsobilostí rozhodovat o ISVS tak, aby bylo možné upravovat a spravovat systém i prostřednictvím třetích osob, nezávislých na původním dodavateli či správci ISVS.
(Zásada řízení ICT 17 Informační koncepce ČR)
Ačkoli je princip otevřených řešení zmíněn přímo v Informační koncepci České republiky, tedy hlavním strategickém dokumentu týkající se eGovernmentu, v praxi zatím není tento standard uplatňován, a to navzdory tomu, že většina soukromých společností open source v různé míře běžně používá.
Kompetenční centra Digitální a informační agentury provedla v roce 2024 výzkum mezi ministerstvy zaměřený na zadávání veřejných zakázek v oblasti ICT. K tématu otevřeného software se absolutní většina resortů vyjadřovalo odmítavě či vyjadřovala značné obavy. Výtky či obavy se týkaly zejména podpory a kybernetické bezpečnosti:
V této souvislosti stojí za zmínku iniciativa Public Money, Public Code (Veřejné peníze, otevřený software), která propaguje otevřený software ve veřejných institucích.[6] Za iniciativou stojí Evropská nadace pro svobodný software (Free Software Foundation Europe), která vydala veřejně dostupnou publikaci Modernising Public Infrastructure with Free Software (Modernizace veřejné infrastruktury pomocí svobodného softwaru). Publikace se věnuje vyvracení několika mýtů o svobodném software, jako jsou tvrzení, že postrádá profesionální podporu, představuje bezpečnostní riziko nebo je nekompatibilní s proprietárním softwarem. Je zdůrazněno, že mnoho velkých společností a veřejných institucí spoléhá na svobodný software pro kritické systémy a jeho otevřená povaha zvyšuje bezpečnost díky možnosti nezávislé kontroly. Že open source (zveřejněný otevřený kód) nepředstavuje bezpečnostní riziko, spíše naopak, dokazuje i 1700 repozitářů vlády Spojeného království.
V České republice stojí za zmínku Spolek pro budování a implementaci sdílených open source nástrojů, z.s.
(www.spolekbison.cz), jehož hlavními cíli jsou:
nebo Portál otevřeného kódu code.gov.cz provozovaný Digitální a informační agenturou a spolkem Otevřená města, z.s. (zatím v pilotním provozu).
Z pohledu licence a přístupu ke zdrojovému kódu můžeme rozlišovat:
Čtyři základní svobody, které definují svobodný software a s ním spojené licence, jsou následující:
I když se svobodný software může zdát na první pohled „bezplatný“, ve skutečnosti za něj může být placeno z nejrůznějších důvodů (viz dále). Od svobodného software tedy musíme odlišovat bezplatný software (freeware), který může být distribuován a používán bez poplatků, ale uživatelům nemusí poskytovat žádné výše zmíněného svobody (ve smyslu modifikace nebo sdílení zdrojového kódu). Bezplatný software tedy může být zcela uzavřený a proprietární, což znamená, že uživatelé nemají přístup ke zdrojovému kódu, ani nemohou ovlivnit jeho fungování.
Pokud je svobodný software překládán do angličtiny jako free software, pak je nutné upozornit, že slovo free zde neznamená „zdarma“, ale odkazuje na větší svobodu při možnosti nakládání se zdrojovým kódem.
Při prodeji otevřeného software zákazníci samozřejmě obtížně akceptují poplatky za licence na software, neboť si jej mohou volně stáhnout z internetu a užívat jej. Dodavatelé otevřeného software jsou tak nuceni nabízet jiné služby v souvislosti s tímto softwarem. Platba za svobodný software je tedy spojena s poskytováním služeb souvisejících s tímto softwarem, nikoli za samotné právo používat daný software. Takové právo je totiž uživateli garantováno svobodnou licencí (viz dále). Za svobodný software se nejčastěji platí v těchto případech:
Platba za svobodný software tedy nesouvisí s užíváním samotného softwaru, které je garantováno licencí, ale za související služby, které pomáhají se správou, údržbou a přizpůsobením tohoto softwaru konkrétním potřebám zadavatele. Pokud orgán veřejné moci disponuje ICT odborníky, kteří svobodné řešení umí sami nasadit a spravovat, tak se náklady na pořízení a provoz mohou snížit až k „nule“ (pochopitelně nepočítaje v to náklady na vlastní odborníky). Pokud těmito specialisty zadavatel nedisponuje, vzniká zde potřeba vypsat veřejnou zakázku a tyto služby poptat.
Výše zmíněné základní svobody jsou garantovány licencemi, jako jsou GPL (General Public License) nebo další svobodné licence schválené Nadací pro svobodný software (https://www.fsf.org/about/) nebo Iniciativou pro Open Source (https://opensource.org/). Svobodný software nemusí být bezplatný (byť v praxi tomu tak většinou je, resp. minimálně získání softwaru jako takového), přičemž klíčová je svoboda nakládání se softwarem, nikoliv jeho cena (nebo cena jeho nezávislé podpory).
Není tedy pravda, že by svobodný software nebyl vůbec licencován. Open source je licencován, avšak oproti proprietárním řešením se licence vztahuje spíše na možnosti použití, nikoliv jako „předplatné“ artiklu. Existuje mnoho open source licencí s jinými pravidly pro používání a úpravy softwaru. Rozdíl oproti proprietárním licencím je v tom, že zákazník má vždy právo obdržet zdrojový kód softwaru, který je pod open source licencí, a kód si dle svého uvážení upravit.
Open source (otevřený, svobodný software) je obecně takový software, k němuž je dodáván i zdrojový kód (forma programu, se kterou pracuje programátor), a to pod licencí, která umožňuje jeho využívání, modifikaci a další šíření. Zpravidla se jedná o některou z řady obecných licencí, jejichž seznam vede nezisková organizace Open Source Initiative, která pro schválení licence požaduje splnění následujících kritérií (volný překlad):
1. Licence neomezuje šíření ani prodej programu, jeho částí ani z něj odvozených děl. Také nepodmiňuje jeho šíření poplatky či podílem na zisku.
2. Licence umožňuje šíření zdrojového kódu i jeho sestavených forem (například spustitelných programů). Pokud není program poskytnut včetně zdrojového kódu, musí být tento volně dostupný za cenu nepřekračující náklady na distribuci (nosič), nejlépe však bezúplatně přes internet. Zdrojový kód musí být ve formě, která bývá programátory rozvíjejícími takové programy preferována, a není dovoleno úmyslné snižování jeho čitelnosti, například dalším strojovým zpracováním.
3. Licence umožňuje úpravy a vytváření odvozených děl a neomezuje jejich šíření, pokud k němu dochází za stejných podmínek jako u původního programu.[7]
4. Licence omezuje šíření zdrojového kódu pouze v případě, že umožňuje šíření rozdílových souborů, s jejichž využitím je možné sestavit upravený program, a zároveň umožňuje šíření sestavených upravených programů. Licence může požadovat šíření změněných programů pod jiným označením, než nese původní program.
5. Licence nediskriminuje žádné osoby nebo skupiny osob.
6. Licence nebrání v užívání programu ke konkrétním účelům (například podnikání nebo výzkum genetiky).
7. Práva vyplývající z licence přísluší každému, kdo program legálně získá.
8. Práva vyplývající z licence nejsou podmíněna získáním programu jako součásti většího balíčku. Pokud je program z takového balíčku vyňat a používán či šířen, jeho uživatelé či příjemci by měli mít stejná práva jako uživatelé programu, kteří získali celý balíček.
9. Licence neomezuje další programy, které jsou šířeny zároveň s licencovaným programem. Nepožaduje například, aby i ostatní programy na datovém nosiči byly open source.
10. Licence není podmíněna konkrétní technologií nebo prostředím (například pouze pro zařízení určitého výrobce).
Takových licencí je aktuálně cca 100. Široce známá a rozšířená licence je GNU General Public License (GPL), pod kterou je např. šířeno jádro operačního systému Linux, a kterou pro využití v její aktuální verzi doporučujeme. Existuje mj. také European Union Public License (EUPL), kterou za účelem podpoření myšlenky využití open source nechala vytvořit Evropská komise a která vyšla ve formě jejího prováděcího rozhodnutí dostupného zde.
Pod touto licencí je licencován rovněž design systém gov.cz. V rámci Evropské komise působí také tzv. Open Source Programme Office (OSPO), která působí jako facilitátor aktivit týkajících se open source (https://interoperable-europe.ec.europa.eu/collection/ec-ospo).
Pokud si zadavatel nechává zhotovit nový software na zakázku a zajistí-li si od dodavatele potřebná majetková práva, může takto zhotovený software dále poskytovat pod open source licencí. Pokud se takový software prokáže jako užitečný i pro jiné subjekty, které ho také nasadí, lze předpokládat, že díky spolupráci dojde ke snížení nákladů na údržbu a rozvoj.
Pokud jde o obavy zadavatelů týkající se podpory, tak je sice pravdou, že pro open source neexistuje „tradiční“ podpora, která je typická pro proprietární software ve formě „24/7 helpdesku“, ale technickou podporu, pomoc s provozem, rozvoj i školení často dokáže nabídnout v rámci veřejné zakázky některý z dodavatelů, kteří obdobné služby dodávají v soukromém sektoru (zpravidla jde o jiné společnosti, než dodavatele „uzavřených řešení“, kteří by tím poškozovali své jiné, pro ně většinou důležitější „core“ obchodní zájmy). K nalezení možných partnerů lze bez obav využít institutu předběžných tržních konzultací. Pokud ve své organizaci zaměstnáváte schopné pracovníky, naleznou další podporu online. Díky otevřenosti mnoho projektů provozuje diskusní komunitní platformy, kde zkušenější přispěvatelé poskytují uživatelům bezplatně rady. Drtivá většina projektů řeší chyby ohlášené uživateli a přijímá vylepšení zdrojových kódů, pokud je dokáží vaši pracovníci vytvořit.
Známé a využívané open source produkty mají zpravidla několik možností a úrovní podpory.
Názor, že open source (veřejně dostupný kód) je méně bezpečný a snáze zneužitelný než kód uzavřený je podle nás spíše mýtem, než pravdou. Právě proto, že ke kódu má přístup široké spektrum uživatelů a odborníků (v porovnání s kódem proprietárním), je šance na objevení zranitelnosti větší, což může vést ve svém důsledku k lépe zabezpečenému produktu, než je proprietární software. Pokud je zdrojový kód programu veřejně dostupný, je možné odměňovat nezávislé bezpečnostní výzkumníky – tzv. etické hackery (“bug bounty huntery“) za nalezené bezpečnostní chyby a dramaticky tak zvýšit bezpečnost informačních systémů veřejné správy.
Již zmíněná brožura Modernising Public Infrastructure with Free Software od Evropské nadace pro svobodný software uvádí několik úspěšných iniciativ svobodného softwaru v různých zemích. Příklady zahrnují platformu Decidim ve Španělsku pro participativní demokracii nebo platformu Oskari ve Finsku pro vizualizaci prostorových dat. Tyto projekty ukazují, jak lze svobodná softwarová řešení sdílet a přizpůsobovat potřebám různých veřejných správ a zároveň tím i výrazně šetřit a naplňovat principy 3E, neboť pořizovací i provozní náklady na proprietární software rostou (a v případě vendor lock-in jsou většinou ještě vyšší, než by byly jinak normálně).
Dalším příkladem je dánské město Aarhus, které se rozhodlo pro open-source řešení, čímž si zajistilo větší flexibilitu a kontrolu nad svými ICT systémy a jejich daty.
Zajímavé pak je, jak se k problematice poskytování zdrojových kódu staví ostatní státy. Např. Lotyšsko již v roce 1995 zavedlo povinnost poskytnout zdrojové kódy pro všechny ICT veřejné zakázky.[8] Obdobným směrem se v roce 2016 vydalo i Bulharsko.[9]
Francouzské město Toulouse platilo za kancelářský software firmě Microsoft každé tři roky 1,8 milionu EUR. Na základě strategického rozhodnutí začalo v roce 2012 využívat open source software LibreOffice, který je zároveň zcela zdarma. Vzhledem k tomu, že migrace mezi řešeními stála 0,8 milionu eur, již samotným pořízením open source řešení vznikla městu úspora 1 milionu EUR za první tři roky.
V rámci zadávání veřejných zakázek se lze s open source setkat v rámci různých scénářů:
| Identifikace a specifikace potřeby a investičního záměru |
§ 16vyhlášky č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy Věcný správce ve fázi strategického plánování vytvoření a rozvoje informačního systému a) identifikuje motivace k vytvoření nebo rozvoji informačního systému, porovná je se stávajícím stavem architektury orgánu veřejné správy a prostřednictvím aktualizace informační koncepce orgánu veřejné správy provede strategické naplánování vytvoření nebo rozvoje tohoto systému, b) v návaznosti na plán v informační koncepci orgánu veřejné správy vypracuje a schválí investiční záměr a v případě určeného informačního systému obdrží souhlasné vyjádření Digitální a informační agentury a c) stanoví cíle, kterých chce dosáhnout vytvořením nebo rozvojem informačního systému nebo se odkáže na platné strategické cíle orgánu veřejné správy nebo cíle České republiky, jejichž splnění bude podpořeno plánovaným informačním systémem.
|
| Příprava veřejné zakázky |
Parametry soutěženého informačního systému by měly být popsány nediskriminačním způsobem, tj. tak aby se veřejné soutěže mohli účastnit i dodavatelé open source aplikací. Při přípravě smlouvy s budoucím vítězným dodavatelem doporučujeme dbát na zajištění možnosti vlastního přístupu k vlastní datové základně mimo služby dodavatele, včetně smluvního ošetření i hypotetické možnosti budoucího vývoje systému třetí stranou a definice exit strategie pro případ možného budoucího „rozchodu“ s vybraným dodavatelem informačního systému. Vzorové právní formulace nabízíme v dalších částech této kapitoly 3. |
| Vyhodnocení nabídek | V rámci přípravy zadávacích podmínek doporučujeme důsledně dbát na správné nastavení hodnotících kritérií, kdy se nabízí použít hodnotící kritérium v podobě hodnocení podle nejnižších nákladů životního cyklu a to tak, aby byly zohledněny skutečně celkové náklady spojené s daným software a jeho provozem - včetně nákladů na nezbytnou související hardwarovou a softwarovou výbavu, servisní a případně i rozvojové práce nebo exit strategii při ukončení spolupráce (tzv. “TCO - Total Costs of Ownership“, viz jinak i příloha k vyhlášce č. 360/2023 Sb. o dlouhodobém řízení informačních systémů veřejné správy, obsahující popis metody celkových nákladů na vlastnictví informačního systému a naše karta hodnocení nabídek na základě nejnižších nákladů životního cyklu). |
Pro předcházení právních příčin vendor lock-in je nezbytné správně nastavit licenční ujednání, a to zejména, nejde-li o software a tím i licenci typu open source. Licencí se obecně rozumí oprávnění určitým způsobem nakládat s předmětem, který podléhá autorskému právu nebo jinému duševnímu vlastnictví (v našem případě s počítačovým programem). Licence dovoluje předmět autorského práva užívat, ale i měnit, zapracovávat do jiných systémů apod. Pojmem licence je označována také vlastní licenční smlouva, tedy ujednání, na jehož základě poskytovatel, který má práva z duševního vlastnictví, uděluje uživateli oprávnění tato práva využívat. Rozsah, v jakém je toto využívání možné, plyne z licenčního ujednání, popř. z příslušných zákonů.
V oblasti dodávek softwaru je důležité věnovat zvláštní pozornost licenčním ujednáním, která se řídí autorským zákonem. Tento typ smlouvy je klíčový pro zajištění práv a povinností jak poskytovatele, tak uživatele softwaru. Správně formulovaná licenční ujednání mohou předcházet sporům, stavu vendor lock-in a zajistit hladkou spolupráci mezi oběma stranami.
|
Doporučená licenční ujednání
|
Obecně naopak nevýhodná ujednání ve smlouvách na ICT produkty (nad rámec licence) lze nalézt i na webu Architektury eGovermentu ČR (z nichž vycházíme původně i v rámci našeho výše uvedeného doporučení).
CITACE:
Technologické projekty mají větší šanci uspět, pokud „netechnické“ profese dohlížející na jejich průběh a rozpočet rozumí šesti základním principům moderního vývoje softwaru, kterými jsou: design zaměřený na uživatele, agilní vývoj softwaru, DevOps, modulární architektura, modulární zakázky a vlastnictví produktu. Jde o obecné principy, jejichž pochopení nevyžaduje technické vzdělání. Ale jakmile je jednou ovládnete, dostanete se skrz vatu a technický žargon na jádro úspěšného řízení softwarových projektů.
(Průvodce světem řízení státních IT projektů, Digitální Česko)
Dokumentace hraje v prevenci vendor lock-in v rámci ICT veřejných zakázek zásadní roli, neboť je kritickým nástrojem pro minimalizaci závislosti na konkrétním dodavateli a naopak maximalizace úspěšnosti migrace dat na nového dodavatele; musí být vždy přístupná, kompletní, aktuální a musí obsahovat informace o architektuře systému, rozhraních API, struktuře dat a zdrojových kódech; ve smlouvách by měly být specifikovány jasné požadavky na poskytování dokumentace v každé fázi vývoje, aby byla vždy k dispozici zadavateli a jeho případným nástupcům; je nutné také zajistit kvalifikované převzetí dokumentace a proces její akceptace.
API (Application Programming Interface/rozhraní pro programování aplikací) jsou důležitým prvkem, který umožňuje výměnu dat a funkcionalit mezi různými systémy a aplikacemi. Dobře navržené a zdokumentované API usnadňuje integraci, rozšiřitelnost a přechod na nové systémy. API tedy slouží jako prostředek k propojení starého a nového systému a umožňuje snadný přenos dat. Zároveň umožňuje, aby nový dodavatel integroval svůj software do stávajícího prostředí.
API může být volně dostupné nebo chráněné licenčními poplatky či dohodou o mlčenlivosti (NDA), a to jako součást většího softwarového celku nebo jako samostatný produkt. Z hlediska vendor lock-in platí pro API to samé jako pro ostatní software.
V rámci ICT zakázek je důležité rozlišit několik druhů dokumentace, které si zaslouží podrobnější pozornost a měly by být součástí smluvních podmínek:
Technická dokumentace informačního systému je určena odborníkům (architektům, administrátorům, vývojářům). Slouží technickým týmům, které systém implementují, nastavují, integrují a provozně udržují. Dokumentace má být důkladná a jednoznačně strukturovaná tak, aby pokrývala všechny podstatné aspekty řešení a usnadňovala jeho vývoj, provoz i další rozvoj. Obsahuje podrobné informace o architektuře softwarového řešení, o technických specifikacích, rozhraních API, datových konektorech, databázích, síťových konfiguracích a dalších technických aspektech systému.
a) dokumentace o architektuře systému by měla obsahovat:
b) technická specifikace by měla obsahovat:
c) dokumentace o rozhraních API a datových konektorů pro přenos dat mezi systémy by měla obsahovat:
d) Informace o struktuře dat by měla obsahovat:
Kvalitní technická dokumentace umožňuje zadavatelům efektivně migrovat na nové systémy (včetně migrace dat) a minimalizovat rizika. Výsledkem je zvýšená flexibilita, konkurenceschopnost a dlouhodobá nezávislost na jednom dodavateli. Zadavatel musí rozumět tomu, co po dodavatelích požaduje, a musí hrát aktivní roli partnera dodavatele. V případě, že bude role zadavatele pasivní a nastavení zadávacích podmínek vágní, bude zcela logicky iniciativa na straně dodavatele, protože v opačném případě, kdy se zadavatel zbaví odpovědnosti a tuto bude klást na bedra dodavatele, je otázkou času, kdy se vytvoří nějaké podmínky pro vznik technického vendor lock-in.
Některé konkrétní příklady standardizovaných technologií, které mohou pomoci předcházet vendor lock-in:
Otevřené standardy pro datové formáty:
XML (Extensible Markup Language) – Používá se pro strukturování a přenos dat. Je široce akceptován a umožňuje snadný export a import dat mezi různými systémy.
Krátká formulace do zadání: „Dodavatel zajistí export a import dat ve formátu XML; XSD schémata budou součástí dodávky.“
JSON (JavaScript Object Notation) – Lehký textový formát pro výměnu dat, běžný u API. Široká podpora u moderních aplikací → snadné napojení/migrace.
„Rozhraní bude přijímat a vracet data ve formátu JSON.“
API (Application Programming Interfaces)
REST – Architektura pro vytváření webových služeb, která umožňuje snadné propojení mezi různými systémy a aplikacemi. Má širokou podporu klientů i serverů.
Krátká formulace do zadání: „Rozhraní bude RESTful přes HTTPS (GET/POST/PUT/DELETE).“
SOAP (Simple Object Access Protocol) – Další standard pro výměnu informací (pomocí XML zpráv), který podporuje interoperabilitu mezi různými platformami.
Krátká formulace do zadání: „Pokud bude použito SOAP, tak verze 1.2 s využitím struktury WSDL 1.1.“
GraphQL – Moderní alternativa k REST. Umožňuje klientům dotazovat se na přesně ta data, která potřebují, což může být efektivnější, pokud chcete získat více různých informací v jedné žádosti. Snižuje závislost na konkrétních „endpointech“.
Krátká formulace do zadání: „Volitelně podpora GraphQL; schéma (SDL) bude součástí dodávky.“
SDK (Software Development Kit) – Není API ve smyslu komunikace mezi aplikacemi, ale spíše soubor nástrojů a knihoven, které programátorům umožňují snadněji pracovat s určitými API nebo vytvářet aplikace.
Mikroslužby – V architektuře mikroslužeb se aplikace skládá z menších, nezávislých služeb, které komunikují pomocí API. Každá služba může mít své vlastní API, které je určeno pro konkrétní funkčnost.
Otevřené protokoly:
HTTP/HTTPS – Základní protokoly pro přenos dat na webu, které jsou široce podporovány. Univerzální kompatibilita, žádné proprietární kanály.
Krátká formulace do zadání: „Veškerá komunikace probíhá přes HTTPS (TLS 1.3+).“
IPv6 – Novější internetový protokol s velkým adresním prostorem. Zajišťuje dlouhodobou interoperabilitu; je požadován ve veřejné správě.
Krátká formulace do zadání: „Provoz musí plně podporovat IPv6 (v souladu s usnesením vlády č. 49/2024).“
DNSSEC - Kryptografické podepisování DNS záznamů.
Krátká formulace do zadání: „Domény budou podepsány DNSSEC (s pravidelnou obnovou klíčů).“
CITACE:
II. Vláda ukládá 1. členům vlády a vedoucím ostatních ústředních orgánů státní správy, kteří dosud nezajistili plnění usnesení vlády ze dne 18. prosince 2013 č. 982, ke Zprávě o zavádění technologie DNSSEC a o plnění usnesení vlády ze dne 8. června 2009 č. 727, ke Zprávě o přechodu na internetový protokol verze 6 (IPv6), napravit tento stav nejpozději do 31. prosince 2024,
2. členům vlády a vedoucím ostatních ústředních orgánů státní správy přestat poskytovat služby státní správy na protokolu IPv4 od 6. června 2032.
(Usnesení Vlády ČR ze dne 17. ledna 2024 č. 49 k restartu zavádění technologie DNSSEC a protokolu IPv6 ve státní správě)
Příklad možného ujednání do smluvní dokumentace:
1. Povinnost předání technické dokumentace
Poskytovatel se zavazuje předat klientovi úplnou technickou dokumentaci, která zahrnuje zejména:
Komentář:
Je třeba vzít v potaz, že v rovině informačních systémů veřejné správy je technická dokumentace součástí dokumentace provozní, a proto se tímto dovolujeme odkázat primárně na náš vzor smluvního ujednání týkající se provozní dokumentace, který lze dále rozšířit o další požadavky stran technické stránky, např. i dle tohoto našeho vzoru týkajícího se technické dokumentace.
2. Aktualizace technické dokumentace
Technická dokumentace musí být aktualizována po každé úpravě, která ovlivňuje systémové procesy, architekturu, rozhraní nebo závislosti nebo při jakéhokoli jiné podstatné změně řešení, které dokumentuje. Aktualizace musí zahrnovat jasně označené změny oproti předchozím verzím.
Komentář:
Ev. aktualizována při jakékoli změně tech. řešení
3. Přístup pro třetí strany
Technická dokumentace musí být strukturovaná tak, aby ji bylo možné bez problémů předat / umožni k ní přístup třetím stranám. Poskytovatel se zavazuje, že nebude používat vlastní (proprietární) formáty nebo terminologii, které by třetím stranám bránily v porozumění nebo přístupu.
4. Formát předání
Dokumentace musí být poskytována v otevřených standardech (např. HTML, Markdown, PDF, SVG) a klient je oprávněn předat dokumentaci / umožnit k ní přístup třetím stranám (udělit jim příslušnou podlicenci). Dokumentace bude v českém jazyce; technické artefakty v angličtině jsou přípustné, je-li součástí český průvodce.
Dokumentace musí být zároveň umístěna v klientem určeném repozitáři se vzdáleným přístupem v oddělených adresářích, verzována a propojena s releasy (tagy). Součástí bude vždy changelog a release notes ke každému vydání.
Webová forma dokumentace nebo dokumentace ve formě mobilní aplikace musí vždy splňovat požadavky zákona č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací, v platném znění.
5. Lhůta pro předání
Poskytovatel se zavazuje předat technickou dokumentaci klientovi nejpozději spolu s předáním díla (implementovaného software), resp. nejpozději ke dni nasazení výše uvedených změn, kterých se technická dokumentace týká, do produkčního prostředí.
Uživatelská dokumentace je zaměřena na koncové uživatele systému. Obsahuje návod, jak používat software či produkt, popis funkcí a možností, které software poskytuje, postupy a řešení častých problémů. Primárně slouží uživatelům, kteří potřebují znát praktické kroky k efektivnímu použití systému. Součástí jsou zpravidla i návody pro administrátory systému. Uživatelská dokumentace může být dodána pro offline distribuci a / nebo integrována do www rozhraní informačního systému.
Příklad možného ujednání do smluvní dokumentace:
1. Povinnost předání uživatelské dokumentace
Zhotovitel je povinen Objednateli dodat kompletní a aktuální uživatelskou dokumentaci, která bude přístupná a srozumitelná pro koncové uživatele systému (občany, úředníky, pracovníky Objednatele). Dokumentace musí zahrnovat:
2. Aktualizace uživatelské dokumentace
Zhotovitel se zavazuje k aktualizaci uživatelské dokumentace při každé významné změně systému, která ovlivňuje uživatelské rozhraní nebo způsob používání. Dokumentace takových změn musí být aktualizována nejpozději ke dni nasazení takových změn do produkčního prostředí. Dokumentace jiných než takových změn uživatelského prostředí, musí být aktualizována nejpozději do 15 dnů ode dne takové změny.
3. Způsob předání uživatelské dokumentace
Dokumentace musí být poskytnuta ve formátech umožňujících snadnou distribuci koncovým uživatelům, například ve formátu PDF nebo webové podobě přístupné z prohlížeče či video podobě, aby uživatelé nemuseli instalovat žádný specifický software. Dokumentace musí být zároveň umístěna v Objednatelem určeném repozitáři se vzdáleným přístupem v oddělených adresářích, verzována a propojena s releasy (tagy). Součástí bude vždy changelog a release notes ke každému vydání. Webová forma dokumentace nebo dokumentace ve formě mobilní aplikace musí vždy splňovat požadavky zákona č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací, v platném znění. Dokumentace bude v českém jazyce; technické artefakty v angličtině jsou přípustné, je-li součástí český průvodce
5. Lhůta pro předání
Zhotovitel se zavazuje předat uživatelskou dokumentaci Objednateli nejpozději spolu s předáním díla (implementovaného software), resp. nejpozději ke dni nasazení každé významné změny systému, která ovlivňuje uživatelské rozhraní nebo způsob používání, do produkčního prostředí, jinak vždy nejpozději do 15 dnů od jakékoli jiné než takové změny uživatelského prostředí.
6. Předání třetím osobám
Objednatel je oprávněn předat dokumentaci / umožnit k ní přístup třetím osobám (udělit jim příslušnou podlicenci).
CITACE:
Uživatelská přívětivost (User-friendliness) Musí být kladen důraz na uživatelskou přívětivost zaváděných digitálních služeb veřejné správy pro různé skupiny uživatelů. Služby musí být na prvním místě srozumitelné, uzpůsobené rozdílným požadavkům různých cílových skupin uživatelů v populaci. Služby mají být z hlediska uživatelského rozhraní otevřené, nesmí se omezovat na proprietární rozhraní nebo jediný standard a předjímat jediný způsob využití.
(architektonický princip P15 Informační koncepce ČR)
Slouží pro účely správy a údržby systému, zahrnuje postupy pro instalaci, zálohování, aktualizace a monitorování systému, obsahuje tedy veškerou dokumentaci (včetně bezpečnostních parametrů) ke vzniku a provozu informačního systému veřejné správy. Jedná se o dokumentaci softwaru, jeho vnitřní struktury, modulů a datových toků, jde o dokumentaci softwaru z věcného a procesního hlediska, na rozdíl od dokumentace zdrojového kódu.
Při zpracování provozní dokumentace je třeba v případě informačních systémů veřejné správy reflektovat právní úpravu zpracování provozní dokumentace podle zákona č. 365/2000 Sb., o informačních systémech veřejné správy, v platném znění, a prováděcí vyhlášky č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy.
Výše uvedený zákon ve svém ustanovení § 5a odst. 1 ukládá Radě vlády pro informační společnost vytvořit a předložit vládě ke schválení tzv. informační koncepci České republiky. Informační koncepce České republiky stanoví cíle České republiky v oblasti informačních systémů veřejné správy a obecné principy pořizování, architektonických změn, vytváření, správy, provozování, užívání a rozvoje informačních systémů veřejné správy v České republice na období 5 let.
V souladu s odst. 2 daného §5a orgány veřejné správy vytvářejí a vydávají informační koncepci orgánu veřejné správy, uplatňují ji v praxi a vyhodnocují její dodržování. V informační koncepci orgánu veřejné správy orgány veřejné správy stanoví své dlouhodobé cíle v oblasti řízení spravovaných informačních systémů veřejné správy a vymezí obecné principy pořizování, architektonických změn, vytváření, správy, provozování, užívání a rozvoje svých informačních systémů veřejné správy.
Na základě vydané informační koncepce orgánu veřejné správy orgány veřejné správy pak vytvářejí a vydávají provozní dokumentaci k jednotlivým informačním systémům veřejné správy, uplatňují ji v praxi a vyhodnocují její dodržování.
Strukturu a náležitosti provozní dokumentace stanoví prováděcí právní předpis, konkrétně výše uvedená vyhláška č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy. Tato vyhláška rovněž stanoví rozsah provozní dokumentace předkládané při tzv. atestaci, kterou orgány veřejné správy prokazují splnění povinností vyplývajících pro ně při plnění povinností vyplývajících ze zákona o informačních systémech veřejné správy.
Provozní dokumentaci je pak věnována celá Hlava III vyhlášky, kdy v § 11 je vymezena struktura provozní dokumentace následujícím způsobem:
Provozní dokumentaci každé etapy životního cyklu informačního systému tvoří sady dokumentací:
a) plánování vytvoření a rozvoje informačního systému,
b) zadání a smluv pro vytvoření a rozvoj informačního systému,
c) stavu informačního systému při uvedení do produkčního provozu po jeho vytvoření nebo rozvoji,
d) plánu a zajišťování provozu,
e) změn informačního systému a
f) hodnocení informačního systému, včetně hodnocení ekonomické výhodnosti.
Nutno upřesnit, že provozní dokumentace se zabývá každým informačním systémem zvlášť, není možné mít jednu provozní dokumentaci pro celý orgán veřejné správy. Nicméně platí, že orgán veřejné správy může zpracovat jednu provozní dokumentaci pro více informačních systémů, a to za předpokladu, že postupy pro vytvoření, správu, provoz, užívání a rozvoj těchto informačních systémů jsou shodné, nebo v příslušné fázi životního cyklu společné. V takovém případě orgán veřejné správy uvede do provozní dokumentace informaci o tom, pro které informační systémy je provozní dokumentace společná.
Až na výjimky zveřejňuje orgán veřejné správy výše uvedené sady dokumentací způsobem umožňujícím dálkový přístup.
Správce informačního systému zařadí dokumenty provozní dokumentace do typového spisu a jako identifikátor typového spisu použije přidělený identifikátor informačního systému. Typový spis se člení na součásti typového spisu, které jsou tvořeny sadami dokumentací podle výše provedeného dělení. Součásti typového spisu jsou členěny na díly, do kterých jsou vkládány spisy provozní dokumentace za stanovené časové období; po uplynutí tohoto období se díly uzavírají. Je-li zpracována jedna provozní dokumentace pro více informačních systémů, zakládá se do typového spisu pouze jednou, ve spisech ostatních informačních systémů je uveden odkaz na typový spis, ve kterém je založena.
Náležitosti provozní dokumentace jsou určeny v § 12 odst. 1 vyhlášky č. 360/2023 Sb.:
Provozní dokumentace obsahuje:
a) charakteristiku informačního systému,
b) popis architektury informačního systému,
c) podrobný popis informačního systému,
d) bezpečnostní dokumentaci,
e) provozní řád – jeho obsah viz níže.
f) postupy a procesy související s provozem informačního systému,
g) protokoly související s provozem informačního systému a
h) smluvní a licenční dokumentaci.
Charakteristika informačního systému obsahuje alespoň:
a) odkaz na záznam v rejstříku informačních systémů veřejné správy a soukromoprávních systémů pro využívání údajů, v němž jsou údaje o informačním systému vedeny,
b) vlivy působící na informační systém a z nich plynoucí předpokládané změny a cíle informačního systému,
c) přehled dekomponování informačního systému na komponenty s uvedením vyhodnocené bezpečnostní úrovně informačního systému a jeho jednotlivých komponent a
d) přehled ukazatelů hodnocení ekonomické výhodnosti provozu a způsobu provozu informačního systému.
Popis architektury informačního systému obsahuje alespoň dokumentaci na úrovni podrobnosti metody architektury úřadu a metody architektury řešení.
Podrobný popis informačního systému obsahuje alespoň:
a) požadavky kladené na informační systém při jeho vytvoření nebo rozvoji,
b) výčet komponent a sdílených prvků technologické a komunikační infrastruktury, které jsou nutné pro provoz informačního systému,
c) popis programových rozhraní,
d) popis připravovaných a realizovaných změn informačního systému,
e) výčet komponent informačního systému, jejich vzájemných vazeb a vazeb na jiné informační systémy,
f) přehled dostupných funkcí a poskytovaných služeb informačního systému,
g) přehled evidovaných údajů a jejich strukturu,
h) přehled zjištěných závad a provedených oprav informačního systému a
i) dobu plánované životnosti informačního systému.
Orgán veřejné správy, kterému nejsou uloženy povinnosti v oblasti kybernetické bezpečnosti podle zákona upravujícího kybernetickou bezpečnost, stanovuje v bezpečnostní dokumentaci alespoň postupy pro:
a) hodnocení dopadů narušení dostupnosti, důvěrnosti a integrity informací v informačním systému,
b) způsob řešení a reakce na bezpečnostní události a bezpečnostní incidenty, sběr a vyhodnocování kybernetických bezpečnostních událostí a incidentů,
c) zajištění provozu informačních systémů a bezpečnosti informací v informačních systémech,
d) rozvoj bezpečnostního povědomí a způsob jeho kontroly,
e) zajištění bezpečnosti komunikační sítě a
f) zajištění řízení kontinuity činností.
Provozní řád obsahuje alespoň:
a) provozní dobu informačního systému,
b) parametry poskytovaných služeb informačního systému,
c) informace o uživatelské podpoře,
d) pravidla pro odstávky informačního systému,
e) pravidla pro zamezení neúměrného provozního zatížení a nesprávného používání informačního systému nebo jeho služeb a
f) podmínky pro připojení ke službám informačního systému.
Rozsah provozní dokumentace předkládané při atestaci
Při atestaci předkládá orgán veřejné správy provozní dokumentaci v rozsahu náležitostí podle § 12 odst. 1 písm. a) až h) – viz výše.
Příklad možného ujednání do smluvní dokumentace:
1. Povinnost předání provozní dokumentace
Poskytovatel se zavazuje předat klientovi úplnou provozní dokumentaci ve struktuře a náležitostech dle vyhlášky č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy.
2. Aktualizace provozní dokumentace
Provozní dokumentace musí být aktualizována při každé změně skutečností, které jsou jejím podkladem. Aktualizace musí zahrnovat jasně označené změny oproti předchozím verzím.
3. Formát předání
Dokumentace musí být poskytována v otevřených standardech (např. PDF, SVG, HTML) a klient je oprávněn předat dokumentaci / umožnit k ní přístup třetím stranám (udělit jim příslušnou podlicenci). Dokumentace bude zároveň spravována ve webovém repozitáři společně se zdrojovým kódem (v oddělených adresářích), verzována a propojena s releasy (tagy). Součástí je changelog a release notes ke každému vydání. Dokumentace ve formě webových stránek nebo mobilní aplikace musí vždy splňovat požadavky zákona č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací, v platném znění.
Dokumentace bude v českém jazyce; technické artefakty v angličtině jsou přípustné, je-li součástí český průvodce.
4. Lhůta pro aktualizaci a předání
Poskytovatel se zavazuje aktualizovat a předat provozní dokumentaci klientovi nejpozději spolu s předáním díla (implementovaného software), resp. vždy nejpozději ke dni nasazení změn řešení, kterých se provozní dokumentace týká, do produkčního prostředí.
Pokud je součástí smlouvy dodání zdrojového kódu, musí být specifikováno, že dokumentace zdrojového kódu obsahuje komentáře a vysvětlení logiky softwarového řešení; je nutné se zabývat nejen kvalitou samotných komentářů, ale rovněž kvalitou samotného kódu a využívání určitých standardů a best practices pro psaní kódu;
Zdrojový kód by měl být strukturovaný, přehledný a obsahovat jasné vysvětlení jednotlivých částí. Slouží primárně vývojářům, kteří budou pracovat na údržbě a rozvoji systému. Zdrojový kód programu je speciálně konstruován tak, aby usnadnil činnost programátorů, kteří specifikují úkoly, které má počítač vykonávat, většinou prostřednictvím zápisu tohoto kódu. Důsledná dokumentace kódu zlepšuje čitelnost, usnadňuje spolupráci a pomáhá odhalovat chyby.
Zdrojový kód také poskytuje možnost otevřeného vývoje. Komunita programátorů tak může spolupracovat na vylepšování a sdílení zdrojového kódu. Dodržování pravidel a zásad umožňuje tvorbu snadno udržovatelného a udržitelného kódu.
DEFINICE: Zdrojový kód je základní prvek softwaru, představující sadu instrukcí, které definují chování programu. Je psán v programovacích jazycích, jako jsou C++, Java, Python nebo HTML, a umožňuje programátorům vytvářet, upravovat a optimalizovat software. Celkově je zdrojový kód klíčovým prvkem, který určuje funkčnost softwaru, a jeho správná správa a dokumentace jsou nezbytné pro úspěšný vývoj.
Příklady zásad a doporučení při vytváření a komentování zdrojového kódu:
Dodržování jednotného programátorského stylu a příručky, jak psát daný kód (Code Style Guides, např. Google Style Guides). Využívat standardních nástrojů zaměřených na jednotlivá informační odvětví, ať už aplikace, webové portály, informační systémy atd. Nástroje pro dokumentaci kódu jsou dostupné na oficiálních webech.
Ukázka syntaxe a pravidel tvorby komentářů:
Příklad
/// <summary>
/// třída pro práci s objektem Osoba
/// </summary>
public class Person
{
/// <summary>
/// jméno Osoby
/// </summary>
protected string _name;
/// <summary>
/// konstruktor Osoby
/// </summary>
/// <param name="name">jméno Osoby</param>
public Person( string name )
{
// přiřazení jména Osobě
_name = name;
}
/// <summary>
/// metoda pro nastavení nového jména Osoby a navrácení jména původního
/// </summary>
/// <param name="newName">nové jmeno Osoby</param>
/// <returns>původní jméno Osoby</returns>
public string setName( string newName )
{
/*
* nejprve je vytvořena místní proměnná pro uchování původního jména Osoby,
* pak je aktualizováno jméno Osoby v instanční proměnné
* jako návratová hodnota metody je vráceno původní jméno osoby
*/
string oldName; // proměnná pro uchování původního jména Osoby
// aktualizace jména Osoby a předání původního jména Osoby jako návratové hodnoty metody
oldName = _name;
return oldName;
}
}
DEFINICE: CODE REVIEW (kontrola kódu) je proces, při kterém vývojáři přezkoumávají a hodnotí kód napsaný jiným vývojářem. Cílem tohoto procesu je zlepšit kvalitu kódu, odhalit chyby a zranitelnosti, zajistit dodržování standardů a sdílet znalosti mezi členy týmu.
Typy zdrojových kódů, které se liší podle způsobu použití, licencování a způsobu správy.:
Proprietární zdrojový kód, Open source zdrojový kód, Zdrojový kód ve veřejném vlastnictví (Public Domain), Sdílený zdrojový kód (Shared Source), Kód s uzavřeným zdrojem (Closed Source), Kód s omezeným přístupem (Restricted Access)
|
Příklad zdrojový kód otevřený vs. proprietární: Rozdíl mezi otevřeným (open source) a proprietárním (uzavřeným) kódem spočívá hlavně v přístupu a podmínkách jeho používání. Otevřený kód je dostupný a podporuje komunitní spolupráci, zatímco proprietární kód je uzavřený a kontrolovaný jednou organizací. |
|
|
Otevřený kód (Open Source):
|
Proprietární kód (Uzavřený kód):
|
Otevřený zdrojový kód eGovernmentu: zdrojový kód informačního systému, který je dostupný pro další využití veřejnými orgány. Umožňuje odborné veřejnosti zkoumat kód, rozhraní a algoritmy, navrhovat zlepšení funkčnosti, kvality a bezpečnosti. Kód je zveřejněn v jednotném úložišti code.gov.cz.[10]
Více o otevřeném zdrojovém kódu eGovermentu naleznete v bezpečnostním doporučení pro vývoj otevřeného softwaru od NÚKIB a Ministerstva vnitra.
Příklad možného ujednání do smluvní dokumentace ve věci poskytnutí zdrojového kódu:
Zhotovitel se zavazuje společně s předáním Informačního systému předat Objednateli zdrojový kód k Informačnímu systému včetně veškeré související dokumentace, a to tak, že zdrojové kódy a dokumentace budou uloženy v Objednatelem určeném repozitáři se vzdáleným přístupem a zároveň budou Objednateli předány na datovém nosiči, bude-li tak požadovat, nebo předány do úschovy třetí osoby, na které se smluvní strany dohodnou včetně podmínek takové úschovy - tzv. escrow) s tím, že:
i. předaný kód musí být vytvořen podle nejnovějších a nejlepších standardů v oboru (tzv. best-practice), zejm. bude v přehledné a strukturované podobě; tj. musí být čitelný a komentovaný včetně všech potřebných náležitostí, které umožňují jeho pochopení a úpravy bez nezbytné účasti Zhotovitele, a to bez zadržování jakékoli části, která by Objednatele omezovala v rozvoji nebo údržbě Informačního systému třetí osobou. Zhotovitel se zavazuje, že žádné části kódu nebudou proprietární, tj. že Objednatel nebude závislý na nástrojích nebo postupech dostupných pouze Zhotoviteli;
ii. v repozitáři bude dokumentace v odděleném adresáři, verzována a propojena s releasy (tagy). Součástí bude vždy changelog a release notes ke každému vydání.
Dokumentace zdrojového kódu musí zahrnovat:
iii. Zhotovitel se zavazuje poskytnout zdrojový kód v otevřeném formátu, který umožňuje plný přístup ke všem souborům. Dokumentace zdrojového kódu musí být uložena v textovém formátu kompatibilním s běžnými nástroji pro vývoj (např. Markdown, README soubory);
iv. Zhotovitel se zavazuje specifikovat Objednateli, které běžně dostupné nástroje byly použity pro editaci a kompilaci zdrojového kódu, v jaké verzi a konfiguraci a tyto informace předat písemně Objednateli;
v. Zhotovitel se zavazuje aktualizovat dokumentaci zdrojového kódu současně se změnami zdrojového kódu, aby tyto změny reflektovala, a takto aktualizovanou ji bezodkladně předat vždy výše uvedeným způsobem (způsoby) Objednateli, a to nejpozději ke dni nasazení změn do produkčního prostředí.
Ve smlouvách by měly být specifikovány jasné požadavky na poskytování dokumentace v každé fázi vývoje, aby byla vždy k dispozici zadavateli a jeho případným nástupcům.
Implementace těchto kroků a požadavků pomůže minimalizovat riziko vendor lock-in a pro efektivní správu ICT veřejných zakázek. Zajistí, že dokumentace bude efektivně podporovat nezávislost na konkrétním dodavateli.
V předchozích kapitolách jsme si uvedli, že vendor lock-in je taková situace, kdy je zadavatel (objednatel, kupující) řešení zcela závislý na službách (produktech – počítačových programech, výrobcích, řešení, či obecně díle) konkrétního dodavatele (poskytovatele, prodávajícího). Je to právě z důvodu toho, že potencionální přechod zadavatele na jiné služby (produkty, výrobky, řešení, dílo) jiných potencionálních dodavatelů je pro takového zadavatele technicky či právně nemožný, či představuje značný náklad.
Do stavu podřízenosti k dodavateli se zadavatel může dostat předně nedostatečně propracovanou, či zcela absentující exit strategií ve smlouvě.
Vytvoření exit (výstupní) strategie je nezbytné pro:
Exit (výstupní) strategie by měla být zahrnuta již do zadávací dokumentace a smluvních podmínek. Vytvoření exit strategie se dá zařadit pod „front-end“ aktivitu. Důvody, kdy se hodí mít naplánovanou exit strategii mohou být různé. Jedná se zejména o situace, kdy původní dodavatel ukončuje poskytovanou službu nebo se na trhu s ICT technologiemi objevil nový dodavatel, který poskytuje lepší řešení, a je tedy potřeba nebo je vhodné vše zmigrovat.
Při přípravě exit strategie je třeba vzít v úvahu několik aspektů, zejména:
Pokud je zadavatel v situaci vendor lock-in z důvodu toho, že se exit strategie ve smlouvě neřešily vůbec, či nedostatečně, tak základem bude si důkladně projít uzavřenou smlouvu a zanalyzovat si, kde jsou zadavatelova slabá či naopak silná místa vůči dodavateli.
Dále pak bude nutné získané výsledky analýzy vykomunikovat s dodavatelem a pokusit se s ním najít řešení výhodné pro obě strany. Pokud si je ale dodavatel vědom svého silnějšího postavení, často není ochoten k nějaké dohodě přistoupit, nebo si diktuje pro zadavatele nepříznivé cenové podmínky. Proto je důležité pamatovat na exit strategie již při tvorbě zadávací dokumentace v rámci zadávání veřejné zakázky a nastavit si ve smlouvě takové parametry, aby k vendor lock-in vůbec nedocházelo.
Obecné požadavky na exit strategie mohou být stanoveny i ve formě vnitřního předpisu – metodického dokumentu zadavatele.
Když byla definována zadavatelem exitová strategie, je dále potřeba do smlouvy zanést i závazek původního dodavatele vypracovat na základě pokynu zadavatele tzv. exit plán, jenž vymezuje veškeré podmínky (ve shodě s nastavenou exit strategií) pro převedení dalšího vývoje, provozu a podpory či jiného relevantního plnění na nového dodavatele (popř. i samotného zadavatele) a poskytnout plnění nezbytná k realizaci exit plánu. Exit plán je tedy praktickou součástí nebo spíše vyústěním exit strategie, která je vtělena přímo do těla smlouvy.
Exit plán je zásadním krokem při ukončení spolupráce s dodavatelem a přechodu na nového poskytovatele (či samotného zadavatele). Tento plán by měl zejména obsahovat:
Příklad ustanovení o závazku dodavatele vypracovat exit plán a poskytovat související součinnost:
Dodavatel se zavazuje dle pokynů Objednatele poskytnout veškerou potřebnou součinnost, dokumentaci a informace a účastnit se jednání s Objednatelem a třetími osobami za účelem plynulého a řádného převedení poskytování předmětu plnění či jejich příslušné části nebo podobného či souvisejícího plnění na nového Dodavatele nebo samotného Objednatele, ke kterému dojde nebo má dojít po skončení účinnosti této Smlouvy nebo v případě předčasného ukončení smlouvy (dále jen „Exit“). Za tímto účelem se Dodavatel zavazuje vypracovat na základě pokynu Objednatele exit plán vymezující veškeré podmínky pro převedení dalšího vývoje, provozu a podpory či jiného relevantního plnění na nového Dodavatele, ev. i samotného Objednatele (dále jen „Exit plán“) a poskytnout plnění nezbytná k realizaci tohoto Exit plánu. Dodavatel se zavazuje součinnost dle tohoto odstavce a Exit plánu poskytovat s odbornou péčí, zodpovědně a do doby úplného převzetí a inicializace poskytování služeb novým Dodavatelem (případně samotným Objednatelem).
Závazek dle tohoto ustanovení platí i po uplynutí doby trvání Smlouvy, a to nejméně 1 rok po jejím ukončení z jakéhokoli důvodu. Objednatel je oprávněn požádat o vypracování Exit plánu dle tohoto odstavce Smlouvy kdykoli během trvání této Smlouvy ve lhůtě jednoho kalendářního roku před datem jejího očekávaného řádného ukončení nebo kdykoli po odstoupení Objednatele od Smlouvy (nebo spolu s ním) nebo kdykoli po odstoupení Dodavatele od Smlouvy. Dodavatel se zavazuje vypracovat Exit plán dle tohoto odstavce Smlouvy a poskytnout plnění nezbytná k jeho realizaci do 1 měsíce od doručení takového požadavku Objednatele, nestanoví-li Objednatel jinak. Strany se dohodly, že cena za vypracování Exit plánu dle tohoto odstavce Smlouvy a poskytnutí plnění nezbytného k jeho realizaci je součástí Ceny za Servisní služby dle odst. XXX Smlouvy, přičemž Dodavateli nenáleží nárok na jakékoliv další finanční plnění dle Smlouvy.
Doporučující ustanovení ve smlouvě pro exit strategii a exit plán
Exit plán tak může být zavázán smluvně vypracovat dodavatel, nebo musí být už (spolu s exit strategií) přímo součástí smlouvy (resp. jejího závazného návrhu).
Exit strategie mají tedy sloužit výlučně zadavateli k co možná nejsnazšímu přechodu od původního dodavatele veřejné zakázky k novému dodavateli, případně k sobě samému, pokud například další provoz a vývoj systému zvládne vlastními kapacitami. Jedná se o „teoretický plán“, kterému se sice musí na začátku věnovat čas, úsilí a energie, ale benefity jeho stanovení ocení zadavatel hned při prvním řešení problémů, jenž vyvstanou při případném přechodu k novému dodavateli (nebo k sobě samému). Samotný exit plán, resp. jeho realizace musí být také naplánována tak, aby zadavatel měl dostatečný časový prostor vysoutěžit nového dodavatele a zároveň mu provoz nebo vývoj/další rozvoj informačního systému prostřednictvím stávajícího dodavatele – provozovatele předat, případně, aby v rámci rámcových dohod mohla být další dílčí zakázka předána včas dalšímu dodavateli v určené rotaci (při systému bez obnovení soutěže mezi účastníky rámcové dohody).
Dále je nutné upozornit, že exit strategie se netýká pouze single vendor infrastruktury. Pokud zadavatelovy procesy běží v multicloudu, u každé aktivity, které běží u jiného poskytovatele, je nutné podmínky odchodu nastavit zvlášť.
|
Na základě výše uvedeného doporučujeme zadavatelům, aby součástí každé smlouvy na veřejnou zakázku byla i precizní ujednání týkající se exit strategie a exit plánu, zejm.:
Dále doporučujeme:
|
Použití standardizovaných a modulárních technických řešení je jednou z nejúčinnějších metod, jak zabránit vendor lock-in; standardizovaná řešení umožňují lepší interoperabilitu mezi systémy a snižují závislost na jednom poskytovateli; modulární architektura zase usnadňuje rozšíření a modifikace systému bez nutnosti zásahu do celé infrastruktury; ve smlouvách by mělo být specifikováno, že všechny části systému budou navrženy s využitím standardizovaných rozhraní, tzv. API (Application Programming Interface), která zajišťují, že jednotlivé komponenty systému mohou komunikovat a fungovat s jinými systémy bez ohledu na dodavatele; tato rozhraní (např. REST API, SOAP API) umožňují snadnou komunikaci mezi jednotlivými systémy a usnadňují přechod na nové poskytovatele služeb.
Životní cyklus informačních systémů veřejné správy (ISVS), ale i tzv. provozních informačních systémů hraje klíčovou roli v prevenci vendor lock-in. Informační systémy by měly být pravidelně vyhodnocovány a modernizovány, aby odpovídaly aktuálním technologickým standardům a potřebám veřejného sektoru. Dlouhodobé používání zastaralých systémů může vést k jejich nekompatibilitě s novějšími řešeními, což zvyšuje závislost na původním dodavateli, proto se doporučuje nastavit jasné pravidlo pro pravidelnou revizi a aktualizaci informačních systémů, včetně stanovení maximálního časového období, po kterém by měl být systém modernizován nebo nahrazen. Tento přístup napomáhá větší flexibilitě zadavatele a možnosti integrace nových technologií, což současně napomáhá i minimalizaci rizika vendor lock-in.
Zkušenosti mnoha zemí ukazují, že pokud nebudou informační systémy neustále přepracovávány, náklady na jejich správu prudce porostou a vzniklý systém tzv. „špagetové architektury“ (“spaghetti architecture”) nebude možné rozplést. Veřejné služby musí být v souladu s novými technickými možnostmi a odpovídat běžným požadavkům na kvalitu. Např. v Estonsku je zaveden tzv. princip „no legacy principle“, tj. že ve veřejném sektoru by žádný informační a komunikační systém neměl být starší více než 13 let[11].
Životním cyklem informačního systému rozumíme všechna za sebou jdoucí období, přičemž pro každé období je stanoven určitý cíl a k jeho dosažení jsou v tomto období nasměrovány veškeré činnosti (od vzniku potřeby po zánik, nebo celkovou rekonstrukci systému). V rovině ZZVZ se životním cyklem rozumí obecně: všechny po sobě jdoucí nebo provázané fáze, zahrnující výzkum a vývoj, pokud mají být provedeny, výrobu, obchod a jeho podmínky, přepravu, užívání a údržbu, po celou dobu existence předmětu dodávky nebo stavby nebo poskytování služby, od získání surovin nebo vytvoření zdrojů po odstranění, likvidaci a ukončení služby nebo používání
Vedle zákona č. 365/2000 Sb., o informačních systémech veřejné správy je zásadním předpisem pro řízení informačních a komunikačních technologií vyhláška č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy. Podle § 15 této vyhlášky fázemi životního cyklu informačního systému jsou:
a) STRATEGIE (strategické plánování vytvoření a rozvoje informačního systému) - fáze životního cyklu informačního systému č. 1
V této fázi životního cyklu ISVS hovoříme o identifikaci, iniciaci a koncepci projektu. Je naplánována budoucí existence projektu a projekt je nahrubo definován a koncipován. Jsou stanoveny jeho cíle a základní podmínky.
Konkrétně věcný správce v této fázi:
a) identifikuje motivace k vytvoření nebo rozvoji informačního systému, porovná je se stávajícím stavem architektury orgánu veřejné správy a prostřednictvím aktualizace informační koncepce orgánu veřejné správy provede strategické naplánování vytvoření nebo rozvoje tohoto systému,
b) v návaznosti na plán v informační koncepci orgánu veřejné správy vypracuje a schválí investiční záměr a v případě určeného informačního systému obdrží souhlasné vyjádření Digitální a informační agentury a
c) stanoví cíle, kterých chce dosáhnout vytvořením nebo rozvojem informačního systému nebo se odkáže na platné strategické cíle orgánu veřejné správy nebo cíle České republiky, jejichž splnění bude podpořeno plánovaným informačním systémem.
b) PLÁNOVÁNÍ A PŘÍPRAVA (plánování a příprava vytvoření a rozvoje informačního systému) - fáze životního cyklu informačního systému č. 2.
Po schválení a zahájení projektu přichází na řadu jeho plánování a příprava, včetně ustavení projektových struktur a jeho materiálního a personálního zajištění. V této fázi se také vytváří plán ukončení provozu informačního systému, tedy v podstatě zmiňovaná exit strategie, a zajišťuje se vypracování studie proveditelnosti k posouzení možných variant nebo zjištění podmínek pro realizovatelnost nových nebo významně měněných informačních systémů.
c) REALIZACE PROJEKTU (realizace vytvoření a rozvoje informačního systému) - fáze životního cyklu informačního systému č. 3
Společně s dodavatelem jsou stanoveny společné projektové struktury, cílový koncept řešení a dodávka (vývoj, implementace) řešení v míře odpovídající zvolenému způsobu realizace (vodopád, agilní, kombinace, …), včetně testování a přípravy produktivního provozu. V rámci této fáze technický správce mj. zajišťuje zveřejnění zdrojového kódu vytvořeného během projektu v rozsahu, v jakém jej nemůže být zneužito k narušení nebo zničení informačního systému.
d) PRODUKČNÍ PROVOZ informačního systému - fáze životního cyklu informačního systému č. 4
Tato fáze zahrnuje přípravu včetně školení, migraci dat, okamžik zahájení užívání a počáteční rozšířenou podporu dodavatele a pak také samozřejmě celý produkční provoz informačního systému včetně mj. pravidelného zálohování a uchovávání dat bez přerušení provozu informačního systému a pravidelných testů obnovy všech funkcí, kódů a dat informačního systému do nového prostředí.
e) VYHODNOCENÍ PROVOZU A SLUŽEB (vyhodnocení životního cyklu informačního systému) – fáze životního cyklu informačního systému č. 5
V této fázi dochází k závěrečnému vyhodnocení výstupů, tj. je vyhodnocováno plnění stanovených požadavků na služby informačního systému, přínosy služeb informačního systému včetně jejich ekonomické výhodnosti, plnění cílů stanovených ve fázi strategického plánování vytvoření a rozvoje informačního systému a zajištění bezpečnosti informačního systému (aplikují se bezodkladně potřebná bezpečnostní opatření).
f) UKONČENÍ ICT SLUŽBY (ukončení životního cyklu informačního systému) – fáze životního cyklu informačního systému č. 6
V této fázi dochází k ukončení života systému a jeho případná náhrada jiným systémem je strategickým rozhodnutím, které musí být podpořeno architektonickými a ekonomickými podklady a musí být dlouhodobě připravováno v Informační koncepci orgánu veřejné správy. Součástí ukončení služby je plnění exit plánu dohodnutého s dodavatelem či provozovatelem.
Ve všech fázích projektu a zejména pak při jeho strategickém plánování, přípravě, realizaci a produkčním provozu je nezbytné provádět průběžné plánování, monitoring a řízení projektu.
Překrývání etap životního cyklu: Každý životní cyklus informačního systému veřejné správy se skládá z jednotlivých etap. Jednotlivé etapy životního cyklu jednoho ISVS se mohou vzájemně překrývat s fázovým posunem. Tedy současně jsou některé služby ISVS rutinně provozovány, některé služby z dřívějších etap již jsou utlumovány a likvidovány a nové služby z další etapy rozvoje systému jsou plánovány nebo realizovány.
Překrývání fází jedné etapy: Stejně tak fáze jedné etapy se ve svých činnostech mohou překrývat či předbíhat. Například ještě nejsou provedeny všechny činnosti uzavření realizačního projektu a finální předání řešení do produktivního provozu, přesto již jsou služby jako výstupy projektu produktivně užívány.
Přístup popsaný výše a zejména pak postup v souladu s vyhláškou č. 360/2023 Sb. zajistí, že zadavatel bude mít flexibilitu a možnost integrace nových technologií, což minimalizuje riziko vendor lock-in. Podrobně je řízení informačních systémů podle etap a fází jejich životního cyklu popsáno také v rámci Architektury eGovermentu ČR.
Definice informačního systému dle zákona č. 365/2000 Sb., o informačních systémech veřejné správy:
Funkční celek nebo jeho část zabezpečující cílevědomou a systematickou informační činnost pro účely výkonu veřejné správy nebo plnění jiných funkcí státu anebo dalších veřejnoprávních korporací. Každý ISVS zahrnuje data, která jsou uspořádána tak, aby bylo možné jejich zpracování a zpřístupnění, provozní údaje a dále technické a programové prostředky, případně jiné nástroje umožňující výkon informačních činností.
Řízeným vývojem by se mělo předcházet stavům, které lze při vývoji software označit jako nežádoucí. Vedle neefektivity a prodražování vývoje či nízké kvality a problémům s následnou údržbou produktu, je to právě i stav vendor lock-in.Vědecká disciplína, která se touto činností zabývá, se nazývá softwarové inženýrství, což je nejobecnější pojem, který pro tuto činnost máme k dispozici. Zastřešuje jak programování jako takové (výroba), tak všechny činnosti, které mu předcházejí, včetně činností, které následují po předání produktu k užívání (viz norma IEEE 610.12-1990).
Obecně platí, že projektový manažer by měl mít jasně definovanou roli a odpovědnosti, které zahrnují sledování plnění všech smluvních podmínek, zejména v oblasti dokumentace, otevřených rozhraní a exit plánů.
Základním termínem v softwarovém inženýrství je projekt, ve smyslu koordinovaného a řízeného procesu vývoje softwaru.
DEFINICE
| Projekt je jedinečný proces, sestávající z řady koordinovaných a řízených činností se stanovenými termíny zahájení a ukončení, prováděný pro dosažení předem stanoveného cíle, který vyhovuje specifickým požadavkům včetně omezení daných časem, náklady a zdroji za současného řízení rizik (viz norma ISO 10 006:2017). |
|---|
Přestože řízený vývoj softwaru může využívat některých technik projektového řízení, projektové řízení není jedinou procesní metodikou (přístupem) k realizaci softwarového projektu.
Totiž, obecně je projekt charakteristický tzv. projektovým trojimperativem, který udává rovnoměrnou souvislost mezi cílem projektu, vyměřeným časem k jeho realizaci a alokovanými zdroji (tzv. trojrozměrný cíl zobrazovaný rovnoramenným trojúhelníkem).
Obr. 1[
Při vývoji softwaru se však může stát, že jeden z cílů významně převyšuje ostatní. Je to dáno tím, že někdy může být kladen větší důraz na inovativnost řešení, a potom je do jisté míry potlačeno hledisko nákladů či času.
Obr. 2
K softwarovým projektům tak můžeme přistupovat buď prediktivně (lineárně, tradičně), pokud vše pečlivě plánujeme a předpokládáme rovnovážný poměr mezi výsledkem a zdroji. Potom můžeme využít některý z normovaných standardů projektového řízení (např. project management podle standardů IPMA, PRINCE2 či PMI). Avšak stále častěji se při vývoji software prosazuje inovativní, tzv. agilní řízení (agile management), které se vyznačuje iterativní a inkrementální povahou vývoje produktu. V softwarovém inženýrství je agilní přístup reprezentovaný např. metodikou Scrum (česky by se mohlo říci „skrumáž“ nebo „mlýn“).
Každý z těchto přístupů má svá pro a proti, které předurčují vhodnost jejich použití. Je tak vysoce pravděpodobné, že při zadávání veřejné zakázky na vývoj softwaru se nejčastěji prosadí hybridní model z níže uvedených.
Vývoj od shora dolů (vodopád)
Při vývoji software tzv. od shora dolů postupujeme najednou, po jednotlivých předem naplánovaných fázích vývoje (ve smyslu až dokončím jeden krok, přejdu na následující). Je tedy jasné, že musíme mít dopředu téměř dokonalou představu výsledného produktu a této představy se držet po celou dobu jeho realizace, a to i ve fázi plánování, ale zejména při zadávání zakázky. Jak již bylo řečeno, jedná se o tradiční přístup, podle kterého se vyvíjejí a soutěží téměř všechny zakázky na informační systémy ve veřejném sektoru.
Výhody vodopádu plynou z faktu, že se v současné době jedná v praxi o nejužívanější přístup k vývoji software, se kterým mají zadavatelé, dodavatelé i úřední autority zkušenost. Hlavní výhody jsou dány z přesné specifikace zadání, které se např. projevuje jednodušším řízením rizik. Jako nevýhody lze označit obtížnou implementaci změn zadání (rigiditu),obecně dražší vývoj, resp. následný rozvoj a právě vyšší tendenci ke vzniku stavu vendor lock-in.
Iterativní vývoj
Využití čistě iterativního vývoje spočívá v opakování téhož procesu v jiném kontextu (fázi projektu). Lze tak navrhnout zadání a schválit zadání, navrhnout první prototyp a schválit první prototyp atd. Samostatně se tento přístup při vývoji softwaru neuplatňuje.
Inkrementální vývoj
Inkrementální neboli postupný vývoj znamená rozdělení projektu na několik menších, které se dokončují samostatně. Stejně jako s iterací, tak se s inkrementálním přístupem setkáme v kombinaci při agilním řízení.
Agilní vývoj
Agilní metodika předpokládá postupnou (inkrementální) konvergenci založenou na neustálém opakování (iteraci) vývojového cyklu: dílčí úkol (sprint) – zpětná vazba – korekce. Na počátku projektu tak není nutné (a není to ani žádoucí) znát detailně celý výsledný produkt. Celkem pochopitelně se agilní řízení při vývoji softwaru ve veřejné správě zatím příliš neuplatňují, protože těmito přístupy nelze garantovat jediný milník daného projektu a riziko ohrožení vývoje či jeho financování je tedy vyšší. Na druhé straně nejsou nutné na počátku velké kapitálové výdaje (CAPEX) a tento systém také umožňuje předvídatelné průběžné vynakládání výdajů o stejné výši (kupuje se předem stanovený čas – „člověkodny/hodiny vývojářského týmu a ne finální produkt).
Hybridní vývoj
Některé fáze vývoje jsou agilní, na některé může být aplikován vývoj od shora dolů.
Pro potřeby posouzení vhodnosti obou přístupů lze využít rozhodovací matici.
| Spíše tradiční přístupy řízení vývoje | Spíše agilní přístupy řízení vývoje | |
| Cíl projektu | Výsledkem je existující produkt | Výsledkem je inovace |
| Výsledkem je celek | Dílčí výsledky (hodnoty v podobě konkrétní a zdokumentované nové funkcionality), které zadavatel průběžně dostává | |
| Orientace na splnění zadání | Orientace na přínos (zadáním je pouze nějaký základní „backlog“, tedy seznam uživatelských potřeb, případně nějaký obecněji definovaný cíl). | |
| Orientace na krátkodobý užitek | Orientace na hodnoty | |
| Zdroje a čas | Rovnováha mezi výsledkem a zdroji | Nejdůležitější je výsledek |
| Důraz na cenu | Důraz na výsledek a hodnoty | |
| Požadavky na dodavatele | Tým motivovaný penězi | Tým motivovaný prací samotnou |
| Vyšší riziko vendor lock-in | Možnost předcházet vendor lock-in | |
| Standardní požadavky na dodavatele | Vyšší požadavky na kompetence dodavatele | |
| Řízení rizik | Změna jako riziko | Změna jako příležitost |
| Změna je akce po skončení vývoje | Změna je součástí vývoje (proto i údržba i rozvoj jsou v podstatě jen běžnou vývojovou prací). | |
| Snaha o absolutní kontrolu rizik | Možnost chybovat | |
| Stabilita prostředí | Dynamika prostředí | |
| Integrace do stávající architektury / systémového prostředí | Na konci vývoje | Průběžně |
|
Pro nastavení podmínek projektů řízených agilně doporučujeme: Definování základních cílů: klást důraz na hlavní cíle projektu, nikoli na přesné specifikace každé jednotlivé funkčnosti. Správné nastavení kritérií kvalifikace a hodnocení nabídek: požadujte / bonifikujte v rámci hodnocení nabídek zkušenosti účastníků s agilně řízenými projekty a porovnávejte hodnotu nabídnutých plnění. Pravidelné hodnocení a zpětná vazba: poskytněte prostor pro pravidelné hodnocení každé fáze projektu a zadávání dalších úkolů na základě dosažených výsledků.
|
Zároveň doporučujeme, aby si zadavatel pokud možno ponechal odborné (nejen) projektové kapacity i na své straně a vše kolem ICT jen neoutsourcoval, minimálně v rozsahu, aby byl pro dodavatele „důstojným odborným partnerem do diskuze“ a byl schopen jeho plnění kontrolovat a věděl, co od něj vůbec požadovat.
DŮLEŽITÉ_
Snažte se zjistit, jestli lidé zodpovědní za vedení a rozpočet projektu mají odpovídající technické zkušenosti. S výjimkou těch úplně nejmenších úřadů má prakticky každý někoho technicky orientovaného, kdo může vedení projektu doplnit – ačkoliv naopak prakticky nikdo k tomuto účelu nezaměstnává přímo softwarové vývojáře.
(Průvodce světem řízení státních IT projektů, Digitální Česko, str. 26-27)
V rámci zadávání veřejných zakázek v oblasti ICT je mnohdy ze strany zadavatele vysoce podceňovanou otázkou vymezení „vlastnictví“, resp. práv k datům a přístupu k nim. Podcenění této problematiky však může vést k problémům při změně dodavatele nebo při rozšiřování existujícího řešení veřejné zakázky. Vlastnictví dat, resp. lépe řečeno zajištění přístupu k nim jsou tak zásadními prvky v prevenci vendor lock-in. Z hlediska právní teorie neexistuje vlastnictví dat nebo absolutní vlastnické právo k datům, které by působilo vůči všem, tzn. i vůči dodavateli, ale toto právo je relativní povahy, které vzniká teprve na základě určité právní skutečnosti, tzn. je třeba ho založit smluvně, anebo ev. může vzniknout i ze zákona (viz níže citovaný §9e zákona č. 365/2000 Sb. o informačních systémech veřejné správy).
Veřejní zadavatelé musí mít zajištěnu plnou kontrolu nad svými daty, aby mohli předejít situacím, kdy dodavatel omezuje přístup k datům nebo podmiňuje jejich vydání. Jasně stanovená práva a možnosti ohledně správy a využívání svých dat jsou pro veřejné zadavatele klíčové.
Smluvní podmínky by měly explicitně uvádět, kdo je vlastníkem dat, jaká práva má zadavatel ve vztahu k těmto datům, jakým způsobem budou data uchovávána a kdo k nim má přístup během trvání smlouvy i po jejím ukončení. Zadavatel musí mít v každé fázi projektu zajištěný nepřetržitý dálkový nebo minimálně promptní přístup k datům na vyžádání a právo si je tak kdykoli od jejich „faktického držitele“ (dodavatele a / nebo provozovatele) vyžádat, exportovat a migrovat na jiné systémy nebo dodavatele (nebo samotného zadavatele) a doporučujeme tak i bez ohledu na skutečnost, že zákon č. 365/2000 Sb. o informačních systémech veřejné správy poskytuje zadavateli, je – li v pozici správce informačního systému (což je obvyklý scénář), trochu „berličku“ v § 9e (pro případ, že jeho provozováním pověří třetí osobu – provozovatele):
CITACE:
§ 9e
(1)
Provozovatel informačního systému veřejné správy předá bezodkladně na vyžádání správce informačního systému veřejné správy data a provozní údaje týkající se provozovaného informačního systému veřejné správy.
(2)
Provozovatel informačního systému veřejné správy předá bezodkladně po ukončení provozování informačního systému veřejné správy data a provozní údaje týkající se provozovaného informačního systému veřejné správy správci informačního systému veřejné správy a kopie těchto dat a provozních údajů zlikviduje.
(3)
Provozovatel informačního systému veřejné správy postupuje při likvidaci kopií dat a provozních údajů týkajících se provozovaného informačního systému veřejné správy podle pravidel stanovených právním předpisem upravujícím kybernetickou bezpečnost pro likvidaci dat, provozních údajů, informací a jejich kopií správci a provozovateli významného informačního systému. Provozovatel informačního systému veřejné správy umožní správci informačního systému veřejné správy dohled nad průběhem likvidace kopií dat a provozních údajů, nevylučuje-li to způsob provozování informačního systému veřejné správy.
(4) Provozovatel informačního systému veřejné správy má právo na úhradu účelně vynaložených nákladů za předání dat a provozních údajů podle odstavců 1 a 2.
(5) Ustanovení právního předpisu upravujícího práva k duševnímu vlastnictví nejsou předáním dat a provozních údajů podle odstavců 1 a 2 dotčena.
Provozovatelem informačního systému veřejné správy přitom daný zákon rozumí osobu nebo její součást, která zajišťuje funkčnost technických a programových prostředků tvořících informační systém veřejné správy (provozováním informačního systému veřejné správy může správce pověřit jiné osoby nebo jejich součásti, pokud to jiný zákon nevylučuje). Správcem informačního systému veřejné správy se přitom dle daného zákona rozumí osoba nebo její součást, která poskytuje služby informačního systému veřejné správy a za informační systém veřejné správy odpovídá.
Obdobné formulace obsahoval ve svém § 6a i dnes už neplatný zákon č. 181/2014 Sb., o kybernetické bezpečnosti, který dále upravoval pro případy hrozícího kybernetického bezpečnostního incidentu i (možné) autoritativní rozhodnutí Národního úřadu pro kybernetickou a informační bezpečnost (NÚKIB) o povinnosti předat správci data, provozní údaje a informace, nicméně pouze co do informačního systému kritické informační infrastruktury, komunikačního systému kritické informační infrastruktury nebo tzv. významného informačního systému, za který tento zákon považoval informační systém spravovaný orgánem veřejné moci, který není kritickou informační infrastrukturou ani informačním systémem základní služby a u kterého narušení bezpečnosti informací může omezit nebo výrazně ohrozit výkon působnosti orgánu veřejné moci, tedy de facto zákonem svěřených agend.
Tento zákon byl však účinný pouze do 31. 10. 2025, kdy od 1.11. 2025 jej nahradil nový zákon č. 264/2025 Sb., o kybernetické bezpečnosti. Ten k této problematice přistupuje jiným způsobem, když přímo neobsahuje obdobu § 6a dosavadního zákona o kybernetické bezpečnosti (a tedy ani obdobu výše citovaného § 9e zákona č. 365/2000 Sb. o informačních systémech veřejné správy), o povinnosti předat data správci a obsahuje ve svém § 24 jen obdobu § 15a starého zákona o kybernetické bezpečnosti v souvislosti s rozhodnutím NÚKIB (nově s možností NÚKIB nařídit vydání dat komukoliv, kdo jimi disponuje).
CITACE:
§ 24
Speciální úprava předání informací a dat od dodavatele
(1)
Úřad může v případě hrozícího nebo probíhajícího kybernetického bezpečnostního incidentu, který by mohl mít závažný vliv na poskytování regulované služby s dopadem na zachování bezpečnosti České republiky, vnitřního pořádku, života a zdraví, majetkových hodnot nebo životního prostředí, na podnět poskytovatele regulované služby v režimu vyšších povinností, který marně vyzval svého dodavatele k předání informací a dat, uložit tomuto dodavateli povinnost předat poskytovateli regulované služby informace a data související s provozem aktiv sloužících k poskytování regulované služby. Pokud tento dodavatel informacemi nebo daty souvisejícími s provozem aktiv sloužících k poskytování regulované služby nedisponuje nebo vzhledem ke skutkovým okolnostem není účelné jejich opatření a vydání po něm požadovat, může Úřad povinnost podle věty první uložit každému, kdo požadovanými informacemi a daty disponuje. Úřad může v rozhodnutí podle vět první a druhé určit formát, rozsah, způsob a lhůtu předání těchto informací a dat a stanovit povinnost po jejich předání tyto informace a data a všechny jejich kopie bezpečně zlikvidovat.
(2)
Podnět podle odstavce 1 musí obsahovat odůvodnění požadavku s ohledem na hrozící nebo probíhající kybernetický bezpečnostní incident, podrobný popis předchozího jednání mezi dodavatelem a poskytovatelem regulované služby a možné následky, pokud nedojde k předání požadovaných informací a dat.
(3)
Rozhodnutí podle odstavce 1 může být prvním úkonem v řízení. Rozklad proti rozhodnutí podle věty první nemá odkladný účinek.
(4)
Dodavatel nebo ten, kdo požadovanými informacemi a daty disponuje, má nárok na úhradu účelně vynaložených nákladů spojených s předáním informací a dat ze strany poskytovatele regulované služby. Jednání o úhradě účelně vynaložených nákladů spojených s předáním informací a dat nesmí být překážkou řádného splnění povinnosti předat informace a data.
Tento nový zákon o kybernetické bezpečnosti se svou prováděcí vyhláškou č. 409/2025 Sb., o bezpečnostních opatřeních poskytovatele regulované služby v režimu vyšších povinností, stanoví v souvislosti s řízením rizik a dodavatelů pro poskytovatele regulované služby v režimu vyšších povinností, mezi které spadají mj. i ústřední orgány státní správy a jiné správní úřady s celostátní působností v rámci výkonu svěřených pravomocí – veřejné správy, povinné náležitosti pro smluvní vztahy s tzv. významnými dodavateli.
Mezi tyto požadavky (aplikováno v relevantním rozsahu) spadá mj. specifikace podmínek pro formát předání dat a informací po vyžádání povinnou osobou (tedy poskytovatelem regulované služby), pravidla pro likvidaci dat, oprávnění užívat data, nebo specifikace podmínek z pohledu bezpečnosti při ukončení smlouvy, tzv. exit strategie, nebo nově i specifikace náležitosti smlouvy o úrovni služeb (SLA) a způsobu a úrovni realizace bezpečnostních opatření nebo ustanovení o dodržování pravidel bezpečného vývoje (nově jsou řešeny i žádosti cizozemských orgánů o zpřístupnění nebo předání dat (v tomto rozsahu jsou tyto regulatorní požadavky na smlouvy s významnými dodavateli širší než dle přílohy č. 7 předchozí a dnes už tedy neplatné vyhlášky č. 82/2018 Sb., o kybernetické bezpečnosti). Ke smluvním požadavkům, byť ještě v souvislosti s předchozí právní úpravou, viz jinak i materiál NÚKIB (materiál se týká i přístupu k datům). Významným dodavatelem dle nově platné regulace se přitom rozumí (obdobně jako v té dosavadní) dodavatel, který poskytovateli regulované služby poskytuje plnění, které je významné z hlediska zajištění kybernetické bezpečnosti regulované služby.
Obecně lze nicméně doporučit proaktivní přístup ze strany správců informačních systémů a mít náležitě smluvně ošetřena rizika, bezpečnost dat a přístup k nim, a to ve vztahu ke všem dodavatelům informačních systémů (technických aktiv), tj. ve vztahu i k těm, kteří nejsou považováni za významné dodavatele.
Důležité je zajistit pravidelné zálohování dat a specifikovat formáty, ve kterých budou data poskytována, aby byla zajištěna jejich přenositelnost a kompatibilita s jinými systémy.
Nutné je také zohlednit právní úpravu ochrany osobních údajů, pokud mají data takovou povahu.
S ohledem na výše uvedené je proto důležité, aby veřejní zadavatelé měli jasně stanovená práva a možnosti v oblasti svých dat, což obecně zahrnuje:
Definice dat: Smlouva s dodavatelem by v první řadě měla přesně definovat, co se rozumí pod pojmem "data". Tato definice může zahrnovat strukturovaná i nestrukturovaná data, metadata, záložní kopie a všechny ostatní formy dat, které jsou během projektu vytvořeny nebo zpracovány. Dále se může jednat o data primární (například data uživatelů) nebo o data sekundární, která vznikají jejich zpracováním.
Práva na přístup k datům a jejich použití: Bez ohledu na okolnosti musí mít zadavatel zajištěn nepřetržitý přístup ke svým datům v průběhu celého projektu i po jeho ukončení, včetně práva na export a migraci dat na jiné platformy, tedy mít smluvně zajištěnou plnou kontrolu nad daty. Jakékoli omezení přístupu k datům může vytvářet závislost na konkrétním dodavateli a komplikovat přechod na jiné alternativní řešení. Dále by měl mít zadavatel k dispozici dostatečné nástroje pro čtení dat, jejich export a manipulaci. Smlouva s dodavatelem by měla rovněž uvádět, že dodavatel nesmí bez předchozího výslovného souhlasu zadavatele data využívat, analyzovat ani sdílet s třetími stranami, a to ani anonymizovaná nebo agregovaná data. Smlouvy by měly obsahovat klauzule o podmínkách přístupu k datům a případných sankcích za nedodržení závazků ze strany dodavatele.
Odpovědnost za bezpečnost, integritu a dostupnost dat: Smlouva s dodavatelem by měla specifikovat, že dodavatel nese odpovědnost za zabezpečení (ochranu), integritu a dostupnost dat během trvání zakázky. Dodavatel by měl zajistit, aby nedocházelo ke ztrátě, poškození nebo neoprávněnému přístupu k datům, a měl by mít zavedeny adekvátní bezpečnostní postupy a technologie.
Omezení použití dat dodavatelem: S použitím dat zadavatelem souvisí i použití dat dodavatelem. Smlouva by měla zahrnovat ustanovení, která zakazují dodavateli používat data pro jakékoli jiné účely než pro poskytování smluvně dohodnutých služeb. To by mělo zahrnovat omezení analýzy dat, vytváření statistik nebo poskytování dat třetím stranám.
Pravidla pro kopírování a zálohování dat: I takové podrobnosti jako jsou pravidla pro kopírování a zálohování dat by měly být ve smlouvě s dodavatelem upraveny. Zadavatel by měl mít jasný přehled o tom, jakým způsobem dodavatel provádí případné zálohování a kopírování dat. Zadavatel by měl mít zajištěn plný přístup k záložním kopiím dat, případně možnost získat je ve bezodkladně ve vhodném formátu. Vše se závazkem dodavatele veškeré případné zbylé kopie zlikvidovat.
Migrace dat: Smlouva s dodavatelem by měla obsahovat podmínky pro bezproblémovou a bezpečnou migraci dat včetně zajištění jejich integrity. Dodavatel by měl být smluvně zavázán k tomu, že na požádání zadavatele provede export dat do vhodného formátu a poskytne technickou podporu, aby zadavatel mohl snadno přenést data k jinému dodavateli. Takové ustanovení minimalizuje riziko, že by dodavatel mohl data držet jako „rukojmí“ po skončení smlouvy. Ve smlouvě by měly být zahrnuty sankce nebo kompenzační opatření, která by se uplatnila v případě, že dodavatel nesplní své povinnosti v oblasti migrace dat.
Zálohování a formáty dat: Je důležité zavést pravidelné zálohy a stanovit formáty dat, které zajistí jejich kompatibilitu s různými systémy, čímž se usnadní přenositelnost. Dodavatelé by měli být povinni využívat otevřené a standardizované formáty dat. Používání proprietárních formátů, které vyžadují specifické technologie nebo nástroje dodavatele, může způsobit značné problémy při přechodu na jiné řešení nebo při integraci s jinými systémy. Zajistit standardní formáty zvyšuje kompatibilitu a snižuje riziko uzamčení zadavatele do jednoho řešení.
Transparentnost a audit zacházení s daty: Ve smlouvě s dodavatelem by mělo být zakotveno právo zadavatele provádět audity, které zajistí, že s jeho daty je nakládáno v souladu s ujednanými podmínkami. Dodavatel by měl spolupracovat a poskytovat veškeré potřebné informace, tzn. měla by být smluvně zajištěna povinnost jeho součinnosti, aby bylo možné ověřit plnění smlouvy, a zajistit, že s daty je nakládáno v souladu se smlouvou a právními předpisy.
Zpracování dat a ochrana osobních údajů: Dodavatel by měl být zavázán plnit veškeré povinnosti týkající se ochrany osobních údajů v souladu s právními předpisy (zejm. GDPR) s tím, že pokud dodavatel bude zpracovávat osobní údaje ve smyslu nařízení GDPR, je nutné, aby smlouva s ním splňovala požadavky na zpracovatelskou smlouvu dle čl. 28 GDPR. Ochrana osobních údajů a soulad s legislativou upravující práva jednotlivců musí být zajištěny.
Nakládání s daty po skončení smlouvy: Ve smlouvě s dodavatelem by měly být přesně stanoveny podmínky týkající se nakládání s daty při a po skončení smlouvy. Dodavatel by měl být povinen ve stanoveném termínu vrátit všechna data zadavateli ve standardním, čitelném formátu, nebude-li zadavatel požadovat jejich výmaz. Každopádně by mělo být zajištěno, že dodavatel po skončení smlouvy zničí všechna data, která by si případně mohl ponechat, pokud to zadavatel výslovně nepožaduje jinak.
Mechanismus pro řešení sporů ohledně přístupu k datům: Pro případ jakýchkoli sporů ohledně přístupu k datům by smlouva s dodavatelem měla obsahovat mechanismus pro jejich řešení. Tento mechanismus může zahrnovat například závaznou mediaci nebo arbitráž, která by rychle vyřešila případné konflikty.
Jasné stanovení výše uvedených práv a povinností ve smluvních podmínkách umožňuje veřejným zadavatelům vyhnout se potenciálním komplikacím spojeným s vendor lock-in a poskytuje jim flexibilitu při výběru nebo změně dodavatele ICT služeb. Takové nastavení také podporuje konkurenci na trhu, protože zadavatelé se mohou rozhodnout pro nejlepší řešení, aniž by byli nuceni zůstat u jednoho dodavatele kvůli omezením ohledně svých vlastních dat a přístupu k nim. Snadný a plný přístup ke všem svým datům bez omezení také zajišťuje, že zadavatel nebude mít v případě změny dodavatele další nepředpokládané náklady.
Vyloučení případného zadržovacího práva k datům ve smyslu § 1395 občanského zákoníku.
Možnost ukončení smlouvy i při plnění smluvních podmínek a omezení (vyloučení) sankcí v takovém případě: Smlouva by měla obsahovat klauzuli, která zadavateli v rámci prevence vzniku vendor lock-in umožňuje ukončit smlouvu bez sankcí nebo s minimálními náklady, i když dodavatel nadále plní všechny dohodnuté závazky. Tato flexibilita umožní zadavateli přejít na jiného dodavatele, pokud najde lepší nabídku, technologii nebo pokud se změní jeho strategické cíle. Zároveň by takové ustanovení mělo jasně definovat minimální finanční nebo právní dopady při rozhodnutí zadavatele smlouvu ukončit z těchto důvodů.
Definice procesu ukončení smlouvy a přechodu: Smlouva by měla detailně popisovat postup ukončení spolupráce, včetně lhůt, podmínek a způsobu předání veškerých dat, dokumentace a systémů. Dodavatel by měl být povinen poskytnout plnou součinnost při přechodu na nového dodavatele nebo i samotného zadavatele.
Nebo: “v případě, že dojde k uzavření nové smlouvy týkající se předmětu plnění nebo jakékoli jeho části nebo podobného či souvisejícího plnění s novým Dodavatelem odlišným od Dodavatele nebo takové plnění nebo jeho část začne vykonávat z důvodu odstoupení od této Smlouvy Objednatelem nebo Dodavatelem v souladu s touto Smlouvou sám Objednatel, zavazuje se Dodavatel po skončení účinnosti této Smlouvy poskytovat Objednateli nebo jím určeným třetím stranám veškerou součinnost potřebnou pro účely plynulého a řádného poskytování služeb novým Dodavatelem nebo i samotným Objednatelem, pokud bude naplnění tohoto cíle záviset na znalostech Dodavatele získaných na základě plnění Smlouvy. Pro vyloučení pochybností se uvádí, že Dodavatel je v rámci součinnosti dle tohoto odstavce Smlouvy povinen zabezpečit na výzvu Objednatele osobní účast příslušných členů Realizačního týmu na jednáních s Objednatelem či jím určenými třetími stranami, přičemž tato forma součinnosti může být ze strany Objednatele požadována nejdéle do uplynutí 3. kalendářního měsíce po měsíci, ve kterém tato Smlouva zanikla. Po uplynutí lhůty dle předchozí věty tohoto odstavce bude součinnosti zabezpečována formou e-mailové či telefonické konzultace. Dodavatel se zavazuje tuto součinnost poskytovat s odbornou péčí, bez zbytečného odkladu a zodpovědně, a to minimálně po dobu 1 roku ode dne, ve kterém tato Smlouva zanikla. Dodavatel se zavazuje reagovat na požadavek Objednatele nebo jím určené třetí strany a zahájit poskytování součinnosti dle tohoto odstavce Smlouvy nejpozději do 3 pracovních dnů ode dne doručení takovéhoto požadavku. Strany se dohodly, že cena za plnění dle tohoto odstavce je součástí Ceny za poskytování Servisních služeb dle odst. XXX Smlouvy bez nároku na další finanční plnění.“
V praxi se lze setkat i s variantou v podobě smluvního závazku stávajícího dodavatele poskytnout subdodavatelské plnění nově vybranému dodavateli (jde o tzv. obligátní poddodávku, tj. nad rámec pouhého smluvního závazku k poskytnutí součinnosti). Dle našeho názoru ale tato varianta ve svém důsledku vendor lock-in neodstraňuje a spíše pro zadavatele může plnění celkově prodražit (cena původního plnění se ještě může navýšit o ziskovou přirážku nového dodavatele). Navíc toto řešení může dle našeho názoru znamenat i obcházení zákona, když ne přímo jeho porušení – konkrétně zásady zákazu diskriminace dle § 6 ZZVZ (toť zejména v případě pouhého požadování zapojení původního dodavatele do nové zakázky v subdodavatelské roli (tedy bez smluvního závazku původního dodavatele navázat spolupráci s jakýmkoliv nově vysoutěženým dodavatelem (uchazeč, se kterým nebude takový původní dodavatel ochoten uzavřít smlouvu, bude z veřejné zakázky efektivně de facto vyřazen). Jako vhodnější se nám proto jeví smluvní zajištění součinnosti pro „přechodovou fázi“, jak výše uvádíme.
Závazek k pokračování v poskytování služeb během přechodného období: Je důležité, aby v případě ukončení smlouvy dodavatel nadále poskytoval služby po nezbytně nutnou dobu (max. například 6 měsíců), než se zadavatel plně přesune k novému dodavateli nebo k vlastním kapacitám, čímž se zajistí kontinuita provozu.
Smluvní povinnost školení a technické podpory při přechodu: Dodavatel by měl být povinen poskytnout školení a technickou podporu, aby usnadnil adaptaci zadavatele a jeho týmu na nový systém nebo řešení po přechodu na jiného dodavatele.
Dále se doporučuje, aby smlouva obsahovala i ustanovení o pravidelných auditech a přezkumu samotné smlouvy: smlouva by měla zahrnovat povinnosti pravidelného auditu smluvních podmínek a technických aspektů, které umožní zadavateli ověřit, zda smlouva a její ustanovení stále odpovídají aktuálním potřebám a technologiím nebo i regulatorním požadavkům a případně umožnit její úpravu či ukončení.
I cloudová řešení, které mohou mít povahu SaaS (Software as a Service), případně i PaaS (Platform as a Service) anebo i IaaS (infrastructure as a Service) mohou v některých případech pomoci snížit vendor lock-in, a to zejména díky své flexibilitě, případně i kontejnerizaci (open source Docker a open source „orchestrátor“ Kubernetes a možnosti využít standardizovaných rozhraní (REST API, SOAP API) nebo databázové nezávislosti – např. PostgreSQL/MySQL, případně i open source nástrojů typu Terraform / Ansible pro přenositelnou infrastrukturu a automatizaci nasazení prostředí u jiného poskytovatele – využitelné z povahy věci u IaaS a částečně PaaS) nebo i díky využití standardizovaných nástrojů pro autorizaci a autentifikaci (např. OAuth 2.0). Zejména u SaaS je třeba však pečlivě zvážit podmínky přenositelnosti dat a smluvní podmínky týkající se ukončení spolupráce a nezavázat se k nějakým proprietárním cloudovým řešením (jinak by mohl cloud vendor lock-in naopak ještě prohloubit).
Viz jinak i Metodický návod pro orgány veřejné správy na využívání eGovernment cloudu ve veřejné správě od Digitální a informační agentury.
I pro cloudy jinak platí obdobná, ne-li stejná preventivní opatření jako pro lokální „on-premise“ software, tedy zejména vyhrazená změna dodavatele popsaná v kapitole 3.11.3 (na například dalšího uchazeče v pořadí – poskytovatele cloud computingu, kterým může být některý z přeprodejců - substitutů - daného cloudového řešení) nebo rozdělení veřejné zakázky na více částí popsané v kapitole 3.11.2 (multi-cloud řešení) a dobře sepsané smluvní podmínky včetně přístupu k datům, tedy i se snadným exportem dat v otevřených formátech (např. CSV, JSON, XML, Parquet) a možnost je tak i převést k jinému poskytovateli (viz i kapitola 3.8). V takovém případě se pak i více projeví výhody takového cloudového řešení (na rozdíl od on-premise řešení není třeba odepisovat velkou kapitálovou investici, pokud se zadavatel rozhodne pro nové zadávací řízení)
Povinnosti provozovatele informačního systému veřejné správy (ISVS) jsou jedním z klíčových aspektů pro prevenci vendor lock-in, zejména po stránce zajištění kontinuity provozu informačních systémů a přístupu k datům a jejich bezpečnosti; v rámci smluv by měly být jasně definovány povinnosti provozovatele ISVS, které zajistí, že zadavatel (uživatel) bude mít dostatečnou kontrolu nad systémem, daty a jejich správou, a že provozovatel (dodavatel) bude plnit všechny zákonem stanovené povinnosti.
Od 1. 11. 2025 je nutné zajistit také dodržování povinností dle nového zákona č. 264/2025 Sb., o kybernetické bezpečnosti a jeho prováděcí vyhlášky č. 409/2025 Sb., o bezpečnostních opatřeních poskytovatele regulované služby v režimu vyšších povinností, pokud jde o smluvní vztahy s tzv. významnými dodavateli, které v souvislosti s předáváním dat a provozních údajů zmiňujeme už výše v kapitole 3.8. Tím však povinnosti provozovatele, ale i správce, nejsou zdaleka vyčerpány, a to zejména v oblasti právě kybernetické bezpečnosti, jak podle dosavadní, tak podle nově platné regulace, kdy zmiňovaná nová vyhláška o bezpečnostních opatřeních poskytovatele regulované služby v režimu vyšších povinností (mezi které spadají mj. i ústřední orgány státní správy a jiné správní úřady s celostátní působností v rámci výkonu svěřených pravomocí – veřejné správy) mj. předepisuje, že povinná osoba u významných dodavatelů stanoví v rámci uzavíraných smluvních vztahů způsoby a úrovně realizace bezpečnostních opatření a smluvně určí obsah vzájemné odpovědnosti za zavedení a kontrolu bezpečnostních opatření.
Porušení zákonných povinností je většinou také přestupkem, proto pro lepší přehled dotčených povinností (i vědomí souvisejících sankcí) je vhodné nahlédnout i do závěrečných ustanovení zmiňovaných předpisů, v rámci kterých jsou upraveny přestupky (nelze ale zapomínat, že samotné prováděcí předpisy - vyhlášky, které zákonné povinnosti dále rozvádí a konkretizují už tato ustanovení o přestupcích zpravidla neobsahují (to však neznamená, že by jejich nedodržení nebylo přestupkem, jako přestupek je však definováno jen obecné „základní“ nedodržení povinnosti). I orgán veřejné moci se může dopustit přestupku.
Aktivním přístupem v oblasti zajištění dodržování povinností provozovatele ISVS může tedy zadavatel dosáhnout nejen mnohem lepší pozice z pohledu potenciálního proprietárního uzamčení, ale také předejít porušení zákona v oblasti například kybernetické bezpečnosti, ve svém důsledku pak i třeba předpisům v oblasti ochrany osobních údajů nebo majetkovým sankcím a negativní publicitě s tím spojené.
V zákoně o zadávání veřejných zakázek (ZZVZ) existuje několik institutů, které mohou zadavatelům pomoci předcházet vzniku vendor lock-in. Tyto nástroje a postupy zajišťují větší flexibilitu, otevřenost trhu a lepší kontrolu nad smluvními podmínkami, čímž se snižuje závislost na jednom dodavateli. Každý z těchto institutů má za cíl posílit postavení zadavatele a zajistit, aby měl vždy možnost reagovat na změny na trhu a v technologiích, aniž by byl omezen stávajícími smluvními vztahy.
V této podkapitole se podrobněji zaměříme na konkrétní instituty, které zadavatel může využít v souladu se ZZVZ, aby vendor lock-in pokud možno vůbec nevznikl. Těmito instituty jsou:
Prvním z nabízených institutů, které mohou zadavatelům pomoci předcházet vzniku vendor lock-in, jsou předběžné tržní konzultace (PTK) upravené v § 33 zákona o zadávání veřejných zakázek.
CITACE:
§ 33
Předběžné tržní konzultace
Zadavatel je oprávněn vést tržní konzultace s odborníky či dodavateli s cílem připravit zadávací podmínky a informovat dodavatele o svých záměrech a požadavcích, pokud to nenarušuje hospodářskou soutěž; ustanovení § 211 odst. 3 se použije obdobně.
Předběžné tržní konzultace pomáhají zadavatelům lépe pochopit dostupné technologie a možnosti na trhu ještě před vyhlášením veřejné zakázky. Předpokládá se, že ne každý zadavatel je natolik erudovaný v oblasti, v níž plánuje vyhlásit veřejnou zakázku (zejména, pokud jde o nějakou vysoce odbornou, specializovanou nebo významnou veřejnou zakázku, což jsou často právě i veřejné zakázky na informační systémy), a proto potřebuje svoje představit konzultovat s odborníky nebo i dodavateli v daném odvětví či si své nabité znalosti ověřit.
Prostřednictvím PTK lze snížit riziko vzniku vendor lock-in, neboť zadavatelé budou mít širší přehled o dostupných, alternativních řešeních a mohou formulovat technické specifikace tak, aby byly méně závislé na jednom dodavateli a nezapříčiňovaly případné námitky proti zadávacím podmínkám kvůli zjevným rozporům a chybám nebo žádosti o vysvětlení zadávací dokumentace. Jinými slovy, provedením PTK zadavatel dopředu informuje relevantní trh dodavatelů o svém záměru – trh má možnost se na něj připravit a zadavatel má tím větší šanci lépe připravit zadávací podmínky a tím i snížit své časové a finanční náklady spojené s přípravou, zadáním i realizací veřejné zakázky (čímž PTK pomáhají naplňovat také i principy 3E, jednání s péčí řádného hospodáře apod.).
Cílem PTK tak tedy může být nejen obecný průzkum trhu, konzultace zcela konkrétního parametru, ale i získání informace o volbě druhu zadávacího řízení, předpokládané hodnoty veřejné zakázky či získání informací o vhodném nastavení kvalifikačních a hodnotících kritérií, obchodních a technických podmínkách, resp. v podstatě cokoli s cílem připravit zadávací podmínky nebo informovat dodavatele o svých záměrech a požadavcích. PTK je rovněž možné v tomto kontextu chápat jako určitou alternativu k jednacím zadávacím řízením.
Vedení PTK je v zásadě možné před i po zahájení zadávacího řízení, a to i opakovaně, ale musejí být zachovány základní zásady zadávání veřejných zakázek, mj. zásada zákazu diskriminace a zásada transparentnosti, aby nedocházelo k narušování hospodářské soutěže na trhu (v praxi se PTK mohou konat po zahájení řízení z důvodu obdržených žádostí o vysvětlení zadávací dokumentace či námitek proti zadávací dokumentaci, popř. i z vlastního podnětu – PTK však v těchto případech nenahrazují vyřízení těchto žádostí, resp. námitek předepsanými postupy dle ZZVZ).
1. Stanovení předmětu předběžných tržních konzultací
V první fázi PTK si zadavatel musí určit, co má být předmětem PTK – (i) proč chce vést PTK; (ii) čeho chce její realizací dosáhnout a (iii) jaké informace hodlá od dodavatelů (expertů) získat. Jak vyplývá z výše uvedeného ustanovení § 33 ZZVZ, (konečným) cílem však musí být připravit zadávací podmínky a / nebo informovat dodavatele o svých záměrech a požadavcích. Pro kvalitní zpracování PTK je nutné mít na straně zadavatele odborníka, který je správně a efektivně nastaví, provede, vyhodnotí a obhájí.
Rozsah poskytnutých PTK, ani škálu, do jaké míry mohou dodavatelé zasahovat do zadávací dokumentace, ZZVZ nestanoví. Doporučuje se proto, aby byly PTK provedeny s co možná nejširším okruhem potencionálních dodavatelů, aby se tím zamezilo podezření, že zadávací podmínky byly „ušity na míru“ konkrétnímu dodavateli (technickému řešení) a že tak nebyla dodržena zásada zákazu diskriminace (§ 6 ZZVZ).
2. Způsob oslovení účastníků předběžných tržních konzultací
Okruh účastníků PTK může být uzavřený či otevřený. Zadavatel může vést PTK pouze s konkrétními, jím oslovenými, účastníky, či s předem neurčeným a neomezeným okruhem účastníků. Je také možné vymezit otevřený okruh účastníků splňující určité podmínky (např. pouze potenciální dodavatelé s příslušným oprávněním k podnikání; dodavatelé či odborníci s relevantní zkušeností nebo praxí).
Doporučuje se, aby zadavatel zvážil uveřejnit záměr provést PTK veřejně (neadresně), a to např. prostřednictvím Věstníku veřejných zakázek (TEDu), uveřejněním na profilu zadavatele, tiskovou zprávou, webových stránkách, či na webech odborných sdružení, v jejichž předmětu podnikání je plánované plnění. Tímto by se mělo předejít případným stížnostem od těch dodavatelů, kteří se PTK nezúčastnili. Z hlediska prevence vzniku vendor lock-in je také obecně lepší, aby PTK byly pak reálně uskutečněny s více dodavateli (protože jinak riziko vendor lock-in naopak spíše roste, např. stanovením specifických technických podmínek, které mohou představovat i nepřípustné porušení hospodářské soutěže).
3. Vymezení formy vedení a dokumentace (zaznamenání) předběžných tržních konzultací
Zákon o zadávání veřejných zakázek nestanovuje žádné formální náležitosti PTK, ani jak by měly PTK probíhat. PTK mohou proběhnout prostřednictvím emailu, osobního jednání - např. i v rámci setkání na seminářích, konferencích, kde zadavatelé prezentují své strategické cíle, které budou v následujícím období uplatňovat, včetně plánovaných veřejných zakázek, či formami komunikace na dálku (MS Teams, Google Meet apod.). Protože ZZVZ stanoví, že § 211 odst. 3 se použije obdobně, tak pro ústní komunikace platí, že v takovém případě zadavatel zajistí, aby obsah komunikace byl v dostatečné míře zdokumentován s tím, že pokud by ústní komunikace mohla mít podstatný dopad na obsah nebo hodnocení nabídek, musí být zdokumentována vhodnými prostředky, zejména zápisy z jednání (prezenčními listinami), zvukovými záznamy nebo souhrny hlavních prvků komunikace – doporučuje se nejlépe audiovizuální záznam.
O probíhajících PTK povede zadavatel dokumentaci, kterou bude náležitě evidovat společně s pořízenými záznamy.
Je rovněž připuštěno, aby zadavatel část zadávací dokumentace (doporučujeme uvádět např. jako pracovní materiály) poskytnul v rámci PTK dorazivším dodavatelům k vyjádření.
4. Splnění dalších povinností zadavatele souvisejících s využitím předběžných tržních konzultací
Zadavatel nemá povinnost zohlednit výsledek konzultací v nastavení zadávacích podmínek. Zároveň však dle § 36 odst. 4 ZZVZ platí, že pokud zadávací dokumentace nebo některá z výzev uvedených v příloze č. 6 k ZZVZ obsahuje informace, které jsou výsledkem předběžné tržní konzultace, zadavatel takové informace v těchto dokumentech označí, identifikuje osoby, které se na předběžné tržní konzultaci podílely, a uvede všechny podstatné informace, které byly obsahem předběžné tržní konzultace.
PTK jsou projevem oprávnění zadavatele „komunikovat“ svůj záměr s odborníky (osoby, které se následně neúčastní zadávacího řízení – znalci, akademičtí pracovníci apod.), ale i s potencionálními dodavateli, kteří se pak zadávacího řízení budou nebo mohou účastnit. Nesmí však být narušena hospodářská soutěž, tedy ani zásady zadávání veřejné zakázky dle § 6 ZZVZ. Je také zcela nepřípustné, aby tito dodavatelé si svoje kroky mezi sebou navzájem slaďovali ve smyslu činnosti směřující k zadání veřejné zakázky za nepřiměřeně vysokou nebo jinak nevýhodnou cenu.
Na tomto místě je vhodné varovat zadavatele před případným zvažováním situace, že přípravu vymezení předmětu veřejné zakázky zadá konkrétnímu dodavateli. Sice není tento postup zcela zakázaný, avšak významně implikuje právě případné porušení hospodářské soutěže, jelikož dává dodavateli, který připravil zadání předmětu veřejné zakázky, nepochybně počáteční výhodu oproti ostatním dodavatelům, kteří se na přípravě předmětu veřejné zakázky nepodíleli (může se na přípravu podání nabídky do veřejné zakázky lépe připravit, tedy takový postup pak zpravidla znamená porušení zásady rovného zacházení; případně si tento dodavatel může předmět veřejné zakázky ušit i více „na míru“ sobě samému, čímž může dojít k porušení zásady zákazu diskriminace, případně i zásady rovného zacházení a transparentnosti. V tomto směru upozorňujeme i na ustanovení § 36 odst. 1 ZZVZ, které stanoví, že zadávací podmínky nesmí být stanoveny tak, aby určitým dodavatelům bezdůvodně přímo nebo nepřímo zaručovaly konkurenční výhodu nebo vytvářely bezdůvodné překážky hospodářské soutěže (s čímž ve věci technických podmínek pro nadlimitní režim souvisí i § 89 odst. 5 a 6 ZZVZ).
Ostatně na scénář možného narušení hospodářské soutěže pamatuje ustanovení § 48 odst. 5 písm. c) ZZVZ (byť jen v souvislosti s fází přípravy zadávacího řízení), podle nějž zadavatel může vyloučit účastníka zadávacího řízení pro nezpůsobilost, pokud prokáže, že došlo k narušení hospodářské soutěže předchozí účastí účastníka zadávacího řízení při přípravě zadávacího řízení, jiné opatření k nápravě není možné a účastník zadávacího řízení na výzvu zadavatele neprokázal, že k narušení hospodářské soutěže nedošlo.
Z hlediska dodržení hospodářské soutěže lze také doporučit, aby zadavatelé stanovovali dostatečně dlouhé lhůty pro podání nabídek (nad rámec minimálních zákonných lhůt), a to aby dodavatelé měli dostatečný prostor pro podání nabídky, tj. i ti, co se na předběžných konzultacích nepodíleli a „srovnalo se tak startovní pole“. Tento postup odpovídá i článku 41 evropské zadávací směrnice, dle kterého by zadavatel měl stanovit odpovídající lhůty pro doručení nabídek (aby nebyla narušena hospodářská soutěž a nedošlo k porušení zásady zákazu diskriminace a zásady transparentnosti).
Doporučit lze zároveň, aby zadavatelé formou předběžného oznámení zveřejnili svůj úmysl zahájit zadávací řízení ve smyslu § 34 ZZVZ. Provedení těchto opatření, tj. delší lhůty pro podání nabídek nebo zveřejnění předběžného oznámení o svém úmyslu zahájit zadávací řízení, může dle našeho názoru fungovat (aspoň v některých případech) i jako „opatření k nápravě“ ve smyslu výše uvedeného § 48 odst. 5 písm. c) ZZVZ.
5. Průzkum trhu vs. předběžné tržní konzultace
K průzkumu trhu, který až na zmínku o něm v § 16, ZZVZ vůbec neupravuje, se zadavatelé uchylují nejčastěji z důvodu časové a nákladové úspory k získání obecných a veřejně dostupných informací (informací z webů, letáků, konferencí, veletrhů apod.) o možných cenových nabídkách a dostupnosti poptávaného plnění bez přímé komunikace s dodavateli (popř. s obecnějšími dotazy na dodavatele bez spojitosti s konkrétní veřejnou zakázkou a její přípravou, například v souvislosti se svojí nově připravovanou strategií veřejného investování – „meet the seller; od daného lze ještě rozlišit i samotné prezentace zadavatele jako kupujícího, jak funguje veřejné zadávání nebo jak se do něj zapojit – tzv. „meet the buyer“[12]).
Jedná se o nejčastěji používanou metodu analýzy trhu. Průzkum trhu se většinou využívá u menších nebo standardizovaných plnění.
Průzkum trhu se odlišuje od PTK tedy v povaze informací, v dostupnosti těchto informací a informační povinnosti zadavatele. Jinými slovy, průzkum trhu se využívá pro sběr běžně a veřejně dostupných informací, které si sám zadavatel obstarává, popř. obecným oslovením dodavatelů (bez spojitosti s konkrétní připravovanou veřejnou zakázkou a přípravou konkrétních zadávacích podmínek), a zákon o zadávání veřejných zakázek tedy nestanovuje pro průzkum trhu žádné zákonné povinnosti (zejména informační). Jeho výsledkem však nesmí být porušení zásad zadávání veřejných zakázek, zejména zásady zákazu diskriminace, zásady rovného zacházení a zásady transparentnosti. Při dodržení těchto zásad by i průzkum trhu měl pomáhat naplňovat principy 3E, jednání s péčí řádného hospodáře apod.
Vzor výzvy k účasti v předběžné tržní konzultaci a vzor registračního formuláře k účasti jsou přílohou k tomuto materiálu.
Alternativně lze doporučit i využití veřejně dostupných zdrojů jako např. uveřejněných zadávacích dokumentací na profilech zadavatelů k porovnání a načerpání inspirace.
Druhým z nabízených institutů, které mohou zadavatelům pomoci předcházet vzniku vendor lock-in a snížit tak jejich závislost na jednom dodavateli, je rozdělení veřejné zakázky na části upravené v ustanovení § 35 a § 101 ZZVZ.
CITACE:
§ 35
Veřejné zakázky rozdělené na části
Zadavatel může rozdělit veřejnou zakázku na více částí, pokud tím neobejde povinnosti stanovené tímto zákonem. Pokud zadavatel zadává více částí veřejné zakázky v jednom zadávacím řízení, vymezí rozsah těchto částí a stanoví pravidla pro účast dodavatele v jednotlivých částech a pro zadání těchto částí.
CITACE:
§ 101
Rozdělení veřejné zakázky na části
Zadavatelé se k dělení zakázek uchylují zpravidla s cílem podpořit hospodářskou soutěž mezi dodavateli a tak podpořit vůbec i úspěšnost zadání předmětu veřejné zakázky (ale i nižší potenciální ceny), jelikož tím připustí i účast malých a středních dodavatelů (zvýšení konkurence), kteří by se jinak bez rozdělení předmětu veřejné zakázky na části nemohly zadávacího řízení účastnit (z důvodu obsáhlých či přísných zejm. technických kvalifikačních kritérií, či by nebyly schopni obsáhnout celý předmět plnění veřejné zakázky z kapacitních důvodů atd.). Tento postup je ve shodě i s Evropským kodexem osvědčených postupů pro usnadnění přístupu malých a středních podniků k veřejným zakázkám, k jehož dodržování vybízí i evropská zadávací směrnice (k dělení pak může docházet, jak směrnice ve svých recitálech uvádí, na kvantitativním i kvalitativním základě nebo i na základě jednotlivých fází projektu). Rozdělení veřejné zakázky na části je však právem, nikoliv povinností zadavatele (tzv. fakultativní dělení), byť zákon k takovému rozdělení nepřímo vybízí, neboť u nadlimitních veřejných zakázek je součástí povinné zprávy o zadávacím řízení i odůvodnění nerozdělení veřejné zakázky na části, pokud toto odůvodnění zadavatel neuvedl už v zadávací dokumentaci (§ 217 odst. 2 písm. m) ZZVZ, což odpovídá i článku 46 evropské zadávací směrnice, který navíc umožňuje členským státům stanovit vnitrostátním právem i povinnost veřejnou zakázku rozdělit na jednotlivé části. Tak „daleko“ ale český zákonodárce ve své vnitrostátní implementaci nešel).
Viz i recitál 78 evropské zadávací směrnice (citace):
…..Členské státy by měly mít i nadále možnost jít v úsilí o usnadnění účasti malých a středních podniků na trhu veřejných zakázek ještě dále, a to rozšířením oblasti působnosti pro povinnost zvážit vhodnost rozdělení veřejných zakázek na části i pro menší veřejné zakázky, požadavkem, aby veřejní zadavatelé odůvodňovali rozhodnutí o nerozdělení veřejných zakázek na části, nebo stanovením povinnosti za určitých podmínek veřejnou zakázku na části rozdělit…..
Rozdělení veřejné zakázky na části umožňuje zadavateli větší flexibilitu a rozložení rizika vendor lock-in tím, že veřejnou zakázku rozdělí (i) na více dílčích částí, jež budou soutěženy v jednom zadávacím řízení, nebo na (ii) více samostatných veřejných zakázek zadávaných v samostatných zadávacích řízeních.
Zadavatel však nesmí cíleně rozdělit veřejnou zakázku na části za účelem snížení předpokládané hodnoty jejích jednotlivých částí a tím zadat veřejnou zakázku v méně přísném režimu.
Tato povinnost je upravena v ustanovení § 18 odst. 1 a 2 ZZVZ. Z dikce uvedeného ustanovení vyplývá, že i když má zadavatel právo rozdělit předmět veřejné zakázky na části, je vždy povinen (resp. s níže uvedenou výjimkou) dodržet pravidlo sčítání předpokládané hodnoty veškerých částí předmětu veřejné zakázky, a to bez ohledu na to, zda je veřejná zakázka zadávána v jednom nebo více zadávacích řízeních (nebo zadavatelem samostatně nebo ve spolupráci s jiným zadavatelem nebo jinou osobou).
Zadavatel tedy nesmí cíleně dělit předpokládanou hodnotu celého předmětu veřejné zakázky a zadávat jednotlivá dílčí plnění samostatně dle jejich dílčích předpokládaných hodnot (a tím jako podlimitní veřejné zakázky nebo jako veřejné zakázky malého rozsahu), neboť tím dochází k porušování (případně v § 35 ZZVZ zmiňovanému obcházení) zákona. Ustanovení § 580 odst. 1 občanského zákoníku pak zakládá neplatnost právního jednání, a tedy podle nás i smlouvy na plnění veřejné zakázky takto případně zadané (viz i § 264 odst. 2 ZZVZ, dle něhož platí, že smlouva na plnění veřejné zakázky se stává neplatnou z důvodu porušení tohoto zákona pouze v případech, kdy ÚOHS uloží zákaz jejího plnění podle odstavce 1. Neplatnost z jiných důvodů tím není dotčena, tedy například i dle občanského zákoníku.
Z hlediska předpokládané hodnoty veřejné zakázky rozdělené na části je třeba vycházet z místních, časových a věcných souvislostí, tj. ze skutečnosti, zda jednotlivá plnění veřejné zakázky tvoří tzv. funkční celek a jsou zadávána v časové souvislosti. Jedinou možnou výjimkou je situace, kdy
celková předpokládaná hodnota všech případně jednotlivě zadávaných částí veřejné zakázky nepřesáhne 20 % souhrnné předpokládané hodnoty a že předpokládaná hodnota jednotlivé části veřejné zakázky je nižší než částka stanovená nařízením vlády č. 435/2023 Sb. o stanovení finančních limitů a částek pro účely zákona o zadávání veřejných zakázek, tedy že hodnota předmětné části nedosáhne hodnoty pro nadlimitní veřejnou zakázku.
Za funkční celek se považuje především plnění stejného nebo srovnatelného druhu, za něž se pokládá i souhrn jednotlivých určitých relativně samostatných plnění, pokud spolu úzce souvisejí, zejména z hlediska funkčního nebo technologického (z pohledu software – informačních systémů veřejné správy).
I. Zadávání částí veřejné zakázky v rámci jednoho zadávacího řízení
Pravidla pro účast dodavatele v jednotlivých částech
Pravidla pro zadání částí
Jinými slovy, pokud zadavatel rozdělí veřejnou zakázku na části, musí při výběru dodavatele postupovat pro takto rozdělenou část samostatně, zejm. musí posoudit splnění podmínek účasti a hodnotit podané nabídky v každé části veřejné zakázky zvlášť, tzn. je povinen vymezit rozsah těchto částí veřejné zakázky a stanovit podmínky účasti dodavatele v jednotlivých daných částech (mohou – byť striktně vzato nemusí – být stanoveny rozdílné požadavky na kvalifikaci, kritéria hodnocení apod.). Z tohoto pravidla však platí dvě výjimky definované ve výše citovaném ust. § 101 odst. 3 a 4:
II. Zadávání „částí veřejné zakázky“ v podobě samostatných veřejných zakázek v rámci samostatných zadávacích řízeních
Třetím z možných institutů, které mohou zadavatelům pomoci předcházet vzniku vendor lock-in, a snížit tak jeho závislost na jednom dodavateli, jsou vyhrazené změny závazku upravené v ustanovení § 100 ZZVZ, které si zadavatel může vyhradit v rámci zadávací dokumentaci. Jde tak v podstatě o opční právo. Každopádně jde o transparentní a zákonný postup, jelikož vyhrazená změna je součástí zadávací dokumentace, a je tak všem dodavatelům v okamžiku podání nabídky dopředu známa.
Vyhrazená změna závazku dle § 100 ZZVZ se může v rovině informačních systémů veřejné správy týkat rozsahu dodávek, služeb, ceny nebo jiných obchodních nebo technických podmínek, včetně změny dodavatele v průběhu plnění veřejné zakázky. Podmínkou pro postup, tedy využití institutu tzv. vyhrazených změn závazku, je, že podmínky pro změnu závazku a její obsah jsou jednoznačně v zadávací dokumentaci vymezeny (fakticky kdekoli, vždy však z logiky věci i ve vzoru - návrhu smlouvy) a současně změna nemění celkovou povahu veřejné zakázky (nové plnění se musí týkat již zadaného předmětu a druhu plnění, nelze původní předmět rozšířit o něco, co se původně vůbec nepoptávalo, tj. o to, co svojí povahou vybočuje z původního rámce zakázky a tím mění její celkovou povahu). Uváděnou jednoznačnost změny závazku a jejího obsahu je přitom třeba chápat tak, že umožní řádné zpracování nabídky. Pokud by tyto podmínky nebyly kumulativně naplněny, jednalo by se o změnu veřejné zakázky, která by velmi pravděpodobně znamenala podstatnou změnu ze smlouvy na veřejnou zakázku ve smyslu ustanovení § 222 odst. 3 ZZVZ, kterou by bylo třeba zadat v novém zadávacím řízení.
CITACE:
§ 222 odst. 2 ZZVZ
Za podstatnou změnu závazku ze smlouvy na veřejnou zakázku se nepovažuje uplatnění změn závazku vyhrazených podle § 100 odst. 1.
§ 222 odst. 3 ZZVZ
Podstatnou změnou závazku ze smlouvy na veřejnou zakázku je taková změna smluvních podmínek, která by
a) umožnila účast jiných dodavatelů nebo by mohla ovlivnit výběr dodavatele v původním zadávacím řízení, pokud by zadávací podmínky původního zadávacího řízení odpovídaly této změně,
b) měnila ekonomickou rovnováhu závazku ze smlouvy ve prospěch vybraného dodavatele, nebo
c) vedla k významnému rozšíření rozsahu plnění veřejné zakázky.
§ 222 odst. 10 ZZVZ
Podstatnou změnou závazku ze smlouvy na veřejnou zakázku je také nahrazení dodavatele jiným dodavatelem. Nahrazení dodavatele jiným dodavatelem je však možné
a) v případě uplatnění změn závazku vyhrazených podle § 100 odst. 2, nebo
b) pokud změna v osobě dodavatele je důsledkem právního nástupnictví v souvislosti s přeměnou dodavatele, jeho smrtí nebo převodem jeho závodu, popřípadě části závodu, a nový dodavatel splňuje kritéria kvalifikace stanovená v zadávací dokumentaci původního zadávacího řízení.
Vyhrazené změny závazku umožňují zadavateli upravit v zadávací dokumentaci podmínky veřejné zakázky bez nutnosti nového zadávacího řízení a efektivně přizpůsobit smluvní podmínky tak, aby reflektovaly změny v požadavcích nebo potřebách zadavatele, aniž by došlo k neplánovanému vendor lock-in.
Výhodou tohoto postupu je, že k plnění dodávek lze přímo povolat v pořadí druhého z uchazečů. Jiní účastníci však nesmí být ze zadávacího řízení vyloučeni postupem podle § 39 odst. 3 ZZVZ (snížení počtu účastníků). Oproti zákonem povoleným „nepodstatným změnám“ dle § 222 ZZVZ má institut vyhrazených změn závazku více „preventivní“ povahu a působí dopředně a určitě ho lze doporučit, nejen pro možné inflační doložky nebo výhradu posunu termínu plnění veřejné zakázky, ale i pro budoucí rozvojové změny informačního systému.
Do předpokládané hodnoty veřejné zakázky se zahrne předpokládaná hodnota změn závazků ze smlouvy (rámcové dohody), jejichž možnost byla vyhrazena v zadávací dokumentaci podle § 100 ZZVZ (viz § 16 odst. 3 ZZVZ).
V neposlední řadě si dovolujeme upozornit, že pokud si zadavatel vyhradí provedení změny jako povinnost mezi smluvními stranami v zadávací dokumentaci, není oprávněn následně takovou změnu neprovést za předpokladu, že dojde k naplnění podmínek pro takovou změnu.
Z důvodu zachování právní jistoty a transparentnosti doporučujeme provedené změny stvrdit vždy písemným dodatkem, či jinou adekvátní formou.
Zadavatel si může v zadávací dokumentaci vyhradit v souladu s § 100 odst. 2 ZZVZ i změnu dodavatele v průběhu plnění veřejné zakázky, pokud jsou podmínky pro tuto změnu a způsob určení nového dodavatele jednoznačně vymezeny.
Z výhrady musí plynou jednoznačný mechanismus, na základě kterého převezme nový dodavatel zbytek plnění po původním dodavateli. Může se jednat o účastníka zadávacího řízení, který se umístil v rámci hodnocení nabídek jako další v pořadí, nebo někdo z poddodavatelů původního dodavatele, případně o nově založenou SPV takového dodavatele (tedy účelově založenou projektovou společnost). Dále se doporučuje stanovit mechanismus pro výběr dalšího potencionálního dodavatele, pokud by náhradní dodavatel z jakéhokoliv důvodu do probíhajícího závazku vstoupit nechtěl nebo ani objektivně nemohl (například pro nesplnění kvalifikačních podmínek).
Smyslem této výhrady je předejít nutnosti případného nového zadávacího řízení za situace, kdy původní dodavatel nesplní celý závazek ze smlouvy na veřejnou zakázku (například z důvodu insolvence, úpadku, nebo odstoupení od smlouvy ze strany zadavatele pro podstatné porušení smlouvy původním dodavatelem).
Dle našeho názoru si lze představit změnu dodavatele i prostřednictvím institutu postoupení smlouvy dle § 1895 občanského zákoníku s tím, že pokud změna v osobě dodavatele je důsledkem právního nástupnictví v souvislosti s přeměnou dodavatele (fúze, rozdělení společnosti apod.), jeho smrtí nebo převodem jeho závodu, popřípadě části závodu, a nový dodavatel splňuje kritéria kvalifikace stanovená v zadávací dokumentaci původního zadávacího řízení, dochází ke změně dodavatele v souladu s § 222 odst. 10 písm. b) ZZVZ, tedy přímo ze zákona.
Poslední z variant vyhrazené změny závazku v oblasti software / informačních systémů je v souladu s ustanovením § 100 odst. 3 ZZVZ vyhrazení možnosti použití jednacího řízení bez uveřejnění (JŘBU) na nové služby (tedy nikoliv i dodávky!) za předpokladu, že
a) podmínky pro nové služby odpovídají podmínkám pro použití jednacího řízení bez uveřejnění podle § 66 ZZVZ,
b) předpokládaná hodnota nových služeb nepřevyšuje 30 % předpokládané hodnoty veřejné zakázky a
c) v zadávací dokumentaci zadavatel uvede předpokládanou dobu a rozsah poskytnutí nových služeb.
Podmínky dle zmíněného § 66 ZZVZ:
Skutečnost, že si zadavatel v zadávacích podmínkách vyhradil možnost použití JŘBU nezakládá jeho povinnost JŘBU využít. Zadavatel může nové služby zadat v samostatných zadávacích řízeních.
Jedná se o tedy opět o institut tzv. opčního práva[13], jehož účelem je zadavateli umožnit získání nového plnění obdobného tomu, které pořídil v rámci původní veřejné zakázky v situacích, kdy zadavatel nemá jistotu, zda u tohoto dodatečného plnění skutečně v budoucnu vyvstane potřeba jeho realizace (ale nemá tedy ani jistotu opačnou). Případně samozřejmě vždy může zadavatel zahájit i zcela nové zadávací řízení.
Název zadavatele XXX, IČO: XXX, se sídlem XXX, PSČ XXX („Zadavatel“) si Vás dovoluje vyzvat k účasti v předběžné tržní konzultaci zvažované veřejné zakázky XXX („Veřejná zakázka“).
1. VYMEZENÍ ÚČELU A PŘEDMĚTU PŘEDBĚŽNÉ TRŽNÍ KONZULTACE
Zadavatel připravuje Veřejnou zakázku k budoucímu vyhlášení a k jeho řádnému nastavení se rozhodl uskutečnit předběžnou tržní konzultaci.
Účelem této výzvy je informovat dodavatele o vyhlášení předběžné tržní konzultace, informovat je o postupu Zadavatele v předběžné tržní konzultaci a umožnit dodavatelům se do předběžné tržní konzultace přihlásit.
2. ÚČAST V PŘEDBĚŽNÉ TRŽNÍ KONZULTACI
K účasti v předběžné tržní konzultaci je nezbytné vyplnit registrační formulář, který je přílohou této výzvy („Registrační formulář“), a zaslat jej nejpozději do XXX do XXX hod. na e-mailovou adresu XXX.
3. PŘEDPOKLÁDANÝ PRŮBĚH PŘEDBĚŽNÉ TRŽNÍ KONZULTACE
Předběžná tržní konzultace bude probíhat ve XXX fázích, a to následujícím způsobem:
A) Písemný dotazník v rámci předběžné tržní konzultace
Dodavatelům, kteří se do předběžné tržní konzultace přihlásí prostřednictvím Registračního formuláře, bude poskytnut písemný detailní popis Veřejné zakázky, včetně dotazníku (dotazy stanovené Zadavatelem k návrhu některých částí Veřejné zakázky) („Dotazník“).
B) Videokonference v rámci předběžné tržní konzultace
Dodavatelům, kteří se do předběžné tržní konzultace přihlásí prostřednictvím Registračního formuláře („registrovaný dodavatel“), budou zaslány přihlašovací údaje a pokyny k připojení se ke společnému distančnímu jednání zástupců Zadavatele se zástupci registrovaných dodavatelů („Videokonference“).
Videokonference se uskuteční dne XXX (přesný časový okamžik bude registrovaným dodavatelům upřesněn).
Účelem Videokonference bude prezentace popisu Veřejné zakázky (který byl registrovaným dodavatelům poskytnut před konáním Videokonference) registrovaným dodavatelům.
Každý registrovaný dodavatel se bude moci k Videokonferenci přihlásit pouze prostřednictvím maximálně dvou přístupů, přičemž nebude rozhodující, kolik osob bude fyzicky u tohoto přístupu (zařízení) přítomno. Přihlásí-li se za jednoho registrovaného dodavatele více jak dva přístupy, budou nadbytečné přístupy z Videokonference odebrány.
Zadavatel učiní v rámci přiměřených organizačních a finančních opatření vše pro to, aby Videokonference umožnila způsob komunikace s dodavateli tak, jako by Zadavatel realizoval s registrovanými dodavateli osobní setkání. Zadavatel na druhou stranu nikterak negarantuje funkčnost či bezproblémový technický průběh Videokonference. V zájmu eliminace výpadku přenosu Zadavatel doporučuje se k Videokonferenci připojit prostřednictvím stabilního vysokorychlostního internetového připojení.
O průběhu Videokonference bude pořízen záznam, a to formou audio či videozáznamu. Účastí na Videokonferenci dává zástupce registrovaného dodavatele souhlas se zpracováním osobních údajů a pořízením audio či video záznamu pro interní účely Zadavatele. Záznam z Videokonference Zadavatel poskytne každému dodavateli, který se Videokonference zúčastnil, a to na jeho výslovnou žádost.
C) Zaslání vyplněného Dotazníku Zadavateli
Registrovaným dodavatelům bude po Videokonferenci poskytnut časový prostor 14 dní pro zpracování a zaslání Dotazníku zpět Zadavateli.
4. KOMUNIKACE MEZI ZADAVATELEM A DODAVATELEM
Všechny podklady související s předběžnou tržní konzultací budou vyhotoveny v českém a anglickém jazyce (s výjimkou případných částí technických podmínek, ohledně nichž si Zadavatel vyhrazuje právo jejich poskytnutí pouze v českém jazyce).
Komunikace mezi dodavateli a Zadavatelem bude jinak probíhat v českém nebo anglickém jazyce.
5. ZÁVĚR
Případné dotazy a připomínky týkající se předběžné tržní konzultace zasílejte prosím výhradně e-mailem na adresu: XXX.
Komentář:
V případě účasti i česky nehovořících účastníků lze doplnit: Videokonference bude probíhat v českém jazyce se simultánním překladem do anglického jazyka. Překlad do jiného než českého či anglického jazyka si musí zajistit registrovaný dodavatel na vlastní náklady.
k účasti v
PŘEDBĚŽNÉ TRŽNÍ KONZULTACI K VEŘEJNÉ ZAKÁZCE „XXX“ („Předběžná tržní konzultace“)
Identifikace Zadavatele:
Název: XXX
IČO: XXX
Sídlo: XXX
Identifikace Předběžné tržní konzultace:
Název veřejné zakázky: XXX
Identifikace zájemce o účast v Předběžné tržní konzultaci:
Název: XXX
IČO: XXX
Sídlo: XXX
Kontaktní osoba dodavatele pro účely Předběžné tržní konzultace: Jméno: Funkce: e-mail: tel.:
Osoby, které se budou účastnit Videokonference: Jméno: Funkce / vztah k dodavateli: e-mail:
Jméno: Funkce / vztah k dodavateli: e-mail:
Výše uvedený seznam charakterizuje 2 přístupy, z nichž se bude registrovaný dodavatel k Videokonferenci přihlašovat. U každého přístupu může být přítomno více osob za registrovaného dodavatele.
Svým podpisem dává zájemce o účast v Předběžné tržní konzultaci výslovný souhlas se zpracováním osobních údajů a pořízením záznamu z této konzultace.
______________________
Jméno:
Funkce:
[1] Licence může být udělena jako časově omezená nebo neomezená, tj. na dobu neurčitou. Takto sjednaná doba se na první pohled může jevit jako vhodnou, ale není tomu tak, neboť v souladu s ustanovením § 1999 občanského zákoníku ji může zadavatel vypovědět ke konci kalendářního čtvrtletí a je otázkou, zda lze takovou zákonnou možnost smluvní výpovědi platně omezit. Doporučuje se spíše sjednat licenční smlouvu na dobu určitou, a to na dobu trvání majetkových autorských práv k dílu, minimálně však na dobu užívání produktu.
[2]SVOBODA, J. Veřejné zakázky v oblasti ICT a problém závislosti zadavatele na dodavateli. Revue pro právo a technologie. Masarykova univerzita, 2019, roč. 10, č. 19, s. 135-190, dostupné online.
[3]Důkazní prostředky však mohou vznikat až později (například externí nebo interní posudky) – viz str. 16 metodiky Asociace pro veřejné zakázky dostupné zde.
[4] JELÍNEK, K. Zadávání veřejných zakázek na IT. Vybrané povinnosti zadavatele, 1. vydání. Praha, C. H. Beck, 2022, str. 42
[5]JELÍNEK, K., DĚDEK, V., ŠLESINGER, J., STAŇO, R. Zákon o zadávání veřejných zakázek. Praktický komentář. Praha, Wolters Kluwer ČR, 2022, str. 210-211
[6] Více informací lze nalézt na webových stránkách https://publiccode.eu.
[7]Pokud licence vyžaduje, aby veškeré „deriváty“, tedy odvozeniny takto vytvořené byly nadále šířeny pod stejnou svobodnou licencí, hovoří se slangově o tzv. copyleft licenci (např. GNU GPL).
[8] CHÝLE, Josef. Jaké otázky si klást v IT veřejných zakázkách před zahájením migrace dat a problematika vendor lock-in. Zakázkové právo v oblasti ICT a další aktuální témata - Informační list [online]. 2017, č. 1, s. 22.
[9] BOZHANOV, Bozhidar. Bulgaria Got a Law Requiring Open Source. The Policy. [online] Medium, publikováno 4. 6. 2016.
[10]Otevřený zdrojový kód [Architektura eGovernmentu ČR]
[11]Ministerstvo hospodářství a komunikací, Digitální agenda 2020 pro Estonsko
[12]Viz.: ŠEBESTA, M., NOVOTNÝ P., MACHUREK, T., DVOŘÁK, D. a kol., Zákon o zadávání veřejných zakázek, 2. vydání, 2022, Praha, C.H. Beck, str. 231 - 237
[13]O opčním právu hovořil výslovně i předchozí zákon o veřejných zakázkách č. 137/2006 Sb. a také vylučoval z tohoto opčního práva dodávky.