Vendor lock - jak nie dać się zamknąć w technologicznej pułapce?

Wprowadzenie i cel odcinka

Cześć, dzień dobry, z tej strony Grzegorz Tabor, a to jest podcast IT i Biznes, gdzie jako dyrektor technologiczny pomagam przedsiębiorcom i menadżerom realizować projekty IT, które wspierają cele biznesowe skutecznie i w terminie. Jeśli napotykasz na swojej drodze wyzwania i potrzeby wsparcia twojego biznesu świadomie z użyciem technologii, ten podcast jest dla ciebie. Odcinek 56.

Wenderlog. Jak nie dać się zamknąć w technologicznej pułapce. Cześć, dzień dobry, witam w kolejnym odcinku podcastu IT i Biznes, w którym rozmawiamy o technologii, która naprawdę działa, czy o takiej technologii, która wspiera, a nie ogranicza.

Dzisiaj poruszymy temat może nieco mniej wygodny, ale absolutnie kluczowy, zwłaszcza dla osób, które decydują się i planują wdrożenia gotowych systemów. Jeżeli jeszcze wcześniej nie słyszałeś, bądź nie słyszałaś o Wenderlogu, czyli o sytuacji, w której okazuje się, że jesteś bardziej zależny, zależna od swojego dostawcy niż zakładałeś na początku, to ten odcinek jest dla ciebie. Nie przedłużając, serdecznie zapraszam.

Witam was serdecznie w odcinku 56. podcastu IT i Biznes i działamy dzisiaj z Wenderlogiem. Wenderlogiem, czyli sytuacją, w której okazuje się, że jesteśmy w jakimś stopniu zależni od czy to dostawcy, czy konkretnego systemu rozwiązań, co może oznaczać bardzo poważny problem i dużą odpowiedzialności ze strony biznesu.

Czym jest vendor lock?

Na czym polega dokładnie zjawisko Wenderloga? To sytuacja, w której firma często nieświadomie uzależnia się od jednego dostawcy danej technologii w takim stopniu, że odejście od niego staje się bardzo trudne, czy wręcz nierealne lub po prostu bardzo kosztowne. Taka pułapka najczęściej ujawnia się dopiero po czasie, kiedy chcemy coś zmienić, zintegrować, rozwinąć i wtedy z reguły ona wychodzi. Można to w pewnym sensie porównać np.

do zakupu samochodu, do którego dostęp do części miałby tylko jeden serwis na świecie i to z cennikiem, który sam ustala. Brzmi abstrakcyjnie? Niestety w świecie IT takie sytuacje zdarzają się częściej, niż mogłoby się wydawać.

Rodzaje vendor locków

To zjawisko może mieć różne wymiary, to jest bardzo ważne.

To znaczy może być Wenderlog np. biznesowy, czyli uzależnienie właśnie od konkretnego dostawcy usług, który trzyma w rękach wiedzę, kod lub infrastrukturę. Wenderlog technologiczny, czyli kiedy system opiera się na technologii lub architekturze, która uniemożliwia łatwe przejście do innych rozwiązań.

Wenderlog licencyjny, kiedy model licencyjny albo np. subskrypcja z autorskimi komponentami sprawia, że nie masz pełnej kontroli nad swoim rozwiązaniem lub nie możesz go wykorzystywać w jakimś stopniu. I Wenderlog procesowy, kiedy system jest tak mocno dopasowany do konkretnych procedur, że zmiana czegokolwiek w tych procedurach jest tak naprawdę niemożliwa, bo pociąga za sobą przebudowę całego modelu i szereg różnych zmian właśnie w owym systemie, które trudno się wprowadza.

Dlaczego firmy wpadają w vendor lock?

Zacznijmy od tego, że Wenderlog bardzo rzadko powstaje z dnia na dzień. W pewnym sensie jest to raczej efekt serii pozornie racjonalnych decyzji podejmowanych na różnych etapach wdrożenia. Decyzji, które w danym momencie mają sens, ale i wydają się być rozsądne biznesowe, ale dopiero z perspektywy czasu widać, jak mocno ograniczyły naszą elastyczność.

Najczęściej mówimy tutaj o takich dwóch głównych scenariuszach. Oba dość powszechne, szczególnie w przypadku gotowych pudełkowych systemów i oba pozornie bezpieczne na starcie, ale problematyczne, gdy pojawia się potrzeba rozwoju, zmiany, czy też integracji z innymi systemami.

Scenariusz 1: brak otwartości systemu

Pierwsza kwestia to brak otwartości systemu.

I to jest sytuacja, w której dostawca projektuje system w sposób zamknięty, z ograniczoną możliwością integracji z innymi narzędziami czy na przykład brakiem dostępu do kodu źródłowego. Czyli przykładem będzie to, że firma wdraża system ERP, który w teorii ma jakieś rozbudowane API, umożliwia dodawanie nowych modułów, ale w praktyce okazuje się, że API działa na przykład tylko dla jakichś części obszarów tego ERP. Moduły można dodawać, owszem, ale na przykład jako nowe zakładki, nie można nic modyfikować w istniejących już zakładkach.

I wszelkie próby integracji z zewnętrznymi narzędziami wiążą się z dodatkowymi kosztami i zaangażowaniem zespołu dostawcy. Druga sprawa tutaj jeszcze z tym związana to to, że może być też sytuacja, kiedy chcesz dodać do procesu na przykład nowy moduł raportowy, albo zintegrować jakiś moduł, system, na przykład MES z Twoim narzędziem do planowania produkcji. I teoretycznie będzie to możliwe, ale tylko przez dodatkowe, jakieś płatne, tak zwane customowe integracje z długim czasem realizacji i bez gwarancji, że będą działać w przyszłości po aktualizacji Twojego systemu.

I tutaj bardzo ważną kwestią jest to, że jeżeli taki system mamy u siebie, to musimy być po prostu świadomi jego ograniczeń takich rozwojowych i o nie już na starcie pytać podczas prezentacji tego typu systemów przez danego przedstawiciela handlowego, jakie te ograniczenia tak realnie tutaj są.

Scenariusz 2: zamknięty ekosystem produktów

I druga kwestia, drugi taki powiedzmy problem, obszar najczęściej występujący przy zjawisku vendor locka to zamknięty ekosystem produktów od jednego dostawcy. Na początku wszystko wydaje się idealnie dopasowane.

System ERP, CRM, WMS i inne moduły współpracują bez zarzutu. Jedna firma, jedna infrastruktura, jedno środowisko, wszystko wygląda okej. I problem pojawia się w momencie, gdy chcesz wymienić choćby jeden z tych elementów, albo coś w nim zmienić.

Czyli planujesz wdrożyć na przykład nowy system magazynowy, czyli tak zwany WMS, ale okazuje się, że ten obecny jest super silnie zintegrowany z ERP-em i nie bardzo da się ten nowy włączyć w miejsce tego starego. Wymiana jednego z modułów oznacza przebudowę całego układu, albo rezygnację z nowego rozwiązania. I taki model technologiczny może być wygodny w krótkim okresie, no bo ma wszystko od jednej firmy, jest dużo łatwiej, ale w dłuższej perspektywie ogranicza elastyczność organizacji i utrudnia modernizację procesów.

W obu przypadkach kończy się to tym, że firma traci możliwość samodzielnego podejmowania decyzji technologicznych. Zmiana dostawcy, rozbudowa systemu, czy nawet wdrożenie nowego narzędzia wymaga każdorazowo i zgody, i pracy, i kosztów podstawnie pierwotnego dostawcy. I co jest bardzo ważne to to, że musimy brać pod uwagę ten aspekt, w którym dany system musimy móc oddzielić od danego dostawcy.

Mam na myśli to, że przy gotowych systemach często jest tak, że one dają ci producenci tego gotowego oprogramowania, mają też np. swoich partnerów wdrożeniowych. Teraz z perspektywy biznesowej patrząc, im więcej takich partnerów wdrożeniowych jest, którzy mają jakiś dostęp do kodu źródłowego, mogą coś modyfikować w systemie, takim gotowym, tym lepiej dla nas z perspektywy vendor-lockup, bo to oznacza, że jeżeli jeden wdrożeniowiec, dostawca tego systemu nas zawiedzie, to zawsze możemy znaleźć innego.

I to jest bardzo ważna kwestia, bo często spotyka się stosunkowo nieduże firmy, które oferują swoje gotowe rozwiązania, ale bez tej siatki partnerów. No i to powoduje, że tutaj w tego vendor-lockup jako proces musimy po prostu zwyczajnie wchodzić świadomie i rozumieć, co się stanie, jeżeli będziemy chcieli wyjść z tej współpracy z jakichś różnych przyczyn.

Scenariusz 3: nadmierna customizacja systemu

I jest jeszcze trzeci scenariusz, który przychodzi mi do głowy, może mniej oczywisty, ale równie groźny.

To scenariusz, który nie zawsze jest klasycznym vendor-lockiem, ale w praktyce prowadzi do bardzo podobnych skutków. Często zaczyna się niewinnie. Wybierasz gotowe narzędzie, a sprzedawca mówi, to się da zrobić, tą funkcję dorobimy, tu przerobimy workflow, zmienimy strukturę danych i na papierze wygląda to po prostu jak dobra obsługa klienta, ale po czasie okazuje się, że twoja wersja systemu, tego gotowego wybranego jest już tak zmodyfikowana do twoich potrzeb, że nie da się jej bezboleśnie aktualizować, nie da się jej bezboleśnie rozwijać, czy też integrować z czymkolwiek innym.

Każda aktualizacja powoduje wówczas ryzyko, że coś się rozsypie, a każda nowa potrzeba kończy się kolejną customizacją, czyli taka trytytka na trytytkę czy zbiór jednego wielkiego patchworku. I teraz tutaj w tym kontekście akurat jeszcze kończąc ten wątek, bardzo ważne jest to, żeby rozumieć i mieć też taką informację i świadomość, jak będą przebiegały aktualizacje tego gotowego systemu i jak dodatki do tego systemu są budowane, różnego rodzaju moduły, jak one wpływają na podstawę tego systemu i mieć też gwarancję warto w ramach podpisanej umowy na taki gotowy system, że wszelkie aktualizacje, które będą dostępne będą też możliwe do dalszego zainstalowania mimo tych customizacji tak zwanych, o których tutaj wspominam.

Jak unikać vendor locka – 6 zasad

I skoro już wiemy czym ten vendor log może być, jak on się potrafi objawiać, jakie ryzyko niesie za sobą dla biznesu, czas odpowiedzieć sobie na najważniejsze pytanie, czy da się go uniknąć.

I dobra wiadomość jest taka, że oczywiście, że tak, ale jak zawsze zresztą wymaga to świadomych decyzji już na etapie wyboru systemu i planowania architektury. Teraz na co warto tutaj zwrócić uwagę, opowiem Wam o pięciu, sześciu jeszcze króciutkich rzeczach, ale które mogą być super ważne i super pomocne, jeżeli chodzi o wybór systemu i nie wpadnięcie w pułapkę vendor loga.

Zasada 1: Otwartość systemu i API

Pierwsza kwestia to zwracaj uwagę na otwartość systemu.

Sprawdź, czy system rozwiązania aplikacji, który wybierasz ma dobrze udokumentowane i publicznie dostępne API lub udziela Ci w ogóle dostępu do kodu źródłowego. Pewni się, że masz dostęp do danych, że możesz je odczytywać, zapisywać i czyli, że integracje z zewnętrznymi narzędziami nie są blokowane przez dostawcę lub nie wymagają też każdorazowo ingerencji jego zespołu. Tutaj bardzo chciałbym, żebyście mieli tego świadomość, że ta otwartość to nie tylko dostęp taki techniczny, ale też transparentność modelu licencyjnego kosztów rozwoju aktualizacji i brak no chyba to tak nazwę uwiązania od danego dostawcy, jeżeli będziemy chcieli coś zmienić albo dodać jakiś nowy system, nową technologię do naszego ogólnie ekosystemu architektury.

Zasada 2: Unikaj ekosystemów all-in-one

Druga sprawa. Nie pozwól się zamknąć w jednym ekosystemie. Z pozoru wygodne rozwiązania all-in-one mogą z czasem zamienić się w technologiczne więzienie w pewnym sensie.

Jeśli dostawca ma dla Ciebie wszystko, CRM-a, RP-a, WMS-a, Marketing Automation, a to wszystko jeszcze w chmurze, to zadaj sobie pytanie, czy mogę w przyszłości wymienić jeden z tych elementów bez przebudowy reszty. Wybieraj rozwiązania, które dobrze współpracują z innymi technologiami i nie wymagają rewolucji, jeśli firma w danym obszarze będzie się rozwijać lub też zmieniać.

Zasada 3: Uważaj na nadmiar customizacji

Trzecia kwestia.

Uważaj na nadmierną customizację gotowych systemów. Jeżeli każde da się zrobić oznacza pisanie kodu specjalnie pod Ciebie, to warto się zatrzymać i nad tym zastanowić. Zamiast coraz mocniej modyfikować gotowy produkt, bo zaznaczam, że to dotyczy ten punkt gotowych systemów, które kupujemy, takich nazwijmy to pudełkowych, to być może to już moment, by zastanowić się nad bardziej elastycznym, a być może nawet bardziej dedykowanym rozwiązaniem, bo często jest tak, że customizacja to jest w pewnym sensie robienie takiego remontu domu po raz kolejny, kolejny i kolejny i przebudowa do przebudowy i tu jakaś dostawka, tu coś jeszcze i czasem okazuje się, że zamiast dobudowywać w cudzysłowie kolejne piętro do domu, to tym dalej oddalamy się od pewnego standardu tego domu, z jakim on był projektowany, budowany kilka, kilkanaście lat wcześniej, tym trudniej jest później rozwijać i aktualizować taki system, czy też rozbudowywać taki dom.

Zasada 4: Konsultuj decyzje z architektem

Czwarta kwestia. Pracuj z architektem lub doradcą technologicznym już na etapie wyboru systemu. Tak naprawdę wiele błędnych decyzji bierze się czy to z pośpiechu, czy to z presji sprzedażowej.

Niezależny specjalista pomoże Ci ocenić ryzyka, przewidzieć konsekwencje wyborów i zbudować architekturę, która będzie wspierać Twój biznes, a nie go ograniczać. Spojrzenie z zewnątrz powoduje, że zwyczajnie ktoś pomija wszelkie emocje, takie pozytywne, negatywne z różnych prezentacji handlowych, skupia się na faktach i stara się na tej podstawie doradzić Ci, jakie rozwiązanie wybrać, albo przynajmniej z czym się będzie wiązał wybór danego rozwiązania, tak żebyś był lub była tego świadoma.

Zasada 5: Kontroluj kod i dane

Piąta kwestia, przedostatnia.

Dokumentuj i kontroluj własność kodu oraz danych. Jeżeli budujesz oprogramowanie tak zwane dedykowane, które powstaje specjalnie dla Ciebie, to jest super kwestia, jeżeli chodzi o właśnie zadbanie o to, żeby ten system był w pełni dopasowany do tego, jak działa Twoja firma. Natomiast, co super ważne, trzeba też tutaj zadbać o jasne ustalenia co do własności kodu i dostępów, bo to brzmi trochę formalnie, ale w sytuacjach awaryjnych, kiedy np.

będziecie chcieli zmienić dostawcę, czy taką firmę programistyczną, która oprogramowanie dla Was buduje, to właśnie te zapisy m.in. zdecydują o tym, czy będziecie mogli zmienić tego partnera technologicznego, bez utraty danych, bez zatrzymania ciągłości działania, no i też przede wszystkim, czy będziecie mogli w ogóle używać tego kodu i tego systemu, który został dla Was stworzony i w jakim stopniu. To jest też super ważne.

Zasada 6: Miej plan B

I punkt szósty, ostatni, myśl w kategoriach wyjścia awaryjnego.

Nikt nie planuje zmieniać systemu zaraz po wdrożeniu, podobnie jak umowy, podpisuje się raczej na złe czasy, ale warto mieć, tak jak w umowach stosujemy pewne zapisy, to też przy okazji realizacji wdrożenia IT, mieć pewną świadomość, jak będzie wyglądał plan B. Co się stanie, jeśli dostawca zniknie z rynku? Jak długo potrwa odzyskiwanie danych i przejście na inne narzędzie? Czy zespół wewnętrzny będzie w stanie samodzielnie utrzymać kluczowe elementy? Jak szybko możemy znaleźć nowego dostawcę i czy w ogóle ktoś może przejąć utrzymanie i rozwój tego systemu, który mamy zbudowany? Czasem nie chodzi o klasyczny vendor log, tylko o taką pozornie wygodną zależność, która w pewnym momencie przestaje być komfortowa. Dobrym przykładem jest sytuacja z pewnym dużym dostawcą oprogramowania, który jakiś czas temu, to jest oprogramowanie takie order management system dla e-commerce’u, bardzo znana firma, która jakiś czas temu wprowadziła znaczną podwyżkę opłat i przedsiębiorcy stanęli przed prostym, ale bardzo bolesnym wyborem. Zaakceptować nowe, wyższe koszty albo w pośpiechu szukać alternatywy.

Choć nie był to taki typowy vendor log, chociaż trochę był, no bo firmy mocno się uzależniły od tego konkretnego dostawcy i tego też konkretnego systemu, czyli tej e-firmy i konkretnego systemu i w sytuacji, w której ten dostawca stwierdził, że uruchamia nowy cennik, który był kilkukrotnie wyższy dla wielu przedsiębiorstw, okazuje się, że jedyną alternatywą, to znaczy jedną z opcji było oczywiście zaakceptowanie tego stanu rzeczy i zapłacenie po prostu wyższego rachunku, a drugą kwestią, taką powiedzmy alternatywną, było zwyczajnie zmienić i firmę i system. Tylko, że to wymagało migracji danych, wymagało tego, żeby zaplanować ten proces, wymagało zastanowienia się, jak to zrobić, żeby zachować ciągłość działania naszych e-commerce’ów, bo przecież zamówienia trzeba nadal przetwarzać, więc no to właśnie jest coś, co warto sobie na poziomie takiej strategii IT w ramach danego przedsiębiorstwa przepraszam, ująć po to, żeby po prostu mieć takie plany, co się wydarzy jeśli, albo być w ogóle świadomym czegoś takiego jak właśnie vendor log w danych obszarach.

Podsumowanie i zaproszenie do kontaktu

Więc podsumowując dzisiejszy odcinek, technologia powinna dawać Ci swobodę, a nie trzymać Cię w miejscu i dlatego warto stawiać na rozwiązania, które są elastyczne, dobrze udokumentowane, dają dostęp do kodu, albo przynajmniej do jakichś modyfikacji, czy możliwości kustomizacji bez konieczności robienia tego z jedną jedyną dostępną na rynku firmą, ale też pozwalają na łatwe migrowanie, integrację, czy nawet takie stopniowe uniezależnianie się od tego jednego źródła, tej jednej konkretnej firmy.

A jeśli Ty jesteś właśnie w takim momencie, gdzie czujesz, że system, z którego korzystasz zaczyna Cię bardziej ograniczać niż wspierać, albo po prostu chcesz skonsultować swoje decyzje technologiczne, albo chcesz upewnić się, że nie masz vendor loga w swoich systemach, to serdecznie zapraszam Cię do kontaktu, chętnie przeanalizuję Twoją indywidualną sytuację i doradzę Ci co zrobić. Tyle ode mnie dzisiaj, dziękuję Wam bardzo za wysłuchanie dzisiejszego odcinka i do usłyszenia za tydzień. Cześć!