Vendor lock-in

1.otázka: Jaká je role principů 3E u veřejných zakázek, u kterých je založen stav vendor lock-in, případně jak tento princip zajistit?

Stav vendor lock-in je možné chápat, jako specifický druh teoretického konceptu Path dependence. Naše rozhodnutí a volby jsou ovlivněny rozhodnutími učiněnými v minulosti. Path dependece, resp. vendor lock-in, byl popsán Brian W. Arthur v roce 1994 v článku Increasing Returns and Path Dependence in the Economy  a demonstrován např. na případu VHS vs. Betamax.

Vendor lock-in byl identifikován primárně jako ekonomický problém, které má dopad na další rozhodnutí, kdy výběr dané technologie/standardu předurčuje možnosti dalšího rozvoje či nákupu dalších produktů. Ekonomové se tímto problémem zabývali a zabývají z důvodu potlačení konkurence a zvýšení nákladů.

V technologicky vyspělých odvětvích, jako je IT, technologie pro medicínu, či produkty a technologie pro průmysl se vendor lock-inu dá jen obtížně vyhnout. Pokud v daném odvětví neexistuje vysoká míra standardizace a otevřenosti, je pochopitelnou snahou výrobců vytvářet produkty a technologie, případně i licenční podmínky, které neumožňují kombinaci produktů různých výrobců (viz např. technologické i smluvní podmínky u výrobců tiskáren, které na technologické úrovni, ale i smluvní se snaží zákazníka odradit od koupě alternativních tonerů/náplní – čipy v náplních a smluvní podmínky omezující reklamovatelnost zařízení v případě použití neoriginálních tonerů/náplní).

Hodnocení, zdali zadavatel je ve stavu vendor lock-inu, bychom nikdy neměli posuzovat podle toho, zdali existuje síť distributorů pro dané řešení/službu/produkt, ale zdali existují alternativní řešení/produkty/služby. Např. pro produkty de facto monopolu na trhu kancelářského software v dnešní době existuje celá řada variant a alternativ, přesto většina veřejných zadavatelů soutěží pouze marži u dealerů.

Stav vendor lock-in má vždy dopady do hospodářské soutěže. V závislosti na cenové/licenční politice pak může mít dopady na cenu a v neposlední řadě mohou být vynaložené náklady mentálním problémem pro změnu dodavatele a tedy hledání lepšího, rozuměj řešení lépe naplňující původní účel, a to zejména z pohledu případného přezkumu ze strany kontrolních orgánů a obvinění zadavatele z případné neefektivity, kterémuž se zadavatel často nevyhne, ať dělá co dělá, typicky u velkých informačních systémů, zadavatelé mohou udržovat i technologicky zastaralé řešení, hlavně aby se eliminovala provozní rizika, ale rizika investic, které jsou často kontinuální s ohledem na potřebu podchytit legislativní změny.

Důležité je připomenout celkový teoretický koncept Path dependence. Zadavatelé a zakázky nejsou statické, ale procházejí vývojem. Nelze na problém, který byl v oblasti veřejné správy a zadavatelů identifikován až s počátkem 21 století, nahlížet ahistoricky, tj. jako na vědomost, kterou měli zadavatelé mít odjakživa. S tím, jak je problém identifikován, je nutné hledat opatření, která buď pomohou mitigovat rizika nebo je odstraní. Vendor lock-in je inheretní v technologické oblasti a své kořeny má i v patentovém a autorském právu, které tvoří rámec pro ochranu investic, ale umožňuje vytvářet technologické bariery omezující změnu dodavatele (např. upravený vnitřní software v pevném disku v rámci diskových polí znemožňuje použití fyzicky stejných disků, ale se softwarem výrobce pevného disku, zadavatel tak musí s ohledem na autorskoprávní ochranu využít pevný disk z distribučního kanálu výrobce diskového pole).

Zadavatel může pomoci posílit roli principu 3E v rámci zadávání veřejných zakázek tím, že:

a) Hledá otevřená a standardizovaná řešení (nikoli de facto standardy, ale skutečné standardy, a to např. na úrovni rozhraní, vstupů, výstupů, atd.)

b) Kalkuluje náklady na celý životní cyklus řešení

c) Stanovuje životní cyklus s ohledem na technologický vývoj

d) Hledá řešení, které mohou pomoci posílit konkurenci na trhu, např. hledáním alternativ a zvýhodněním řešení, která nabídnou vyšší míru otevřenosti (např. přístupnost zdrojových kódů u software)

e) Váží výhody ekosystémů, které horizontální i vertikální integrací produktů tvoří nenápadný a líbivý vendor lock-in

f) Zejména však soustředěním se na účel a cíl, nikoli na konkrétní řešení

2. otázka: Jaké řešení stavu vendor lock-in, zejména v případech rozsáhlých informačních systémů fungujících i několik desítek let, by se dalo označit za udržitelné?

Předně je nutné vzít v potaz dvě skutečnosti, na které se v praxi zapomíná a zadavatelé jsou často i neprávem obviňováni z nečinnosti či vlastního zavinění. V první řadě je takovéto obvinění často ahistorické, a to z důvodu výše zmiňovaného konceptu path dependance a teorie sociálních problémů (viz např. Čtyř-složkový model veřejně politického cyklu, viz Potůček 2005 (str. 37, POTŮČEK, Martin. Veřejná politika. Upr., dopl. a aktualiz. vyd. v českém jazyce. Praha: Sociologické nakladatelství (SLON), 2005. Studijní texty (Sociologické nakladatelství). ISBN 80-86429-50-4.

Druhá skutečnost ovlivňující obecně pozici zadavatele je asymetrie informací. Zadavatel zpravidla není tvůrcem technologií, nových postupů, ale pouhým konzumentem. Zároveň v minulosti nedisponoval stejnými informacemi, včetně informací o možných rizicích spojených např. s využitím proprietárních systémů a formátů jako výrobce. Pro výrobce bylo obecně jednoduší využít této asymetrie k vytvoření, případně postupnému posilování, závislosti na dodavateli/výrobci.

V praxi je možné rozlišit dvě situace. První nastává u již existujícího systému, druhou je pak pořizování nového systému.

V prvním případě jsou dlouhodobě prováděny úpravy systému a je zajišťována jeho údržba. Dodavatel v tomto případě disponuje unikátním know-how, které bez ohledu na fakticitu vlastnictví zdrojových kódů a dokumentace, značně limituje možnosti změny dodavatele, a to z následujících důvodů:

a) Dokumentace nemusí být úplná.

b) Kvalita dokumentace zdrojových kódů nemusí být dobrá, a to i s ohledem na dlouhodobý historický vývoj.

c) Dodavatel si účelově drží určité know-how.

K tomuto se ještě často přidává problém s určením vlastnictví zdrojových kódů, jejich případným odkupem, atd. Zejména ve státní správě vede v poslední době zadavatele historický vendor lock-in k plánování pořízení nového informačního systému.

Bez ohledu na ochotu dodavatele/výrobce předat zadavateli veškerou dokumentaci, zdrojové kódy i získané know-how (včetně např. různých interních znalostních bází, atd.), je změna dodavatele zpravidla obtížná, případně i nemožná. Existující dodavatel disponuje zjevnou konkurenční výhodou, která je ještě umocněna délkou trvání zadávacího řízení a případné migrační doby na nového dodavatele. Zadavatelé v tomto případě čelí značným provozním rizikům a vzhledem k nutnému souběhu obou dodavatelů i k značným finančním nákladům. Přitom, bez dostatečné lhůty pro prostudování všech podkladů a zdrojových kódů, se dodavatelé vystavují riziku přecenění či podcenění nákladů spojených s převzetím díla. Zakázka je tak často spíš formálně otevřeným zadávacím řízením než reálnou soutěží.

V tomto případě je každá veřejná zakázka a každý smluvní vztah unikátní a je potřeba jej posuzovat ad-hoc a hledat i drobné kroky k vyvážení postavení zadavatele, např. vyřešením problému autorských práv, celistvosti dokumentace, atd. a ověřováním možnosti soutěže, např. formou předběžných tržních konzultací, tak aby se stav využívaný – využívající změnil v rovnocennější obchodní partnerství směřující. Druhý případ, tj. nové soutěže na dodávky zboží a služeb, umožňují zadavateli realizovat podstatně větší množství opatření vedoucí k omezení závislosti na dodavateli, a to s ohledem na získané zkušenosti. Mezi daná opatření mohou patřit např.:

a) Požadavek na dodávku komentovaných zdrojových kódů a jejich kontrola a případný audit (minimálně smluvní ukotvení, které je v případě jakostních nedostatků umožňuje zjednání nápravy a uložení sankcí)

b) Kompilace – převod ze zdrojového kódu do spustitelného – jako jednu z akceptačních metrik pro převzetí díla či jeho části

c) Důsledná kontrola dokumentace

d) Vyloučení používaní binárních částí (tzv. binárních blobů), které omezují plnohodnotné využití zdrojových kódů a samotného software bez zajištění autorských práv k těmto částem, např. proprietární frameworky, atd.

e) Zajištění předání veškerých dat na vyžádání v dokumentované formě, např. po vzoru Google Data Liberation Front

f) Otevřenost od počátku

Zejména poslední opatření může být stěžejní pro dlouhodobou udržitelnost. V tomto případě je systém již od počátku vyvíjen jako otevřený, po vzoru open source softwaru. Zadavatel samozřejmě může omezit okruh subjektů, které budou mít přístup k zdrojovým kódům, např. jen na kvalifikované subjekty disponující dohodou o mlčenlivosti, ale skutečných efektů je zpravidla dosaženo, pokud systém je od počátku vyvíjen jako otevřený, tj. po celou dobu může být pod drobnohledem třetích stran a know-how o fungování systému může být absorbováno větším množstvím subjektů. Tento postup samozřejmě bude mít své kritiky, zejména v případě bezpečnosti bude uplatňován princip security through obscurity. Domnívám se, že v obou případech se dá hledat cesta k realizaci opatření, které zajištění udržitelnost předmětu plnění při zachování principů 3E případně 4E (3E + etika).

3. otázka: Lze v případě „rozbití“ vendor lock-inu zadáváním nové veřejné zakázky na zelené louce dosáhnout fakticky otevřené hospodářské soutěže mezi dodavatelem původní veřejné zakázky a dodavateli novými, resp. konkurenceschopnosti nových dodavatelů v takovém zadávacím řízení?

Záleží na konkrétní situaci. Obecná řešení, podle mého názoru, nemusí fungovat dobře. Určitou konkurenční výhodu bude mít původní dodavatel zřejmě vždy, a to díky znalostem, postupům, které uplatňoval při vývoji, atd. Zároveň u komplexního software (který má stovky tisíc řádků kódu, celou řadu vazeb a nové úpravy musí být realizovány v čas a s minimalizací provozních rizik, tj. ekonomických dopadů) by otevřené zadávací řízení muselo minimálně poskytnout dostatečný prostor pro prostudování zdrojových kódů a stejně tak i prostor pro migraci z původního na nového dodavatele. Je ke zvážení, jestli by nebylo vhodné v takovém případě například s využitím předběžné tržní konzultace umožnit potenciálním účastníkům se seznámit se systémem a nechat je navrhnout lhůty pro vlastní zadávací řízení (pro dostatečné prostudování dokumentace) i lhůtu pro vlastní migraci. Zadavatel by mohl pro takový případ kalkulovat s ekonomickou náročností celé změny dodavatele i zvážit rizika, která by se identifikovala ještě před vlastním zahájením zadávacího řízení (samozřejmě zde JŘSÚ poskytuje nepoměrně více manévrovacího prostoru).

Problém je vždy čas. Málokterý informační systém je statický, ale zpravidla se v něm odrážejí legislativní, funkční i uživatelské změny. Pokud bychom uvažovali o systému, který nedoznává příliš mnoha změn, je jistě reálnější konfrontovat stávajícího dodavatele s jinými účastníky. U dynamického systému, který se často mění, může být tato změna složitější, a to i z důvodu rizik, kterých si je vědom potenciální dodavatel, tj. rizika spojená s rozvojem a údržbou systému po převzetí od původního dodavatele, tedy existují objektivní rizika, která potenciální uchazeči vyhodnotí, jako příliš velká z pohledu ekonomického i reputačního.

Posuzován by tak měl být případ od případu a nehledat řešení, které padne všem i za cenu toho, že existuje poptávka po řešeních, které sluší každému.

Psáno pro časopis Veřejné zakázky. Bez redakčních úprav a korektur. – PETR NOVÁK