Vendor lock-in

„Vendor lock-in“ je výraz, který v souvislosti s digitalizací veřejné správy padá hodně často – označuje stručně řečeno situaci, kdy veřejná správa zůstane odkázaná na milost nějakého dodavatele, který si pak může diktovat libovolné podmínky.

(Vendor lock-inu jsme se mimochodem hodně věnovali v Česko.Digital hned po našem vzniku v roce 2019, kdy jsme vydali Průvodce světem řízení státních IT projektů přeloženého z původně amerického prostředí. Tam je řada rad, jak se vendor lock-inu vyhnout. Nevím, nakolik jsou relevantní v [současném] českém prostředí.)

Uvědomil jsem si, že těch typů vendor lock-inu rozeznávám víc a ne všechny vnímám stejně negativně:

1. Nevlastníme data ani kód

Ze všeho nejhorší je, když si objednavatel řešení vlastně jen „pronajímá“ od dodavatele. Na objednávku tedy vznikne třeba nějaký IT systém, ale objednavatel ho sám neprovozuje, nevlastní zdrojové kódy a zejména nevlastní ani data. Pokud si dobře pamatuju, tohle byla například původní pražská Open Card. Pokud dodavatel chce, může jedním čudlíkem vypnout velkou část pražské MHD, což mu dává prakticky neotřesitelnou pozici v jakýchkoliv jednáních. A pokud chce objednavatel situaci vyřešit přechodem jinam, musí si ještě draze vykoupit „vlastní“ data. Gratulujeme!

2. Vlastníme data, nevlastníme kód

Pak je tu lepší varianta, kdy už dodavatel nevlastní data, ale vlastní zdrojové kódy a případně systém provozuje. Stále ho tedy může vypnout a taky může totéž řešení, vyvinuté za veřejné peníze, opětovně prodávat jiným částem veřejné správy, což se, pokud vím, docela běžně děje. Z pohledu veřejné správy tím platíme jednu věc mockrát dokola a pokud se dodavatel například rozhodne systém dál nepodporovat a nevyvíjet, máme smůlu.

3. Vlastníme data i kód – ale máme externí závislosti

A do třetice je tu ještě varianta, ve které sice vlastníme data i kód, ale systém stojí na produktu třetí strany, ze kterého je těžké odejít. Tohle můžou být v soukromém sektoru třeba produkty postavené na cloudu od AWS – i když se ukáže, že vás ty služby stojí milión, přejít jinam by znamenalo překopat velkou část vašeho systému, což situaci opět blokuje.

Na tuhle poslední variantu nemám extra jasné názory, protože vyhýbat se rizikovým produktům třetích stran by často vzalo veliké dodatečné zdroje (nejen finanční). Vlastně se bavíme o tom, jestli vychází rozumně poměr mezi ušetřenými zdroji a potenciálními problémy. Tady taky zároveň vnímám docela velký rozdíl mezi soukromým a veřejným sektorem.


Jak se na tohle díváte? Sedí tohle rozdělení, anebo je ta situace v reálu jiná? Nejsem ani přinejmenším odborník, takže mě zajímají zkušenosti z české praxe.

1 Like

Diky, moc pekne. Ja bych dodal, ze vendor lock-in muze byt mnohem mekci. A pritom mit stejne dusledky. Napriklad dodavatel, ktery kontroluje klicovou sluzbu (jako treba spisovou slozku, agendovy system…) a jeji API, ma vyhodu nad konkurenci, ktera se na jeho API musi pripojovat.

Muze ji behem vyvoje hazet klacky pod nohy v nejake “relativne male” mire, ktera ale produkt konkurence ve vyberku vyrazne zdrazi a udela cenove nekonkurenceschopny. Deje se to v podstate vsude, napric vsemi systemy statni/regionalni spravy.

3 Likes

Spadají do toho třeba i otevřená data? Kdy je třeba poskytují, ale v obtížně zpracovatelném formátu.
A určitě bych tohle neomezoval jen na veřejnou správu, tohle je obecný problém.

1 Like

Je to tak, otevřená data s tím souvisí. Například blahé paměti otevřená data o jízdních řádech, která jsme docela dlouho tahali z firmy CHAPS. Obecně se podle mě dá říct, že dobře nastavený mechanismus zveřejňování otevřených dat může riziko vendor lock-inu omezit.

1 Like