Vendor lock-in. Pułapka, w którą wchodzi się z uśmiechem.

Zadzwonił do mnie klient z dość spokojnym tonem. Zbyt spokojnym, jak na kogoś, kto właśnie odkrył, że jego firma od kilku lat zbiera dane, do których nie ma dostępu.

System działał. Faktury wychodziły, magazyn się zgadzał, raporty generowały się na czas. Wszystko wyglądało dobrze – dopóki klient nie postanowił przeprowadzić poważniejszej analizy. Chciał zestawić dane sprzedażowe z historią zamówień, zobaczyć trendy, wyciągnąć wnioski. Normalny ruch w normalnej firmie.

Okazało się, że danych nie można wyeksportować. Nie ma takiej opcji. System ich nie udostępnia – ani przez interfejs, ani przez API, którego po prostu nie ma. Jedyna możliwość pracy z danymi to korzystanie z wbudowanych raportów. A wbudowane raporty nie dają tego, czego klient potrzebuje.

Odpowiedź producenta oprogramowania była krótka i rzeczowa: dane są dostępne wyłącznie za pośrednictwem systemu. Jeśli system tego nie pokazuje, to znaczy, że tak ma być.

Firmowy dział prawny zaczął zadawać pytania. Kto jest właścicielem danych wprowadzonych przez pracowników klienta, na sprzęcie klienta, w ramach działalności klienta? Producent oprogramowania odpowiedział nie wprost – ale zasugerował, że w przypadku sporu może zawiesić działanie systemu do czasu jego rozwiązania.

I to był moment, w którym wszystko stało się jasne.

Zakładnik własnych danych

Zawieszenie systemu oznaczałoby paraliż operacyjny firmy. Magazyn, sprzedaż, fakturowanie – wszystko w jednym miejscu. Bez systemu: nic. Klient miał do wyboru walczyć o swoje dane i ryzykować zatrzymanie działalności albo odpuścić i żyć z tym, co ma.

Odpuścił. Tak kończy się większość takich sporów – nie wyrokiem sądowym, tylko cichą kapitulacją strony słabszej, bo słabsza jest ta, której zależy na czasie.

Nie winię klienta za tę decyzję. Winię umowę, którą podpisał kilka lat wcześniej. A właściwie – jej brak. Nikt nie zadał wtedy pytania o własność danych. Nikt nie sprawdził, czy istnieje możliwość eksportu. Nikt nie wpisał do umowy, że dostęp do danych jest warunkiem koniecznym, a nie łaską dostawcy.

Producent oprogramowania działał legalnie. Być może nieetycznie, ale legalnie. Bo umowa na to pozwalała.

Jak wygląda pułapka, zanim się w nią wpadnie

Vendor lock-in rzadko wygląda jak pułapka w momencie zakupu. Wygląda jak wygoda.

Jeden system, który robi wszystko. Spójna obsługa, jeden dostawca, jeden punkt kontaktowy. To brzmi dobrze – szczególnie dla właściciela firmy, który nie chce zarządzać technologią, tylko prowadzić biznes. Problem pojawia się wtedy, gdy relacja z dostawcą przestaje być partnerska.

Klasyczny scenariusz przebiega tak: firma zamawia system, wdraża go, szkoli pracowników, integruje z codzienną pracą. Przez rok, dwa, trzy wszystko gra. Dostawca podnosi stawkę za utrzymanie o dwadzieścia procent – firma płaci, bo koszt migracji jest wyższy niż różnica w opłacie. Dostawca znowu podnosi – firma znowu płaci. W pewnym momencie pytanie nie brzmi „czy ten system jest dla nas najlepszy”, tylko „czy nas stać na to, żeby z niego wyjść”.

Zazwyczaj okazuje się, że nie.

I to nie jest wyjątek. To jest model biznesowy.

Trzy przejawy uzależnienia, które warto rozpoznać

Uzależnienie od dostawcy przybiera różne formy i nie zawsze dotyczy danych. Pierwsza, najczęstsza: dane w formacie własnościowym. Eksport jest niemożliwy albo produkuje plik, którego nikt inny nie rozumie. Dane są technicznie dostępne, ale praktycznie więzione.

Druga: brak API lub API celowo ograniczone. Jeśli system nie pozwala na programowy dostęp do danych, integracja z innymi narzędziami jest niemożliwa lub kosztuje osobno – i to dostawca dyktuje warunki tej integracji. 

Trzecia, najtrudniejsza do zobaczenia: wiedza i procesy ułożone pod konkretne narzędzie. Pracownicy nauczyli się systemu, procesy firmy zostały przeprojektowane pod jego logikę, dokumentacja opisuje „jak to robimy w systemie X”. Migracja to już nie kwestia przeniesienia danych – to przeprojektowanie sposobu działania całej firmy. A to kosztuje więcej niż jakikolwiek abonament.

Co powinno znaleźć się w umowie, zanim podpiszesz

Historia mojego klienta ma jeden konkretny wniosek: po zakończeniu sporu, gdy zaczął budować nowe rozwiązanie, każda umowa z wykonawcą zawierała już zapisy, których wcześniej nie było.

Własność danych – expressis verbis. Zapis mówiący wprost, że dane wprowadzone przez użytkowników systemu są własnością zamawiającego, a dostawca pełni wyłącznie rolę ich przechowywania i przetwarzania.

Prawo do eksportu w każdym momencie. Nie „po zakończeniu umowy”, nie „na pisemny wniosek z czternastodniowym terminem realizacji” – w każdym momencie, w ustandaryzowanym formacie, bez dodatkowych opłat.

Ciągłość dostępu w przypadku sporu. Zapis zakazujący dostawcy jednostronnego zawieszenia systemu do czasu rozstrzygnięcia sporu – jeśli umowa o tym milczy, dostawca może to zrobić i zrobi, gdy uzna, że mu się to opłaca.

To nie są wymagania wyśrubowane ani nadmiarowe. To podstawowa higiena prawna w relacji z dostawcą oprogramowania. Fakt, że rzadko się je stosuje, nie wynika z tego, że są zbędne – wynika z tego, że na etapie zakupu wszyscy są jeszcze przyjaciółmi.

Dlaczego o tym nie myślimy na początku

Zakup systemu informatycznego wygląda jak decyzja techniczna. A decyzje techniczne deleguje się do działu IT albo do zewnętrznego wdrożeniowca. Prawnik siedzi po drugiej stronie budynku i zajmuje się umowami z kontrahentami, nie z dostawcami oprogramowania.

To jest błąd organizacyjny, nie techniczny.

Każda umowa z dostawcą systemu jest umową o dostępie do danych operacyjnych firmy. Danych, na podstawie których podejmujesz decyzje. Danych, które zbierałeś latami. Jeśli tej umowy nie czyta nikt, kto myśli kategoriami ryzyka biznesowego – tylko ktoś, kto porównuje funkcjonalności – to ryzyko wejścia w pułapkę jest bardzo wysokie.

Mój klient zapłacił za tę lekcję stosunkowo niewiele. Inni płacą drożej.

Uzależnienie to nie zawsze zły wybór. Ale powinien być świadomy.

Chcę być precyzyjny, bo łatwo tu wpaść w pułapkę odwrotną.

Zlecenie budowy dedykowanego systemu nie jest złą decyzją samo w sobie – często jest najlepszą możliwą. Problem nie leży w tym, że ktoś zewnętrzny pisze kod i utrzymuje system. Problem leży w tym, jak skonstruowana jest umowa regulująca tę relację i kto faktycznie kontroluje dane.

Stopień uzależnienia od dostawcy jest zawsze kwestią umowną, nie techniczną. Dwa systemy o identycznej architekturze mogą dawać klientowi zupełnie inny poziom autonomii – zależnie od tego, co zostało zapisane w umowie przed jej podpisaniem. Jeden kontrakt zapewnia pełen eksport danych na żądanie, dostępne API, jasną ścieżkę migracji i zakaz jednostronnego zawieszenia systemu. Drugi kontrakt milczy w tych kwestiach i zostawia całą władzę po stronie wykonawcy.

Dlatego przed każdym wdrożeniem warto zadać trzy pytania: co się stanie, gdy za dwa lata zdecyduję się zmienić dostawcę? Co się stanie, gdy dostawca podniesie stawkę o pięćdziesiąt procent? Co się stanie, gdy dostawca przestanie istnieć?

Jeśli odpowiedź na każde z nich brzmi „nie wiem” albo „katastrofa” – to nie jest stan, w którym powinieneś podpisywać umowę. To jest stan, w którym powinieneś negocjować albo szukać dalej.

W taką pułapkę wchodzi się z uśmiechem, bo na początku naprawdę jest dobrze. Pułapka nie zatrzaskuje się w momencie zakupu – zatrzaskuje się wtedy, gdy po raz pierwszy chcesz z niej wyjść.

I właśnie dlatego warto o tym myśleć, jeszcze zanim wejdziesz.