Czym jest Vendor Lock-in i jak się przed nim uchronić?

Manufaktura e-commerce

Cześć. Nazywam się Michał Zabielski i od ponad 10 lat zajmuję się działaniami e-commerce na styku biznesu i technologii. W swojej karierze miałem okazję pracować zarówno z małymi sklepami internetowymi, jak i dużymi organizacjami, dzięki czemu mogę patrzeć na problemy handlu w sieci z różnych perspektyw. Podcast ten powstał, by dzielić się swoją wiedzą i doświadczeniem, jak również pomóc biznesom online mądrze i efektywnie się rozwijać. Jeśli szukasz porad i wiedzy, jak przenieść swoje działania w internecie na wyższy poziom, to to miejsce jest zdecydowanie dla ciebie.

Tytuł tego odcinka to: Czym jest Vendor Lock-in i jak się przed nim uchronić?

Cześć wszystkim. W dzisiejszym odcinku chciałem poruszyć temat, który wzbudza dość spore emocje, jeśli chodzi o obszar wdrażania, realizacji czy rozwoju platform e-commerce i generalnie w ogóle rozwiązań związanych z e-commercem. Mowa tu dokładnie o tak zwanym Vendor Lock-inie. Powiemy sobie, czym ten Vendor Lock-in jest, dlaczego w wielu wypadkach traktujemy ten temat dość stereotypowo i dlaczego traktując go stereotypowo, możemy się narazić na całkiem spore problemy.

Czym jest Vendor Lock-in?

Więc zacznijmy sobie od początku, czym ten Vendor Lock-in jest. Vendor Lock-in jest taką sytuacją, w której klient staje się na tyle silnie zależny od jakiegoś dostawcy technologii czy jakiejś usługi, że zmiana, zmiana tego dostawcy czy tego produktu na ofertę konkurencji staje się bardzo trudna, wręcz niemożliwa do zrealizowania.

Myślę, że część z was miała okazję słyszeć takie historie, gdzie znajomy czy ktoś z rynku miał taki pomysł, że zmieni sobie platformę sprzedażową, bo ta jego obecna jest strasznie uciążliwa, generuje różne problemy, a w ogóle dostawcy, którzy tę platformę obsługują, mówiąc kolokwialnie, nie dowożą.

No i bardzo często okazuje się, że jak pojawia się taki pomysł, zaczynamy sobie robić analizę rynku, to docieramy do sytuacji, w której tak naprawdę koszt przejścia do tej nowej platformy robi się, czy czy nowego rozwiązania robi się dość duży, albo okazuje się, że na rynku nie ma rozwiązań, które spełniają nasze potrzeby. Lub umowy z obecnym dostawcą są tak skonstruowane, że wręcz niemożliwe jest w jakimś takim szybkim czasie, niemożliwe jest po prostu rozwiązanie tej umowy.

Także wszyscy mówią oczywiście o tym, żeby wystrzegać się tego Vendor Lock-inu, natomiast często jest tak, że nie wiemy w ogóle, jak zorganizować sobie czy to współpracę, czy jak kupować te technologie, jak jak działać tak naprawdę na tym naszym rynku, żeby po prostu tego Vendor Lock-ina unikać.

Stereotypy dotyczące Vendor Lock-in

Poza tym istnieją takie stereotypowe sformułowania, że na przykład jeśli korzystamy z rozwiązań SaaS-owych, czyli takich w modelu subskrypcyjnym, no to w zasadzie jesteśmy uziemieni i ten Vendor Lock-in jest oczywisty, no bo ten dostawca dostarcza nam platformę, jak tylko zerwiemy abonament, no to praktycznie nie mamy platformy. Więc jesteśmy silnie uzależnieni od dostawcy, a z drugiej strony, jak zrobimy sobie rozwiązanie dedykowane, no to też jesteśmy uwiązani tym dostawcą, który wytworzył dla nas dedykowane rozwiązanie.

Więc bardzo często pojawia się w świecie e-commercowym takie stwierdzenie, że powinniśmy iść w rozwiązania Open Source, bo one są ogólnodostępne i po prostu dostosować je do swoich potrzeb, no bo to będzie najlepsze rozwiązanie problemu Vendor Lock-ina. I o tym sobie też parę słów powiemy na koniec.

Rodzaje Vendor Lock-in

Zacznijmy od tego, że tych rodzajów Vendor Lock-ina może być kilka. To znaczy my tak branżowo jesteśmy przyzwyczajeni do tego, takiego podstawowego Vendor Lock-ina, czyli uzależnienia od technologii. Ale to jest jeden z rodzajów tak naprawdę Vendor Lock-inu, czyli rodzaju uzależnienia od dostawcy bądź technologii czy usługi.

I tutaj ja wyróżniłem takie cztery tak naprawdę rodzaje Vendor Lock-inów czy uzależnienia. Pierwsze to jest właśnie uzależnienie od technologii, czyli to, które większość z nas zna i o nim sobie powiemy. Drugie to uzależnienie od produktu. Trzecie to jest uzależnienie od know-how. I czwarte to i takie najbardziej subtelne to uzależnienie od decyzyjności. I przez te uzależnienia, przez te Vendor Lock-iny sobie przejdziemy.

Uzależnienie od technologii

Pierwszy temat: uzależnienie od technologii. To jest dość oczywiste, czyli jeśli mamy jakieś rozwiązanie i ono zostało napisane w jakimś konkretnym zestawie technologii i te technologie na przykład, jak mamy rozwiązanie dedykowane, są znane tylko tym twórcom, no to pojawia się problem taki, że potrzebujemy znawców tej technologii, żeby utrzymywać czy rozwijać aktualne rozwiązanie, ale ich na rynku jest mało albo ich nie ma wcale. Czyli choćbyśmy, choćby nam nie podobała się współpraca z obecnym dostawcą, no to niewiele możemy na to poradzić, no bo po prostu nie mamy alternatywy.

Jak zabezpieczyć się przed uzależnieniem od technologii?

Jak się przed tym zabezpieczyć? No przede wszystkim powinniśmy wymagać od takiego naszego dostawcy tego, żeby on na bieżąco przekazywał nam wszelkiego rodzaju dokumentację projektową, decyzje architektoniczne, czyli wszystkie decyzje, które są podejmowane w ramach platformy, powinny mieć odwzorowanie w jakiejś dokumentacji. Dzięki temu minimalizujemy ryzyko tego, że jak będzie potrzeba przejścia na nową technologię albo do nowych dostawców, którzy tej technologii nie znają, no to będą w stanie nauczyć się z dokumentacji, jak to wszystko działa i na podstawie tego będą w stanie rozwijać platformę.

Czyli jest to takie rozwiązanie, które no nie rozwiązuje problemu tego, że jest jakaś tam krzywa uczenia dla tych nowych dostawców, ale minimalizuje czas i minimalizuje tę krzywą uczenia, żeby po prostu ułatwić wejście w tę w tę nową technologię.

Warto też znajdować sobie partnerów biznesowych takich, którzy są otwarci na takie potencjalne przejście, żeby po prostu no w sytuacjach przekazania była ta inicjatywa, czasami to można nawet zapisać w umowach, żeby ta przestrzeń na przekazanie rozwiązania też istniała i był taki okres przejściowy, gdzie ten poprzedni dostawca przekazuje wiedzę. Wtedy nie mamy tego problemu uzależniania się od technologii.

Uzależnienie od produktu

Drugi temat, czyli uzależnienie od produktu, ten ten rodzaj Vendor Lock-ina. To jest taki, takie podejście typowo typowo SaaS-owe, czyli mamy jakiś produkt, realizujemy sobie nasze działania i docieramy do momentu, że bez tego produktu nie możemy realizować naszych podstawowych działań sprzedażowych czy jakichkolwiek działań operacyjnych w naszym e-commerce.

No i to jest sytuacja, która pojawia się dość często, szczególnie u nowych graczy w świecie online, no bo bardzo często jest tak, że my chcemy zweryfikować jakąś ideę, chcemy zweryfikować rynek, więc nie tworzymy jakiś tam rozwiązań, które są dostosowane jakkolwiek do nas, tylko bierzemy jakieś rozwiązania pudełkowe, gotowe i te rozwiązania po prostu wykorzystujemy. One są dostępne najczęściej w modelu abonamentowym, no i po prostu wymagają technicznie tego, że my po prostu instalujemy to i ewentualnie wpinamy to w nasz ekosystem technologiczno-biznesowy i korzystamy z tego narzędzia.

No tutaj pojawia się ten problem, że wyjęcie takiego produktu z naszej układanki no może sprawić, że nie będziemy w stanie realizować podstawowych działań.

Jak zabezpieczyć się przed uzależnieniem od produktu?

No i znowu pytanie, jak zabezpieczyć się przed tego typu sytuacją, tak? Czyli mamy produkt i na nim mamy tak naprawdę postawione całe całe zarządzanie operacyjne czy strategiczne. No i po prostu z nim żyjemy.

No tu jest temat dość trudny, to znaczy trzeba się liczyć z tym, że po prostu jeśli będziemy chcieli zmieniać produkt, to musimy w kosztach uwzględnić koszt migracji z jednego produktu do drugiego produktu. Czyli będzie taki, będzie taki moment gdzieś tam w działaniu firmy czy działaniu organizacji, gdzie tymczasowo będą działały na przykład dwa produkty, bo ten jeden będzie wygaszany na rzecz drugiego. I to jest realna rzecz, która na pewno się wydarzy, w związku z tym trzeba na to przygotować zarówno przestrzeń czasową, żeby zrobić tę migrację, jak i przygotować na to przestrzeń kosztową, bo to będzie realny koszt. Tymczasowo będą działały dwa produkty, będzie również potrzebny potrzebny do poniesienia koszt czasowy i kosztowy takiej migracji, bo proces migracji też trwa i proces migracji wcale nie musi być prosty. Także to też trzeba mieć gdzieś z tyłu głowy na względzie.

No i oczywiście kolejna rzecz istotna, którą trzeba wziąć pod uwagę, to jest taka, że budując czy wybierając jakiś produkt do naszej organizacji, powinniśmy brać pod uwagę to, jakie on oferuje możliwości eksportu danych z takiej z takiego produktu. Czyli jeśli to jest powiedzmy, nie wiem, jakiś rozwiązanie typu PIM, czy jakiś CRM, czy jakiś produkt do newsletterów, czy marketing automation, powinniśmy sprawdzić w pierwszej kolejności, jak moglibyśmy potencjalnie wyeksportować produkty, wyeksportować dane o klientach, wyeksportować jakiekolwiek nasze dane z takiego narzędzia, żeby można było potencjalnie te dane wsadzić w inny produkt.

Czyli wszelkiego rodzaju jakieś standardowe narzędzia do do eksportu przez pliki CSV, przez Excel, przez JSON, przez takie standardowe formaty, które po prostu są znane wszystkim produktom i tak naprawdę i tak naprawdę możemy po prostu skorzystać z tego, co daje nam rynek, co jest znane i wykorzystywane jako szeroki standard w wielu produktach. Takie coś powinno być, ewentualnie czy produkt wystawia jakieś API, czyli tak zwany interfejs, tak tak zwany interfejs programistyczny, który może pozwolić na to, żeby ktoś na przykład programowo podłączył się do tego produktu, no i mógł po prostu wyciągać niezbędne informacje. To też jest to też jest jakieś rozwiązanie.

No i oczywiście tak jak mówiłem, okres przejściowy, działające dwa produkty. Z tym bym się liczył i to bym brał pod uwagę, jeśli chcemy oszczędzić sobie problemów. W szczególności, kiedy produkt na produkcie mamy postawiony jakiś kluczowy proces operacyjny czy jakiś czy jakiś element strategiczny dla nas, który jest kluczowy dla działania naszej sprzedaży czy dla działania naszego e-commerce. Także to jest to też jest jakby ten temat szalenie istotny.

Uzależnienie od know-how

Teraz przechodzimy na takie Vendor Lock-iny, które są może trochę mniej oczywiste. Uzależnienie od know-how, czyli ten Vendor Lock-in oparty o know-how. Tu chodzi o takie podejście, gdzie jesteśmy uzależnieni może nie tyle od technologii czy od produktu, co jesteśmy uzależnieni od wiedzy dostawcy czy jakieś jakiegoś konsultanta, kogoś z zewnątrz i bez tej wiedzy nie jesteśmy w stanie operować.

Chodzi o taką sytuację, gdzie na przykład zbudowaliśmy jakąś platformę, powiedzmy, że platformę B2B i ona jest na tyle skomplikowana, że tylko twórca tej platformy wie, jak ją obsługiwać, jak ją rozwijać czy jak ją utrzymywać. Czyli krótko mówiąc, jeśli z jakiegoś powodu osoba, która wytworzyła tę platformę albo ją nam dostarczyła, odchodzi z organizacji, albo my nie mamy z nią kontaktu, no to zostajemy z platformą, która co prawda teraz dla nas działa, ale ona jest kompletnie niepodatna na na zmiany, na rozwój, na jest trudna w utrzymaniu, bo nie wiemy tak naprawdę co tam zrobić, żeby żeby ona działała okej, albo jak nie daj Bóg coś się zepsuje, no to na koniec dnia platforma nie działa i nikt za bardzo nie wie, co w niej zmienić, co zmodyfikować, gdzie tutaj uderzyć, gdzie młoteczkiem, gdzie pokręcić, żeby po prostu ta platforma z powrotem działała jak należy.

I wbrew pozorom to nie jest domena rozwiązań dedykowanych czy SaaS-ów, bo w swoim w swoim doświadczeniu spotykałem się na przestrzeni lat z wieloma rozwiązaniami, które były rozwiązaniami Open Source-owymi, w których po prostu integracje czy napisane moduły były na tyle skomplikowane, całe całościowo to rozwiązanie, cały ten zlepek dedykowanych rozwiązań, modułów i tak dalej, po złożeniu był na tyle skomplikowany, że nikt nie był, no może nikt to przesada, ale bardzo trudno było wprowadzić jakiekolwiek zmiany na takiej platformie, a czasami wprowadzenie tych zmian było na tyle skomplikowane i kosztowne, że w dalekim, w długim terminie bardziej opłacało się tę platformę przepisać, zredukować i dostosować do obecnych realiów organizacji, żeby ten koszt utrzymania był niższy, no i żeby po prostu nie generować sobie większej liczby problemów.

Więc to jest taki specyficzny element uzależnienia od od know-how. I to zarówno w kontekście produktu, jeśli my na przykład instalujemy sobie produkt i korzystamy z jakiejś funkcji, która jest dla nas niezrozumiała i jednocześnie nie mieliśmy szkolenia z tego produktu, więc no po prostu nie wiemy, jak ten, jak ten obszar produktu działa. Jeśli taka osoba, która nam zainstalowała ten produkt albo go utrzymuje, odejdzie, nie mamy z nią kontaktu, zostajemy z niczym.

Jak zabezpieczyć się przed uzależnieniem od know-how?

Także uzależnienie od know-how, straszna sprawa. Natomiast sposób na uchronienie się od tego uzależnienia od know-how jest po raz kolejny dość prosty, czyli szkolenia, czyli dokumentacja, czyli komunikacja, krótko mówiąc obieg wiedzy związany z tym elementem powinien być oczywisty, powinien być ciągły i powinien być kończyć się tym, że ta dokumentacja, czy te wnioski, czy ta wiedza powinna zostać z nami, czyli być po naszej stronie, po naszej stronie jako właściciela tej technologii, nie właściciela tej technologii, tylko właściciela e-commerce, czy tam całościowej tej tej tego ekosystemu biznesowo-technologicznego, to jest nasza własność. My powinniśmy tę wiedzę pozyskać od dostawcy i powinniśmy ją utrzymywać.

To też po naszej stronie powinno być, ale i odpowiedzialnością powinno być dostawcy czy wykonawcy, żeby dostarczać nam dokumentację, dostarczać nam wiedzę i i robić to w sposób ciągły. To znaczy to, że na przykład mamy platformę B2B czy jakąś platformę sprzedażową, kończy się projekt, firma przygotowała dokumentację tej platformy i generalnie na tym się kończy zabawa, to nie jest zapewnienie ciągłości dostarczania wiedzy. Ta wiedza powinna być dostarczana w sposób ciągły, bo uwierzcie mi, na przestrzeni choćby pierwszych trzech miesięcy po wdrożeniu platformy dużo wyjdzie nowych rzeczy, dużo wyjdzie nowych tematów, których wcześniej się nie nie udało w 100% wyeksplorować, a które będą cenną wiedzą dla nas odnośnie tego, jak z platformy korzystać, jakie biznesowe przypadki szczególne potrafią się pojawić w naszej sytuacji i jak je obsługiwać bądź jak reagować na nie. To jest bardzo ważne.

Uzależnienie od decyzyjności

No i czwarty rodzaj uzależnienia, czyli Vendor Lock-ingu, Lock-inu, czyli uzależnienie od decyzyjności. I to jest taki typ takiej dość, takiego dość finezyjnego Vendor Lock-inu, który zupełnie inaczej się rozwiązuje. Mianowicie chodzi o taką sytuację, kiedy my byliśmy tak uzależnieni od wiedzy dostawcy, konsultanta, jakiegoś usługodawcy, że nie potrafimy bez niego podejmować skutecznych decyzji biznesowych.

Więc to jest taka sytuacja, gdzie na przykład mieliśmy projekt, który realizacji, niech będzie, trzymajmy się tej platformy B2B czy platformy sprzedażowej. Mieliśmy projekt realizacji platformy B2B, platformy sprzedażowej i w tym projekcie wynajęliśmy sobie do współpracy konsultanta, który miał nam pomóc w zbudowaniu działającej platformy B2B zgodnej z naszymi oczekiwaniami. Wzięliśmy sobie tego konsultanta, on bardzo ładnie poprowadził nam ten projekt, pytał się nas, wyciągał wiedzę, przekazywał ją dalej do wykonawcy. Na podstawie rekomendacji tego konsultanta podejmowaliśmy jakieś decyzje biznesowe. Projekt został zrealizowany. Konsultant stwierdził, że jego praca już na tym się zakończyła. No i idzie sobie dalej w świat.

A my my zostajemy z platformą, zostajemy z platformą, którą jest utrzymywana przez przez wykonawców tej platformy i w pewnym momencie oni mogą zadawać decyzje, zadawać pytania na temat dodatkowych integracji, na temat tego, jak głęboka ma być ta integracja, czy te integracje mają być na przykład dwukierunkowe, jakiego typu dane chcemy wymieniać między systemami. I możemy dotrzeć do sytuacji takiej, że to my teraz musimy podjąć decyzję, ale nie mamy konsultanta. Czyli bazujemy na naszej wiedzy, którą posiadamy na temat platformy.

A ponieważ konsultant cały proces wziął wcześniej na siebie, no to on ma tak naprawdę sedno wiedzy. My mamy pewne, my mamy wiedzę o tym, jak działamy jako organizacja, więc jest to jakaś nasza przewaga, ale nie wiemy, jakie decyzje projektowe czy architektoniczne były podejmowane wcześniej. Jak konsultant przełożył nasze potrzeby na konkretne rozwiązania biznesowe, na przykład na platformie. I wtedy pojawia się problem, bo wykonawca pyta się nas, jak rozwiązać jakiś problem, jak do niego podejść, a my nie wiemy. I teraz podejmujemy te decyzje w warunkach wysokiej niepewności, albo bierzemy za telefon, kontaktujemy się z konsultantem, no i oczywiście przeprowadzamy z nim jakąś konsultację i na podstawie tego działamy dalej.

Ale wiadomo, że w długim terminie może być to problematyczne. Może, ale nie musi. No bo może być tak, że zależy nam na tym, żeby z tym konsultantem po prostu działać w sposób taki ciągły. Tylko że jest to dodatkowy koszt. I dopóki jakby my to akceptujemy w ramach naszej strategii działania, no to okej. Natomiast jeśli nie chcemy oddawać pełni decyzyjności czy jakiejś sporej części decyzyjności konsultantowi, tylko jednak no na koniec dnia to jest nasza firma, więc my chcemy robić tak, jak powinno być najlepiej dla organizacji, a nie dla konsultanta, no to musimy wziąć pod uwagę to, że po prostu musimy się uniezależnić decyzyjnie od takiego dostawcy czy konsultanta.

Jak zabezpieczyć się przed uzależnieniem od decyzyjności?

Jak się chronić przed takim Vendor Lock-inem związanym z decyzyjnością? No sprawa jest tutaj znowu teoretycznie prosta, w praktyce z tym bywa różnie, czyli po prostu musimy brać udział, nawet jeśli mamy jakiegoś zewnętrznego konsultanta czy bierzemy kogoś zewnętrznego do prowadzenia projektu, musimy brać udział w podejmowaniu tych decyzji, musimy mieć wspólną decyzyjność i musimy te decyzje projektowe, czy tam różnego rodzaju biznesowe, jeśli podejmujemy te decyzje, najlepiej jest zostawić sobie upisane te decyzje wraz z uzasadnieniem, czemu takie decyzje zostały podjęte, czyli mieć taki katalog pewien decyzji projektowych czy decyzji biznesowych, które w ramach projektu podejmowaliśmy. Najlepiej z lekkim uzasadnieniem, czyli z opisaniem lekkim kontekstu i uzasadnieniem, dlaczego taka decyzja była podjęta, a nie inna.

I to wbrew pozorom może się wydawać czymś nadmiarowym, ale po pierwsze chroni nas przed tym uzależnieniem od decyzyjności, bo znowu wiedza zostaje w organizacji. A po drugie, to jest też bardzo duża skarbnica wiedzy na przyszłość, nie tylko o tym projekcie, ale w ogóle o organizacji, bo często jest tak, że wracamy historycznie do pewnych założeń, które podejmowaliśmy, albo z perspektywy czasu docieramy do jakiegoś problemu, który wcześniej w przy okazji rozwiązywania jakiejś decyzji biznesowej, technicznej, decyzji projektowej, po prostu już roz rozbijaliśmy na czynniki pierwsze, już analizowaliśmy.

Czyli krótko mówiąc, kiedyś przeprowadzaliśmy analizę tego problemu, o którym teraz rozmawiamy i na podstawie tego podjęliśmy jakąś decyzję projektową. Ona z perspektywy czasu może być słuszna, niesłuszna, to już jest rzecz trochę wtórna, ale to co jest istotne, to to, że poza decyzją możemy zobaczyć kontekst tego, jak wyglądał ten, jak wyglądała ta kwestia, którą na podstawie której potrzebowaliśmy podjęcia decyzji. I poza kontekstem możemy zobaczyć, jaki proces myślowy tam został przeprowadzony, który doprowadził do tego, że podjęliśmy taką, a nie inną decyzję. I teraz być może zmienił, zmienił nam się troszkę ten kontekst i dzięki temu, analizując tamten proces myślowy, jesteśmy w stanie po prostu podejmować inne, lepsze decyzje.

Czyli dla samodoskonalenia się organizacji to jest dobry element, a oprócz tego uniezależniamy się decyzyjnie i nie sprawiamy, że zarząd jest uzależniony od jakiegoś konsultanta, dostawcy, usługodawcy, żeby po prostu móc funkcjonować. A wbrew pozorom to nie jest wcale taka rzadka sytuacja.

Podsumowanie rodzajów Vendor Lock-in i jak się przed nimi chronić

Dobrze, czyli cztery rodzaje Vendor Lock-inu: od technologii, od produktu, od know-how i od decyzyjności. Powiedziałem wam kilka rzeczy na temat tego, jak można sobie radzić z tego typu Vendor Lock-inami i co zrobić, żeby ostatecznie ich nie mieć, bo samo w sobie sama w sobie współpraca z zewnętrznymi dostawcami jest jak najbardziej w porządku. Najważniejsze jest to, żeby nie uzależniać się od niej, czyli żeby nie było sytuacji takiej, że po prostu bez jakiejś firmy my nie możemy totalnie funkcjonować, albo nie możemy jej po prostu zmienić na inną, bo to jest taka sytuacja dość toksyczna, która może powodować różnego rodzaju dysproporcje i powodować tarcia między zespołami, no i w ogóle może powodować to zaburzenie w realizacji waszej strategii czy waszych działań operacyjnych.

Stereotypy a rzeczywistość Vendor Lock-in

Na koniec jedna uwaga, o której też wspominałem na początku, czyli czyli te stereotypy, takie stereotypowe myślenie i próba unikania tego stereotypowego myślenia czy szablonowego. Krótko mówiąc, powszechne przekonanie, że jeśli robimy rozwiązanie dedykowane, to automatycznie mamy Vendor Lock-in zagwarantowany, no bo ten dostawca robi coś dla nas dedykowanego i koniec, nie ma szans, żeby robił to ktoś inny. I tak samo Vendor Lock-in w kontekście produktów typu SaaS, Software as a Service, czyli, że jeśli korzystamy z jakiegoś produktu, no to już jesteśmy uwiązani tym produktem, wszystko zależy od tego, jak będziemy korzystać z tego produktu, co nam da dostawca i tylko to, co nam dostawca da, możemy wykorzystywać, no bo po prostu jesteśmy osadzeni w jego ekosystemie.

Tutaj od razu mówię, no i oczywiście jeszcze jedna dygresja, czyli Open Source jako rozwiązanie problemu Vendor Lock-inu, no bo przecież jak to jest Open Source, no to jest cała baza specjalistów, którzy mogą się tym zająć, no i po prostu w razie czego będziemy mogli zmienić zespół.

Otóż nie jest tak do końca, świat nie jest taki czarno-biały i z tym się trzeba liczyć, bo jak przeanalizujemy sobie te Vendor Lock-iny, o których mówiłem, to poza takimi czysto niskopoziomowymi rzeczami typu uzależnienie od technologii czy od produktu, w grę wchodzą jeszcze te uzależnienia od know-how i decyzyjności. W związku z tym może być tak, że platforma Open Source została na przykład zmodyfikowana tak bardzo, albo zawiera jakiś taki istotny element strategiczny, strategiczny element taki know-how, bez którego my nie jesteśmy w stanie poprawnie działać z naszą platformą.

I tu mogę podać przykład, mieliśmy takiego jednego klienta, który przyszedł do nas z działającą jego platformą napisaną na Open Source, na Magento, i problem ten dostawca miał taki, że od wielu, wielu miesięcy jego platforma nie działała tak jak powinna, a wynikało to z tego, że poprzedni dostawca napisał integrację z systemem zewnętrznym tak specyficznie i to było tak mocno powiązane z tym know-how, które wypracowali, że wiele poprzednich agencji po prostu nie było w stanie poprawić tej integracji i jej odpowiednio rozbudować.

Nam się to udało, ale to wynikało oczywiście z tego, że że byliśmy w stanie to dość intensywnie i dogłębnie przeanalizować, oraz mieliśmy spore doświadczenie po prostu z tą platformą, co nie oznacza, że musiało to się tak skończyć, że tamte poprzednie agencje nie mogły tego rozwiązać, bo gdyby przekazanie wiedzy było tutaj odpowiednie, to tak naprawdę myślę, że każda inna agencja byłaby w stanie po prostu to dalej rozwijać. Ale widzicie, Open Source, teoretycznie sytuacja, w której nie powinniśmy w ogóle martwić się o Vendor Lock-in, no niestety ten Vendor Lock-in na poziomie know-how doprowadził do tego, że przez długi, długi czas nie można było znaleźć tak naprawdę zamiennika czy alternatywnej alternatywnej agencji do utrzymywania i rozwoju platformy.

Także to jest taka rzecz. Tak samo rozwiązanie dedykowane. Przy rozwiązaniach dedykowanych ludzie mówią, że jest ten Vendor Lock-in już z definicji i ten dostawca już na całe życie jest uwiązany z z wybraną firmą. No, jeśli weźmiemy pod uwagę obecny stan rozwiązań czy narzędzi AI, to tutaj sytuacja ulega już diametralnej zmianie, bo tak naprawdę nic nie stoi na przeszkodzie, żeby rozwiązania z zakresu sztucznej inteligencji przeanalizowały całą bazę kodu, przeanalizowały to, jak to działa i były w stanie wspomóc nową agencję czy nowy zespół w rozwoju tej platformy. A z kolei, gdybyśmy mieli całą dokumentację na bieżąco rozwijaną i utrzymywaną, to tak naprawdę znowu nowa agencja może wejść na rozwiązanie dedykowane, zapoznać się z dokumentacją i śmiało może tego typu narzędzie rozwijać. I wtedy okaże się, że na przykład rozwiązania dedykowane, paradoksalnie, wcale nie nie prowadzą do Vendor Lock-inu, a prowadzą do tego, że mamy idealnie skrojone na miarę rozwiązanie pod nasz biznes, pod nasze procesy i nasze potrzeby, a po prostu jak jest potrzebna nowa agencja, to trzeba wziąć pod uwagę ewentualnie dodatkowy koszt tego, że proces przekazania i nauczenia się platformy będzie troszeczkę dłuższy niż przy rozwiązaniach ogólnodostępnych.

Także to jest istotna rzecz i to jest ta informacja, z którą was zostawiam. Nie patrzcie na Vendor Lock-in w kontekście schematów, że jak SaaS to Vendor Lock-in, jak dedyk to Vendor Lock-in, jak Open Source to nie Vendor Lock-in, tylko sprawdźcie swój konkretny przypadek, osadźcie to w kontekście agencji czy produktów, z których korzystacie i wtedy zastanawiajcie się, czy faktycznie macie do czynienia z sytuacją, gdzie potencjalnie jesteście narażeni na Vendor Lock-in. I mówię to mimo tego, że w większości wypadków my realizujemy rozwiązania czy wdrożenia w oparciu o platformy Open Source-owe. Także to też nie jest tak, że że ten mój punkt widzenia jest jakoś tam skrzywiony, nie wiem, próbuję was namawiać do tego, że Open Source jest najlepszy. Nie zawsze jest najlepszy, ale właśnie dlatego, że nie zawsze jest najlepszy, to warto po prostu świadomie podejść do procesu wyboru jakiejś technologii, rozwiązania, a nie takiej ślepej klasyfikacji, która po prostu może doprowadzić do tego, że bez sensu albo przepalicie jakieś budżety, albo wybierzecie rozwiązanie, które kompletnie jest nieadekwatne do waszych potrzeb i będzie to generować po prostu tylko i wyłącznie problemy w dalszym etapie utrzymywania i rozwoju.

Tyle ode mnie, jeśli chodzi o Vendor Lock-in. Mam nadzieję, że troszeczkę wam nakreśliłem kontekst tego, jak można podejść do tematu i jak rozwiązywać go w waszym kontekście, tak żeby problem u was nie wystąpił i żebyście mogli swobodnie rozwijać sobie swoje działania e-commerce zarówno na poziomie takim operacyjnym, jak i technologicznym, jak i biznesowym.

Jeśli wiecie, że ktoś mierzy się z tego typu problemem, to zachęcam was do podzielenia się odcinkiem, jak również zachęcam do subskrybowania kanału po więcej wiedzy związanej z e-commercem zarówno B2B, jak i B2C. Na dziś to wszystko. Zapraszam was do następnych odcinków. Powodzenia w waszych, w rozwoju waszych e-commerców. Cześć.