Klauzula vendor lock-in w umowach IT

Na czym polega vendor lock-in?

Klauzula umowna vendor lock-in polega na uzależnieniu się zamawiającego od rozwiązania technologicznego oferowanego przez jednego dostawcę. W rezultacie przeprowadzenie efektywnej zmiany (np. oprogramowania w firmie) staje się niemożliwe bez poniesienia bardzo wysokich wydatków, poświęcenia ludzkich zasobów oraz czasu na znalezienie lub stworzenie alternatywnego sposobu rozwiązania danego problemu.

Pomimo faktu, że zamawiający nabywa prawa do korzystania z oprogramowania – czy to w drodze licencji czy też przeniesienia praw autorskich – nadal jest zmuszony do ponoszenia opłat związanych z utrzymaniem, korzystaniem, serwisem i rozwojem software’u na niekorzystnych warunkach u jednego dostawcy usług chmurowych w kontekście usług chmurowych u innego dostawcy własności intelektualnej a innymi dostawcami strategia multi cloud i otwarte standardy i ich możliwe konsekwencje dla nowych technologii plu możliwość przeniesienia mająca szczególne znaczenie.

Gdzie stosuje się klauzule vendor-lock in?

Klauzule typu vendor lock-in spotyka się przede wszystkim w umowach z sektora IT. Tam, gdzie w grę wchodzą nowe technologie i złożone projekty programistyczne ograniczenie elastyczności zamawiającego jest względnie proste. Obszar IT jest predestynowany do wystąpienia tego problemu także i z tego względu, że współpraca stron często utrzymuje się przez długi czas, a implementacja zamówionych rozwiązań wymaga daleko idącej ingerencji w strukturę i procesy firmowe.

Warto też pamiętać, że ryzyko uzależnienia się od dostawcy wzrasta wraz z wiekiem oraz stopniem złożoności systemu. Zwykle okazuje się, że coraz trudniej jest znaleźć wykonawcę, który byłby w stanie kontynuować osiągnięcie poprzednika. Co więcej, w miarę jak pracownicy szkolą się do korzystania z jednego oprogramowania, zmiana na inne pociąga za sobą dodatkowe koszty oraz konieczność poświęcenia czasu na naukę od początku.

Warto podkreślić, że związanie się firmy z jednym dostawcą oprogramowania nie musi być szkodliwe. Często współpraca układa się pomyślnie przez wiele lat. Niemniej jednak taki układ sił ogranicza elastyczność, a w branżach, gdzie dostęp do infrastruktury IT ma znaczenie krytyczne, jak np. bankowość czy finanse, może okazać się wręcz niebezpieczny.

Szczególną uwagę należy zwrócić na obecność klauzul vendor lock-in w umowach zawieranych w reżimie zamówień publicznych. W tej sytuacji bardzo trudno o zmiany warunków umowy i wycofanie się ze współpracy, a zamawiający, który raz związał się z dostawcą, będzie zmuszony do korzystania z monopolu dostawcy przez lata. Zmonopolizowanie dostawcy oprogramowania jest szczególnie niekorzystne, kiedy:

• jakość usług świadczonych przez dostawcę nie osiąga zamierzonego poziomu;
• zakres i specyfikacja usług świadczonych przez dostawcę zmienia się w sposób niespełniający wymagań biznesowych zamawiającego;
• dostawca podnosi ceny za korzystanie z usług, wiedząc, że ich odbiorca jest związany współpracą.
• dostawca usługi ogłosił upadłość i po prostu przestał istnieć.

Jak wygląda przykładowa klauzula vendor lock-in?

Rozpoznanie mechanizmu vendor lock-in w umowie nie zawsze będzie proste. Wykonawcy oprogramowania wykorzystują różnego rodzaju klauzule na poszczególnych etapach życia aplikacji, aby zmonopolizować dostarczane przez niego rozwiązanie.

Najbardziej reprezentatywnym przykładem jest sytuacja, kiedy zamawiający korzysta z różnych usług chmurowych tego samego producenta, które współpracują wyłącznie z konkretnym środowiskiem, np. programu CRM, klienta poczty i usługi STaaS (ang. Storage as a Service), czyli udostępnienie przestrzeni chmurowej na dyskach dostawcy. Niekiedy jednak mechanizmy mogą być bardziej złożone. Na co warto zwrócić uwagę w umowie?

• uzależnienie wdrożenia oprogramowania od skorzystania z usług serwisowych i utrzymaniowych tego samego dostawcy oprogramowania;
• dostawca wymaga ponoszenia opłat serwisowych już od samego początku współpracy, jeszcze w fazie projektowej.

Dostawca oprogramowania może dążyć też do utrudnienia dostępu do usług podmiotów trzecich, np. żądając dodatkowych opłat licencyjnych za integrację dostarczonego oprogramowania z third-party software albo wprowadzając w umowie zapis wprost, że takie wykorzystanie oprogramowania jest niedozwolone. Jeszcze inną taktyką może być wskazanie w kontrakcie, że dostawca nie jest zobowiązany do ujawnienia danych dotyczących interoperacyjności, czyli specyfikacji technicznej pozwalającej na współpracę z innymi produktami lub systemami.

Aby dodatkowo wzmocnić vendor lock-in, w umowach pojawiają się zwykle wysokie kary umowne, które skutecznie zniechęcają zamawiającego do podejmowania prób wyjścia z patowej sytuacji.

Regulacje vendor lock-in

Zawierając umowę o zaprojektowanie, wdrożenie lub utrzymanie oprogramowania należy dokładnie przeanalizować zakres uprawnień i obowiązków stron. Zdecydowana większość umów zawieranych w branży IT to umowy nienazwane, które nie zostały w żaden sposób uregulowany przez obowiązujące przepisy. Oznacza to, że strony układają treść stosunku prawnego z odwołaniem się do zasady swobody umów wyrażonej w art. 3531 k.c. Zgodnie z tym przepisem treść umowy może zostać sformułowana w sposób dowolny tak długo, jak nie narusza ona:

• istoty stosunku prawnego;
• zasad współżycia społecznego;
• bezwzględnie obowiązujących przepisów prawa.

Aby uniknąć „wpadnięcia w pułapkę” vendor lock-in warto zlecić przygotowanie umowy kancelarii prawnej doświadczonej w obsłudze podmiotów z sektora IT.

Choć vendor lock-in nie został zaklasyfikowany do umów nazwanych, warto zwrócić uwagę na rekomendacje Komisji Nadzoru Finansowego w tym zakresie. Zalecenia są kierowane do podmiotów działających na rynkach finansowych (przede wszystkim banków), ale ich ogólny zarys można wykorzystać do ukształtowania współpracy stron. O jakich rekomendacjach mowa?

Rekomendacja D a klauzula vendor lock-in

W rekomendacji D – sekcja 10.4 wskazano, że bank powinien analizować ryzyko związane z upadłością zewnętrznego dostawcy lub jego nagłym wycofaniem się ze współpracy oraz posiadać skuteczne plany awaryjne na wypadek wystąpienia takich sytuacji. W miarę możliwości bank powinien również dążyć do tego, aby ograniczyć ryzyko uzyskania przez usługodawcę pozycji monopolistycznej.

Jednocześnie KNF wskazuje, że wybór usługodawcy w żaden sposób nie zwalnia banku z odpowiedzialności za jakość świadczonych usług względem klientów. Jeżeli więc okaże się, że usługi świadczone przez wybrany podmiot nie spełniają oczekiwań, ale jego zmiana jest bardzo trudna lub wręcz niemożliwa, to bank ponosi całkowite ryzyko takiej sytuacji.

Rekomendacja M a vendor lock-in

Podobne zalecenia znalazły się w rekomendacji M. W sekcji 11.8 organ nadzoru wskazał, że dla procesów, których wykonanie jest zlecane w całości lub części podmiotom zewnętrznym, plany utrzymania ciągłości działania i plany awaryjne banku powinny obejmować – w wymagających tego przypadkach – alternatywne źródło usług oraz zasoby niezbędne do zmiany dostawcy usług w niezbędnym czasie. Zmiana musi być także możliwa w sytuacji awaryjnej.

Komisja Nadzoru Finansowego sugeruje, aby procedura dotycząca planu awaryjnego pozwalała w sposób jednoznaczny ustalić m.in.:

• kiedy taki plan awaryjny należy uruchomić;
• jak będą podejmowane decyzje w sytuacji kryzysowej;
• które procesy mają charakter krytyczny, jak długo będzie trwało ich przywrócenie i jakich zasobów wymaga;
• w jaki sposób będzie realizowana komunikacja z klientem banku w sytuacji kryzysowej;
• jak i kiedy zostaną przywrócone dane i zasoby niezbędne do prowadzenia działalności.

Na wszystkie te pytania zamawiający powinien znać odpowiedzi już na etapie negocjowania warunków z dostawcą usług IT.

Zagrożenia dla usług chmurowych a stanowisko KNF

Niezależnie od wymienionych wyżej rekomendacji KNF warto zwrócić uwagę na komunikat organu nadzoru w przedmiocie przetwarzania przez podmioty nadzorowane informacji w chmurze obliczeniowej publicznej lub hybrydowej (publiczno-prywatnej).

Wybierając dostawcę usługi chmurowej, podmiot nadzorowany ma obowiązek uwzględnić w procedurze szacowania ryzyka zagrożenia ogólne dla stosowania technologii chmurowej. Takim zagrożeniem jest – zgodnie z VI.2.1.e wytycznych – m.in. brak zgodności technologicznej pomiędzy usługami różnych dostawców chmury obliczeniowej powodujące przywiązanie do jednego dostawcy usług chmury obliczeniowej poprzez ograniczenie albo brak możliwości przenoszenia (korzystania z identycznych) usług lub przetwarzania informacji (vendor lock-in). Takie wyniki szacowania ryzyka powinny być regularnie analizowane i aktualizowane.

W zależności od tego, w jakiej branży działa dany podmiot może pojawić się konieczność dostosowania wyboru usługodawcy do wskazanych wyżej wytycznych lub nie. Nawet jeśli jednak firma korzystająca z usług software house’u nie ma formalnie takiego obowiązku, warto potraktować stanowisko KNF jako swego rodzaju kierunkowskaz.

Jak uchronić się przed vendor lock-in przed zawarciem umowy?

Podpisując umowę z dostawcą oprogramowania, warto rozważyć kilka kwestii, których niedopilnowanie może skutkować ograniczeniem pola manewru zamawiającego.

W pierwszej kolejności strony powinny dokładnie określić swoje oczekiwania względem software’u (w przypadku zamawiającego) oraz możliwości technicznych (w przypadku wykonawcy). Poza tym należy dokładnie przeanalizować warunki współpracy, w tym prawa i obowiązki stron, zakres przeniesienia praw autorskich do oprogramowania, możliwości modyfikacji warunków współpracy oraz korzystania z usług podmiotów trzecich. Dla zwiększenia wiarygodności software house’u dobrym pomysłem będzie zlecenie przeprowadzenie badania due diligence, który wskaże na potencjalne zagrożenia i ograniczenia.

Istotną rolę w planowaniu współpracy odgrywa dobre zrozumienie tzw. cyklu życia umowy, czyli tego kiedy, do czego i na jakich warunkach będzie zobowiązany wykonawca. W tym zakresie umowę można podzielić na etap przedwdrożeniowy, wdrożeniowy, wykonawczy, utrzymaniowy i serwisowy. W każdej z tych faz prawa i obowiązki stron mogą wyglądać nieco inaczej.

Wreszcie należy opracować dobry exit plan. Dobry, czyli jaki? Taki, który zostanie zaakceptowany przez obie strony i będzie określał:

• co dzieje się z danymi przekazanymi przez zamawiającego wykonawcy po zakończeniu współpracy (np. archiwizacja i przekazanie zwrotne, zniszczenie);
• kto ponosi koszty związane z zakończeniem współpracy i związanymi z tym czynnościami;
• czy strony mają obowiązek współpracować ze sobą w okresie między złożeniem oświadczenia o wypowiedzeniu umowy a formalnym zakończeniem współpracy.

W praktyce w opisie procedur exit strategy często można spotkać się z tzw. Macierzą RA(S)CI. Definiuje ona:

• kto jest odpowiedzialny za przeprowadzenie „wyjścia” (ang. Responsible);
• kto zatwierdza odbiór procedur związanych z zakończeniem współpracy i weryfikuje ich poprawność (ang. Accountable);
• kto wspiera płynność i integralność zakończenia współpracy (ang. Support);
• kto udziela informacji niezbędnych do realizacji zadań związanych z exit strategy (ang. Consult);
• kto ma być poinformowany o realizacji procedury wyjścia, np. dział IT zamawiającego, członkowie zarządu (ang. Inform).

Jak wyjść z vendor lock-in?

Załóżmy, że firma korzystająca z rozwiązań informatycznych już podpisała umowę o współpracę, która przewiduje rozwiązania ograniczające elastyczność korzystania z ofert innych usługodawców. Czy to oznacza, że taka sytuacja zawsze będzie niekorzystna, a jeśli tak, że nie da się z niej wybrnąć? Nie zawsze tak będzie!

W pierwszej kolejności warto rozważyć, czy warunki zawartej umowy rzeczywiście są dla przedsiębiorstwa niekorzystne w porównaniu z rozwiązaniami, jakie oferuje konkurencja. Przecież z jakiegoś względu firma wybrała właśnie takiego, a nie innego dostawcę. Warto też usiłować rozwiązywać różnego rodzaju spory, które pojawiają się po drodze, w sposób polubowny. Być może niektóre ustępstwa będzie można wynegocjować, np. zmianę architektury oprogramowania w zamian za dodatkowe, relatywnie niskie w porównaniu z przygotowywaniem kodu źródłowego do nowa, wynagrodzeniem.

Jeśli zamawiający przeprowadził wcześniej badania due diligence i wie, że dostawca oprogramowania to firma działająca na rynku od lat trzeba również rozważyć, czy zmiana software house’u na inny nie spowoduje, że sytuacja wewnętrzna stanie się mniej przewidywalna.

„Wyjście” z vendor lock-in wymaga dokładnego przeanalizowania umowy. Kontrakty zawarte na czas nieoznaczony można zwykle wypowiedzieć zachowaniem umownego okresu wypowiedzenia, jeżeli został on wskazany. W przeciwnym razie umowa ulega rozwiązaniu niezwłocznie z momentem złożenia oświadczenia drugiej stronie. Jeżeli strony umówiły się na współpracę na czas oznaczony, z reguły oznacza to petryfikację stosunku prawnego, który można zakończyć wyłącznie w przypadkach wskazanych w umowie.

W jaki sposób bezpiecznie budować infrastrukturę IT w swojej firmie?

Przed problemem związanym z budową infrastruktury IT staje wielu przedsiębiorców, którzy potrzebują kompleksowego systemu IT, aby móc funkcjonować na rynku. To może być system bankowy lub ubezpieczeniowy, ale też ERP do zarządzania czasem pracy kierowców w firmie transportowej czy WMS w firmie zajmującej się logistyką. Czy można wskazać na idealny model współpracy z software housem? W literaturze często wskazuje się na trzy możliwe strategii działania.

• Model maksymalnie bezpieczny – choć niekoniecznie optymalny kosztowo – zakłada, że każda usługa jest świadczona przez innego dostawcę. Należy wtedy zadbać o interoperacyjność poszczególnych systemów. To także konieczność ciągłego szkolenia się pracowników;
• Model maksymalnie ryzykowny – ale często najtańszy i efektywny – polega na tym, że wszystkie usługi są dostarczane przez jeden podmiot, którego historia działania na rynku została gruntownie przeanalizowana. To również ryzyko, że dostawca z biegiem czasu zacznie dostarczać rozwiązania przestarzałe, wskutek czego w firmie zacznie rosnąć dług technologiczny;
• Model hybrydowy zakłada, że dostawcę danego rozwiązania wybiera się w zależności od aktualnych oczekiwań firmy oraz okoliczności; W tym przypadku ryzyko vendor lock-in jest wprawdzie niewielkie, ale z kolei sama infrastruktura może stać się nadmiernie skomplikowana oraz droga w utrzymaniu.

Kancelaria Prawna RPMS świadczy kompleksowe usługi w zakresie nowych technologii. Nasi prawnicy przeanalizują zapotrzebowanie firmy na rozwiązania technologiczne, a także doradzą optymalny model funkcjonowania w oparciu o strategię biznesową przedsiębiorcy z uwzględnieniem obowiązujących wytycznych i przepisów prawa. Dla naszych klientów negocjujemy warunki współpracy z dostawcami rozwiązań IT, analizujemy umowy oraz identyfikujemy ryzyko prawne, finansowe i gospodarcze.

Pytania i odpowiedzi

Zaufali nam: