Vendor lock-in w e-commerce: jak rozpoznać uzależnienie od dostawcy i odzyskać kontrolę

Wyobraź sobie, że chcesz zmienić w firmie system albo dostawcę, agencję albo dodać nową funkcję, której potrzebują twoi klienci i nagle słyszysz: „Nie da się, nie da się, bo wasz ERP jest tak zbudowany z tylu różnych modułów, że nikt nie chce tego dotknąć, żeby nic nie zepsuć. Nie da się, bo OMS jest jednocześnie magazynem, PIM-em i posiada tysiąc automatyzacji i też każdy boi się tego dotknąć. Nie da się, bo tylko agencja, właściwie jedna agencja zna ten system, a nie ma do niego dokumentacji. Nie da się, bo cała technologia w firmie jest zamknięta u jednego dostawcy”.

 

I teraz pojawia się to najważniejsze pytanie. Co jeśli twoja firma jest zablokowana? Co jeśli jest w tak zwanym vendor lock-in, a ty nawet o tym nie wiesz?

 

Dzisiaj opowiem o tym, czym jest vendor lock-in. Po ludzku, bez takiego technologicznego bełkotu. Jakie są najczęstsze przypadki tego typu blokad? Skąd się bierze uzależnienie od jednego dostawcy lub od jednego systemu czasem? Jakie niesie to konsekwencje dla rozwoju twojej firmy? Co możesz zrobić, żeby odzyskać kontrolę i wolność technologiczną? De facto to nie będzie odcinek o technologii, chociaż tak może się wydawać. To będzie odcinek o bezpieczeństwie twojego biznesu.

 

Vendor lock-in = uzależnienie od jednego dostawcy

 

 

Na początek powiedzmy sobie o tym, czym w ogóle jest vendor lock-in, czyli zablokowanie twojego biznesu. Jak sama nazwa wskazuje, vendor to dostawca, a lock-in to zamknięcie się w czymś. Możesz być zamknięty z wieloma systemami u jednego dostawcy. Możesz być też zamknięty w jednym systemie. W dalszej części tego odcinka opowiem o kilku przypadkach takich najbardziej charakterystycznych i najczęściej powtarzalnych, które występują właśnie w vendor lock-in, w tym jak firmy blokują de facto możliwości własnego rozwoju w zakresie technologii. A ta technologia, nie oszukujmy się, już dzisiaj utrzymuje całe biznesy, bo one są osadzone na technologii i de facto funkcjonują często tylko i wyłącznie dzięki technologii.

 

W tym momencie wyjaśnię, co to dokładnie jest, kiedy powstaje i dlaczego to jest naturalny skutek, naturalne konsekwencje działań i złych decyzji biznesu, niekoniecznie złej woli dostawców.

 

Vendor lock-in to jest pułapka, która nie powstaje z dnia na dzień. To jest coś, co buduje się latami. Dlatego łatwo można to przegapić, ponieważ buduje się to po kawałeczku i nie jest tak wyraziście dostrzegalne na żadnym z etapów, w którym wprowadzasz do swojej firmy kolejne narzędzia technologiczne. Więc tak jak już na początku powiedziałam, vendor lock-in to uzależnienie się od jednego systemu lub jednego dostawcy. Bez niego, bez tego systemu albo dostawcy, firma po prostu staje. Firma nie będzie funkcjonowała. Nie można dokonać zmian, nie można dokonać integracji, migracji.

 

De facto nie możesz albo możesz, ale boisz się sam ruszyć czegokolwiek, czy ty sam jak masz wewnętrzny zespół, czy jakaś zewnętrzna agencja, bo jeśli coś jest zrobione w sposób customowy, jeżeli to jest trochę taki Frankenstein, gdzie dolepialiście kolejne kawałki i nie ma do tego dokumentacji, więc ta wiedza jest w sumie tylko w kodzie i w głowach osób, które ten kod pisały, to nikt z zewnątrz nie będzie się chciał tego dotknąć i, za przeproszeniem, dłubać w tym systemie, szczególnie jeżeli na tym systemie stoi dosyć spory kawałek twojego biznesu i chodzi o duże pieniądze. Najczęściej będzie tak, że agencja powie ci, że trzeba to kolokwialnie mówiąc zaorać i zrobić od nowa i już zrobić to w zgodzie z nową architekturą technologiczną i strategią technologiczną.

 

Więc często skutek jest taki, że niestety nie da się tego kontynuować. I teraz jeżeli to są duże systemy, to też, że tak powiem, trzeba odważnego, który przyjdzie i powie, że teraz będziemy to zmieniać, będziemy to pisać od nowa, podczas kiedy na całą tę infrastrukturę wcześniej zostały wydane grube miliony. O ile jeszcze nie są to duże pieniądze, to to tak bardzo nie boli i łatwiej podjąć taką decyzję. O ile wchodzimy już w duże pieniądze, w duże systemy, w wiele procesów, które te systemy obsługują, o tyle dużo trudniej z takiej sytuacji wyjść. I to jest właśnie to uzależnienie, to jest ta blokada de facto, bo oczywiście jak to mówimy, zawsze jest jakiś wybór, tylko ktoś się też pod tym wyborem musi podpisać, a to nie jest wcale łatwe, żeby podjąć taką decyzję w imieniu firmy. Czy te decyzje podejmuje jej właściciel, czy te decyzje podejmuje dyrektor, to w żadnym z tych przypadków nie jest łatwa decyzja.

 

Więc vendor lock-in to trochę można powiedzieć taka sytuacja, jakby zamknąć całą firmę w jednym pokoju i wyrzucić do niego klucz. Nie ma dostępu, nie da się nic zrobić, nie da się nic zmienić i trzeba trwać już w tym, co jest. To jest niewygodne, to nastręcza dużo problemów. To jest też na koniec dnia po prostu bardzo kosztowne.

 

 

Jak rozpoznać vendor lock-in?

 

 

A teraz spójrzmy na to trochę z innej strony. To znaczy jak masz rozpoznać, czy w sumie ten vendor lock-in występuje w twojej firmie, czy to się u was zadziało, bo być może jeszcze nie jesteś w takiej sytuacji. Teraz jakie są symptomy tego, że już wkroczyliście na te niebezpieczne wody i jesteście albo wchodzicie, jesteście na tej ścieżce wejścia w vendor lock-in.

 

Podstawowe symptomy to takie, że na przykład nie możesz zmienić dostawcy, bo system jest zbyt specyficzny. To znaczy żaden dostawca nie będzie w stanie przejąć i kontynuować bardzo mocno customowego rozwiązania. Jeśli znasz, trochę się interesujesz w ogóle na przykład językiem polskim, to wiesz, że w języku polskim da się powiedzieć wiele rzeczy o bardzo podobnym znaczeniu na dziesięć na przykład różnych sposobów. I trochę tak jest z kodem programistycznym. To znaczy pewne rzeczy da się zrobić i będą działać na wiele różnych sposobów i to zależy w dużej mierze od zespołu programistycznego, od architekta, który układa to, jak ten system będzie wyglądał, działał. Mówię tak bardzo kolokwialnym językiem, żeby nie wchodzić w szczegóły, ale to bardzo mocno można skustomizować i potem jeśli ten kod nie jest, nazwijmy to kolokwialnie, czysty, jeżeli nie jest dobrze opisany, jeżeli nie ma do tego dokumentacji, a jest to bardzo customowe, czyli dedykowane rozwiązanie, to jest bardzo trudno komukolwiek, czy to wewnętrznie u ciebie w firmie, czy zewnętrznej agencji wejść i cokolwiek robić w tym systemie. Nie mówię o konfiguracji, mówię o zmianach programistycznych.

 

Kolejna rzecz, jeżeli na przykład integracje są też customowe, są, że tak powiem, zabetonowane i boicie się wręcz ruszyć czegokolwiek, bo to może skutkować tym, że coś przestanie działać, że jakieś duże procesy po prostu przestaną funkcjonować i się zawalą. I im więcej systemów tak naprawdę jest integrowanych w firmie, tym większe ryzyko. Dlaczego? Bo poszczególne działania, poszczególne elementy jakiegoś większego procesu możesz zrobić oczywiście w tych poszczególnych systemach, ale na co dzień to nie jest tak, że na przykład pracownicy obsługują zamówienia w platformie B2B, tylko obsługują je na przykład w OMS-ie, obsługują je w ERP-ie. Jeżeli integracja przestanie działać i te zamówienia nie będą przechodzić do OMS-a, nie będą przechodzić do ERP-a, to się okaże, że nagle ktoś musi się zalogować do tej platformy, do CMS-a, do tego panelu zarządczego i tam zarządzać tymi zamówieniami.

 

Może się okazać, że masz duże problemy z rezerwacjami i dostępnością swoich produktów na przykład na marketplace’ach. Bo skoro informacje nie docierają do OMS-a, który aktualizuje stany magazynowe na wiele różnych kanałów sprzedaży, to te stany, pomimo tego, że w platformie na przykład ktoś kupuje i tych stanów ubywa, to te stany w OMS-ie cały czas są takie same, bo się też nie zmieniają w ERP-ie, bo nie ma tej komunikacji. Ta komunikacja jest zerwana, jest uszkodzona.

 

Więc w integracjach, jeżeli jest ich dużo i jeżeli nie bazujemy na jakichś standardowych rozwiązaniach, na API, tylko wszystko jest customowe i również bez jakiejś dokumentacji i każdy już wiele lat temu było to zrobione i każdy boi się wręcz tego dotknąć, to może się okazać, że to jest właśnie kolejny bloker i to jest kolejny problem.

 

Jeżeli każda zmiana w systemie, z którego korzystasz, to jest oczekiwanie wiele miesięcy na to, żeby ją wykonać i bardzo duży koszt, żeby wykonać tę zmianę, bo system ma tak rozbudowaną i dużą architekturę albo jesteś na jakiejś dużej platformie SaaS-owej na przykład, że dostawca może mieć duży problem z tym, żeby twoje indywidualne, jakieś dedykowane funkcjonalności wpasować w całą platformę i wtedy być może trzeba podejść do tego w inny sposób, na przykład wydzielić twoje konto na osobną instancję i tam dopiero dokonywać tych dedykowanych zmian. To też pociąga za sobą dodatkowe koszty również tej dodatkowej instancji.

 

Przypadki są różne, to jest jeden z przykładów. Natomiast przypadki są bardzo różne i też to, że czekasz długo i musisz za to dużo zapłacić, też może cię zblokować biznesowo, bo na przykład zmiana jest potrzebna tuż przed sezonem albo jest tak mocno wyczekiwana przez klientów, bo pewne rzeczy budzą ogromną frustrację i chciałbyś to zmienić i dostarczyć szybko, a okazuje się, że musisz czekać rok i jeszcze bardzo dużo za to zapłacić. Czy to jest taka formalna, stricte blokada? Formalnie nie, bo jednak jest ta możliwość do robienia czegoś i ktoś ci to zrobi, ale biznesowo jest już blokada. Już w taki sposób, jeżeli to działa, to masz biznesową blokadę i możesz to mocno odczuć.

 

Jeżeli tylko jeden dostawca zna twój system, bo właśnie jest on jakiś customowy albo jest on SaaS-owy albo tak zwany SaaS Enterprise, czyli jakaś duża część systemu jest wspólna dla wszystkich firm, jakiś taki core, podstawa jest taka sama, ale do tego firma działa projektowo w ramach tego enterprise, działa projektowo i może dorobić pewne rzeczy, zmodyfikować w tym core pewne rzeczy pod ciebie, to się może okazać, że tylko wąska grupa osób zna tak naprawdę ten system od tej strony technologicznej i jest w stanie cokolwiek w nim zrobić i zmodyfikować.

 

Jeżeli twoja architektura to jest trochę zlepek takich różnych systemów, ale też różnych modułów przy systemach. Często są takie moduły, na przykład przy platformach open source, moduły przy ERP-ach i te moduły pochodzą od różnych agencji, czyli były pisane przez różne firmy w różny sposób, dostosowywane do danego ERP-a albo na przykład platformy też w różnym zakresie, to może się okazać, że stworzyliście takiego Frankensteina. Znam przypadki, gdzie firma miała tak dużo dodatków na przykład do ERP-a, że już sami nie wiedzieli de facto, ile tych dodatków jest. A po audycie okazało się, że wiele osób nie pamięta już nawet, że niektóre z tych dodatków są zintegrowane z tym ERP-em, bo nikt z nich nie korzysta, a nadal są zintegrowane, nadal mogą powodować problemy, nadal mogą się okazać niekompatybilne z jakąś wersją systemu i poblokować inne rzeczy. A ty już nawet nie pamiętasz, że je tam masz. Więc dokopanie się czasem też do tego, co tak naprawdę masz de facto w firmie i na ile cię to może przeszkadzać, na ile cię to może blokować, też jest procesem, na który warto zwrócić uwagę.

 

Kolejny symptom. Jeżeli wszystko trzyma się na ERP-ie, bo ERP jest pępkiem świata w twojej firmie i wszystko jest na zasadzie headless, ale dla wszystkich procesów, dla wszystkich systemów punktem wyjściowym jest ERP, to też jest niebezpieczna sytuacja, ponieważ ERP jest systemem dziedzinowym do pewnego zakresu procesów magazynowych, logistycznych, księgowych czasem, w zależności jak ułożysz to w swojej firmie. Ale to nie jest PIM, to nie jest system, do którego warto dobudowywać jakąś dedykowaną platformę B2B na przykład. Więc to zależy mocno od sytuacji, ale jeżeli ERP jest źródłem wszystkiego, jest podstawą wszystkiego, jest tym pępkiem świata w twojej firmie i bez tego ERP-a nie da się obejść, to później, jeżeli chciałbyś wymienić tego ERP-a, to się okazuje, że tracisz fundament, jakiś ogromny duży klocek z tej układanki, na którym stoi cała reszta. W tym przypadku trudniej podjąć decyzję i ryzyko tej decyzji jest dużo większe.

 

Kolejna rzecz to na przykład migracje. Jeżeli już decydujesz się na zmianę, to jednym z elementów takiej zmiany systemu, wymiany na inny system jest migracja danych. Jeżeli nie wiemy, nie mamy dokumentacji, nie wiemy dokładnie, jak coś zostało zrobione, to migracja też staje się bardzo ryzykowna. I oczywiście tu nie ma blokerów technologicznych, to znaczy da się ją zrobić, tylko to są znów miesiące analizowania, miesiące sprawdzania, przygotowywania się. To jest ogromne ryzyko biznesowe, ryzyko decyzji, którą ma podjąć konkretna osoba i często kończy się na tym, że takich zmian i takich migracji nie ma. Czyli tkwicie w czymś, co nie jest już dla was dobre, nie jest wystarczające, dlatego że boicie się, że te wszystkie elementy tej układanki się po prostu posypią i będzie jeszcze gorzej za chwilę niż jest dzisiaj, pomimo że dzisiaj nie jest dobrze. I to też jest bloker.

 

Ostatnia sytuacja, najbardziej taka już wprost, że jesteś w tym vendor lock-in, to jest sytuacja wynikająca z na przykład zapisów prawnych, o których mówiłam w poprzednim odcinku. I sytuacja taka, że to dostawca dyktuje ci warunki. Dyktuje ci warunki co do korzystania z tego systemu, co do płatności za ten system. Wtedy to już jest taka największa realna blokada, że nie możesz pójść własną drogą i nie możesz zrobić wiele w swoim systemie.

 

Jeśli któryś z tych symptomów występuje u ciebie, jeśli jest to zauważalne już na tym etapie, to jest to dobry moment, żeby coś z tym zrobić. Mam nadzieję, że tych symptomów, jeśli zauważyliście, to zauważyliście ich jak najmniej. Bo im mniej, tym lepiej. Zwróćcie na to uwagę. Spróbujcie to prostować delikatnie, krok po kroku. O tym jeszcze za chwilę będę opowiadać, jak podejść do tego, żeby wyjść z takiej sytuacji. Natomiast im mniej tych symptomów zauważyliście, tym lepiej dla was. Im więcej, tym trochę gorzej, ale też warto się tym tematem zainteresować i spróbować te sytuacje naprawić.

 

 

Najczęstsze przykłady vendor lock-in

 

Teraz przejdziemy do przykładów. Obiecałam na początku, że opowiem o kilku najczęstszych, najbardziej charakterystycznych przykładach tego, kiedy występuje w firmach vendor lock-in.

 

Pierwszy przykład to ERP jako centrum wszechświata, jako centrum twojej firmy. Jeżeli wszystko robi się w ERP-ie, jeżeli do tego ERP-a, żeby wszystko było właśnie na nim, dobudowujesz poszczególne moduły. Wszystko jest jakimś modułem do ERP-a. Albo dostawiasz sobie na przykład e-commerce jako taki kolejny frontend do ERP-a, tylko taki prosty system, żeby coś wystawić na zewnątrz do klienta, żeby mógł złożyć zamówienie, ale i tak całe serce i dusza tkwi w tym ERP-ie. Jeżeli nie masz do tego dokumentacji, bo się tworzy na bieżąco, to wszyscy przecież wiedzą, do czego to służy, do czego to jest, po co ta dokumentacja, papier na półkę, dużo czasu, dodatkowy koszt, więc nie ma sensu.

 

Jeżeli w pewnym momencie dochodzisz już do tego, że dostosowujesz swoje procesy do tego, co jest w ERP-ie, co ten ERP może, na co on pozwala, a nie odwrotnie, czyli nie masz już tej elastyczności tego rozwiązania, tylko dochodzisz w wielu miejscach do ściany, to też jest coś, co powinno cię zaalarmować, że jest już nie tak. Więc jeśli ten ERP jest w twojej firmie pępkiem świata, jest systemem do wszystkiego de facto i na bazie tego ERP-a dobudowywana jest cała reszta funkcjonalności, modułów, aplikacji niezintegrowanych z ERP-em, ale także działających na bazie ERP-a, stojących na tym ERP-ie i są od niego uzależnione, to jest to jeden z elementów, jeden z przypadków właśnie takiej blokady działania.

 

Wymienienie czegokolwiek w takim przypadku jest trudne, jest kosztowne, bo wymaga dużo większej liczby zmian niż byłoby to w sytuacji, kiedy miałbyś systemy dziedzinowe tak zwane, czyli każdy system dedykowany konkretnym działaniom, konkretnemu procesowi. Wtedy byłoby to łatwiejsze, bo wymieniasz klocek do klocka. A w tym momencie, kiedy to jest elementem jakiegoś monolitu, jakiejś większej całości, jest to dużo trudniej wyjąć. Musisz budować po prostu cały system. Musisz podchodzić do tego od nowa, jakby do nowego wdrożenia. Więc nie zalecam tego, żeby budować to w taki sposób.

 

Drugi przypadek. Oprócz ERP-a często widać, że w OMS-ie ludzie też budują dużo różnych rzeczy, które w OMS-ie stricte znaleźć się nie powinny albo powinny być przynajmniej w jakimś szczątkowym zakresie. O czym mówię? Jeśli OMS w twojej firmie trochę udaje PIM-a, udaje magazyn, ma tysiąc automatyzacji i różnych workflow, które tam funkcjonują, to też jest ryzyko, dlatego że masz bardzo dużo rzeczy w jednym systemie.

 

I tu wrócę do tego, co powiedziałam o tym częściowym wykorzystaniu, bo oczywiście OMS potrzebuje informacji magazynowej, jakie ma stany, żeby je przekazywać do różnych kanałów sprzedaży i powinien taką funkcjonalność mieć, ale to jest tylko informacja o stanie magazynowym. Natomiast zarządzanie magazynem to coś więcej. To są też dokumenty zakupu. To są różne strategie ustalania cen od tej ceny zakupu. To są różne algorytmy, które mówią nam o tym, kiedy mamy optymalny stan zapasu, kiedy powinniśmy wygenerować nowe zamówienia. One mogą obsługiwać też kanał stacjonarny, informować pracowników na przykład o tym, że cena się zmieniła i że trzeba nowe metki, nowe kody kreskowe dać na produkty, bo mamy zmianę cen i tak dalej. Czyli samo zarządzanie magazynem to nie jest tylko przechowywanie stanu magazynowego. I to mam właśnie na myśli, mówiąc, że częściowo pewne systemy posiadają jakieś funkcjonalności, ale to nie jest pełna funkcjonalność do zarządzania danym obszarem w firmie.

 

Podobnie jest z platformą B2B i kartoteką produktową. Czy platforma B2B może służyć do zarządzania kartoteką produktową? I tak, i nie. Tak, jeśli masz niewiele produktów i ta informacja produktowa jest uboga, to znaczy nie potrzeba kontrahentom za dużo informacji produktowej. A są takie przypadki. Pisałam o tym w artykule i na moim blogu znajdziesz więcej informacji, a link do tego artykułu zostawię w opisie odcinka, więc możecie sobie doczytać tam więcej.

 

Natomiast są takie przypadki, że tej informacji produktowej nie trzeba aż tak dużo i wtedy rzeczywiście można tą kartoteką produktową zarządzać w platformie B2B. Ale jeśli masz tych produktów w tysiącach, milionach, bo tak też bywa, i sprzedajesz na przykład na wiele rynków, czyli w różnych językach potrzebujesz tej informacji produktowej, albo też w różnych kanałach sprzedaży, gdzie pod każdy kanał inaczej wystawia się ofertę i potrzebny jest inny zakres danych, w inny sposób jest w ogóle konstruowany na przykład opis w takiej ofercie, wtedy nagle to się wszystko multiplikuje i z miliona produktów może się okazać, że masz nagle trzynaście milionów produktów, jeżeli weźmiemy pod uwagę inne rynki i kanały sprzedaży. I w takim przypadku już platforma B2B to nie jest miejsce do zarządzania informacją produktową. To po prostu przestaje być wystarczalne.

 

Więc to mam na myśli, kiedy mówię, że częściowo oczywiście pewien zakres może się powielać w różnych systemach, bo ERP też ma kartotekę produktową, ale ma tam indeks EAN, cenę, dostępność i kilka jakichś podstawowych rzeczy i nazwę w dodatku nie e-commerce’ową, tylko nazwę producencką i to też jest kartoteka produktowa. W platformie będzie mniej danych, też będzie kartoteka produktowa, ale dopiero w PIM-ie masz zarządzanie informacją produktową. Więc właśnie o tym mówię, żeby nie zastępować systemów dziedzinowych i nie budować jakiegoś monolitu.

 

Najgorzej, najmocniej przekonali się o tym użytkownicy jednego chyba z najbardziej popularnych OMS-ów dominującego na rynku, którzy z racji tego, że nie było konkurencji, bo też firma dominowała niską ceną i po prostu pozostałym firmom nie opłacało się rozbudowywać tych systemów i konkurować, nie byliby wtedy w ogóle konkurencyjni. To właśnie w tym OMS-ie firmy pobudowały bardzo dużo różnych automatyzacji, różnych specyficznych procesów, systemów krok po kroku, rok po roku, dobudowując następne rzeczy.

 

A później, kiedy nastąpiła podwyżka cen, okazało się, że nie są w stanie przenieść tych procesów i tego, co zrobili, do innego systemu, bo po prostu żaden system nie ma tego jeden do jednego. Żaden system nie ma też tego nawet chociażby w pięćdziesięciu, sześćdziesięciu procentach, co oni tam zrobili. I stało się to bardzo trudne i niestety przy bardzo rozbudowanej skali, wielu procesach, wielu takich automatyzacjach, co pozostało? Pozostało zostać i płacić.

 

W wielu przypadkach to jest nadal opłacalne i ta zmiana nie ma sensu, ale dla wielu firm to był początek zmiany, upraszczania procesów i szukania narzędzia, i dobudowywania na własną rękę nawet w tych narzędziach konkurencyjnych elementów, które są im newralgiczne, a resztę po prostu musieli usuwać. Bardzo duża zmiana dla organizacji w bardzo krótkim czasie, ryzykowne i kosztowne, więc to też jest element, który pokazuje nam, żebyśmy nie budowali trochę takiego potworka technologicznego, ponieważ na początku może być fajnie, może nam się wydawać, że to jest super rozwiązanie, ale później dojdziemy jednak do ściany. No i okaże się, że to ryzyko, które sobie zbudowaliśmy, jest bardzo duże i bardzo kosztowne.

 

Inna sytuacja to można powiedzieć takie one stop shop u jednego dostawcy. Zaczynamy na przykład, najczęściej się tak dzieje, że zaczynamy od ERPA albo od jakiejś aplikacji. No i potem się okazuje, że ten dostawca może zrobić jeszcze platformę e-commerce, że ma jeszcze CRMA, że może zrobić aplikacje dla handlowców, że robi też integrację, że może zrobić tam jakąś aplikację do planowania tras na przykład w logistyce. I po pewnym czasie okazuje się, że masz wszystkie systemy u jednego dostawcy, a twoja faktura z kilku tysięcy opiewa już na kilkadziesiąt tysięcy miesięcznie.

 

Zazwyczaj wtedy pierwsza budzi się księgowość właśnie, widząc zmiany w tych fakturach, i zaczyna drążyć temat, co się takiego wydarzyło, że ta faktura tak, no można powiedzieć, drastycznie wzrosła na przestrzeni lat, tak że temu dostawcy płacimy coraz więcej, i wtedy okazuje się, że tak naprawdę wszystko masz u jednego dostawcy, że jesteś całkowicie uzależniony od jednej firmy technologicznej, która wyposażyła cię we wszystko. Dla tej firmy technologicznej to jest dobra sytuacja, dlatego że im więcej klient weźmie od jednej firmy rozwiązań, no tym bardziej właśnie jest uzależniony i tym trudniej jest mu wyjść. Czyli będzie to klient bardziej lojalny, klient, który będzie dłużej trwał z danym dostawcą, no i płacił faktury.

 

Więc dla dostawcy sytuacja jest wygodna. Natomiast dla ciebie na początku też się wydaje tak, no bo przecież ten dostawca, jak już zrobił nam ERPA, no to tak dobrze zna nasz biznes, nasze produkty, to zrobi też resztę. Ta cała reszta nie zawsze wygląda tak dobrze i nie zawsze właśnie spełnia do końca swoje funkcje, bo może się okazać, że ten dostawca specjalizuje się na przykład w ERP-ach i ten ERP jest super, jest świetny, natomiast pozostałe rzeczy dorobił właśnie po to, żeby cię jeszcze bardziej zaangażować i uzależnić od siebie, ale no te rzeczy nie są tak, te pozostałe systemy nie są jego core’ową działalnością i nie za bardzo się na tym też zna. Nie za bardzo chce te systemy rozwijać, bo będzie rozwijał to, co jest core’ową, czyli główną działalnością jego firmy, czyli ERPA na przykład.

 

I może się okazać, że jeden system masz super, a te pozostałe no taka średnia rynkowa albo poniżej. Tak. I w tej sytuacji też trudno jest wyjść, bo jak już masz porobione wewnątrz integracje, tak, dedykowane integracje, to jest trudno z tego wyjść, pomimo że możesz mieć systemy dziedzinowe, czyli możesz mieć ładnie różne klocki w jednej układance. Jeżeli będzie trudno wyjść, bo będzie brak alternatyw, tak, w którymś z systemów, to może się okazać, że kilka klocków wymienisz, ale jakiś newralgiczny nadal będzie musiał zostać u tego dostawcy, a dostawca, wiedząc o tym, że nie jesteś w stanie przejść do konkurencji, może windować wyższą cenę. Więc wraz z tym uzależnieniem cena może być podnoszona i de facto no zgodzisz się na nią, bo po prostu nie będziesz mieć wyjścia. Tak, to jest taka sytuacja.

 

To zawsze to uzależnienie jest na początku wygodne, ale w dłuższej perspektywie czasowej zawsze bardziej boli i więcej kosztuje, więc tutaj należałoby się nad tym zastanowić.

 

I kolejny przypadek to dedykowane systemy, platformy tam, gdzie one nie są potrzebne. W swoim to już dosyć długim okresie, kiedy zajmuję się i e-commerce, i technologią, wprowadzam je do różnych firm, bądź też pracowałam po stronie dostawcy i rozwijałam takie oprogramowania, testowałam wiele różnych oprogramowań. Raz w sumie spotkałam, tylko raz spotkałam się z takim przypadkiem, gdzie naprawdę najlepszym rozwiązaniem było zbudowanie dedykowanej platformy i podczas rozmów, podczas warsztatów z klientem, gdzie dostałam też dostępy do obecnej platformy, zobaczyłam, jak to funkcjonuje, przeanalizowaliśmy wszystko i przeanalizowaliśmy to, co możemy jako dostawca zrobić, bo wtedy pracowałam po stronie dostawcy, oraz to, czego nie zrobimy, bo to jest produkt SaaS i kompletnie to nie jest w ramach w ogóle ścieżki rozwojowej tego produktu. To jest już typowo dedykowana rzecz, którą najlepiej jakby zrealizowała jakaś inna agencja. Możemy to zintegrować. Wiele było takich rzeczy specyficznych, naprawdę mocno specyficznych, nawet w takich podstawowych elementach struktury i tej architektury platformy B2B, że byłoby to drogie dla klienta, no i w pewnym momencie rozwoju też by go blokowało.

 

I tu w tym jednym przypadku uzasadnione było, tak w pełni uzasadnione było skierowanie klienta na ścieżkę dedykowanej platformy. I tak się stało. Ten klient zbudował dedykowaną platformę, zrobił te wszystkie dodatkowe funkcjonalności, których nie byliśmy w stanie zrobić. I to do dzisiaj funkcjonuje sprawnie, ale na tyle lat to był jeden przypadek, w którym sama doszłam do przekonania, że dedykowane rozwiązanie będzie najlepsze w tym przypadku dla klienta.

 

W każdym pozostałym przypadku, nawet jak specyfika branżowa czy danej firmy jest duża, to zawsze jakieś 70, 80%, 60 czasem, ale to rzadziej, jesteśmy w stanie wziąć z danego na przykład silnika open source albo znaleźć w rozwiązaniu SaaS-owym, a resztę jakichś specyficznych rzeczy jesteśmy w stanie dorobić na zewnątrz i zintegrować. I wtedy należy zwrócić uwagę tylko na otwartość firmy, danego rozwiązania, na integrację.

 

Więc budowanie dedykowanych platform tam, gdzie nie ma potrzeby, tam, gdzie tylko chcesz po prostu bardziej mieć po swojemu albo żeby to było moje, bo to musi być moje, bo mam taką potrzebę posiadania, że tak powiem. Ale każda właściwie funkcjonalność jest pisana customowo i każda funkcjonalność no nie ma jakiejś standaryzacji. Wtedy te koszty będą rosły. Tak, bo PIM-a można też zrobić na rozwiązaniu open source’owym, które nie jest dedykowane do PIM-a, tylko wtedy będą rosły koszty na przykład integracji, bo masz całkowicie customowe rozwiązanie, więc możesz mieć całkowicie customowe API, a twoje koszty idą w górę.

 

Czy jest sens podczas gdy na rynku są dostępne oprogramowania, które już to robią, które mają ustandaryzowaną ścieżkę, nazewnictwo i API, z którymi wiele innych firm już się połączyło i ma takie integracje gotowe? Czy jest sens wykładać pieniądze na budowanie czegoś od zera? Czy naprawdę to jest dobry pomysł? A jak będzie z utrzymaniem tego? Jak będzie z rozwojem? Czy pracownik, który to robił, albo firma będzie z tobą na zawsze? Czy to jest popularne rozwiązanie, czy będziesz w stanie je później rozwijać przez ludzi, którzy nie mają kompetencji programistycznych, którzy potrafią tylko coś skonfigurować? Tu należy sobie zadać naprawdę mnóstwo pytań, zanim pójdziemy w tego typu rozwiązanie, bo to naprawdę może być niebezpieczna ścieżka.

 

Także ode mnie cztery przykłady, cztery przykłady najczęstsze, jakie widzę na rynku, w które takie ścieżki, w które klienci idą, a które są ewidentnie ścieżką do właśnie blokady biznesu, do takiego vendor lock-in. Jeśli jesteś w którejś z tych ścieżek, pora posłuchać dalszej części, bo powiem tam między innymi o tym, jak się zabrać do tego, żeby z tej sytuacji wyjść.

 

 

Dlaczego firmy wpadają w vendor lock-in?

 

Zanim jeszcze opowiem o tym, jak wyjść z vendor lock-in, to przez chwilę zatrzymajmy się jeszcze na tym etapie zrozumienia, dlaczego firmy w ogóle wpadają w ten vendor lock-in, dlaczego tak się dzieje, bo skoro to jest takie w sumie proste, żeby nie dopuścić do tej sytuacji, bo jest proste, to dlaczego firmy jednak wpadają i dlaczego mamy w ogóle takie zjawisko jak vendor lock-in, o którym coraz częściej się mówi.

 

No niestety powody są czysto, można powiedzieć, ludzkie i organizacyjne. Nie są technologiczne, nie są związane ze złą wolą dostawcy absolutnie. One są typowo ludzkie i związane z tym, jak my podejmujemy decyzje. Związane są z naszą wiedzą, z naszymi kompetencjami, a te zazwyczaj są na niskim poziomie w firmach, szczególnie mniejszych, tak, małych, średnich firmach, które nie budują swoich zespołów IT, kompetencji wewnątrz firmy. No i tu już łatwo o błędne decyzje.

 

Pierwszy taki czynnik, który wpływa na to, to jest po prostu wygoda. Tak. Dostawca zna dobrze nasz biznes. Nie musimy od nowa tłumaczyć, pisać wymagań. Spotykamy się raz na jakiś czas, to mu poopowiadamy, a on coś zrobi. Tak, on coś zrobi, będzie to dobrze. Ma doświadczenie, już nas zna, więc nie musimy otwierać tej ścieżki na nowo z nową firmą, z nowym dostawcą. Będzie nam po prostu łatwiej.

 

Druga rzecz to brak takiego architekta systemowego wewnątrz firmy, czyli kogoś, kto układałby, że tak powiem, te klocki układanki, czyli układałby te systemy według jakiejś strategii, i brak takiego doradztwa po stronie agencji. Agencja nie jest od tego, żeby doradzać ci, jak ma wyglądać architektura systemowa w twojej firmie. Ona jest od tego, żeby wdrożyć konkretne systemy. To jest zewnętrzny podmiot, też firma, która ma swoje cele sprzedażowe i nie zawsze wasze cele są takie same. Czasami są wręcz diametralnie inne i stoicie po dwóch stronach, że tak powiem, barykady i będziecie trochę przeciągać ten sznur, każdy na swoją stronę.

 

Więc nie zawsze jest tak, że ktoś ci po prostu w tym pomoże. Uczciwa firma, która widzi, co się dzieje, powie ci faktycznie, jak jest, i naprowadzi cię na dobrą ścieżkę, ale nie jest to w jej obowiązkach, nie jest to w zakresie też jej interesu, więc niekoniecznie musi na to zwracać uwagę i również prowadzić cię w taki sposób.

 

Często vendor lock-in, tak jak powiedziałam, powstaje etapowo, powstaje latami. To nie jest tak, że to jest jedna decyzja: teraz i wpadamy w vendor lock-in. Tak, on powstaje latami, ponieważ dochodzimy do tego, że mam takie punktowe decyzje, czyli w tym momencie potrzebny jest nam taki i taki system albo funkcjonalność, albo taki moduł do ERPA, a za rok będzie potrzebny inny, a w tym samym roku z innego działu ktoś będzie potrzebował czegoś innego. Tak? Jeżeli nie ma jednej osoby, która by nad tym panowała w firmie, no to zaczyna nam się robić taki zlepek i my nawet tego nie widzimy, bo każdy dział widzi swoje moduły, z których korzysta, swoje kawałki tego wszystkiego.

 

I jeżeli nie ma jednej osoby, która spojrzałaby na to z lotu ptaka i zobaczyła, że powstanie tu coś strasznego i niebezpiecznego, no to my nie mamy tej wiedzy de facto. Tak, brniemy w to przez kolejne lata i nie mamy tej świadomości w ogóle, że my idziemy w złym kierunku. W związku z tym to też nie jest tak, że to jest łatwe do zauważenia, bo bardzo często jest to trudne do zauważenia.

 

Czasami też nie mamy świadomości ryzyka, jakie to niesie ze sobą. Tak, to, co wybieramy, wydaje nam się dobre. Widzimy te pozytywy, szczególnie jeśli jeszcze dostawca te pozytywy nam podkreśla. No a to jest normalne, że będzie nam podkreślał te pozytywy. Nawet nie ze względu na to, że nie wiem, że chciałby źle dla nas, że chciałby nas, nie wiem, broń Boże oszukać, tak? Tylko po prostu każdy, kiedy w coś wierzy, coś robi, to chce to pokazać z jak najlepszej strony. I to jest normalne. I każdy z nas tak robi. Każdy, kto chce coś sprzedać, kto chce kogoś innego do czegoś przekonać, każdy z nas domyślnie, automatycznie w taki sposób to robi.

 

Więc nawet może być taka sytuacja, że nie mamy świadomości tych ryzyk, jakie wiążą się z tym, co my robimy, jakie decyzje podejmujemy. To dopiero później okazuje się po czasie.

 

Kolejna rzecz, jeżeli nie robimy dokumentacji. Ta dokumentacja jest często lekceważona w firmach, tak samo jak umowy prawne, bo po co? Bo to papier na półkę, kto do tego będzie zaglądał? Przecież korzystamy z systemu, to my wiemy, jak z niego korzystać, wiemy, jak go obsługiwać. To po co nam ta dokumentacja? No właśnie. Dokumentacja, tak samo jak umowy, są na czasy gorsze, na czasy złe. Kiedy się coś dzieje, czego nie chcemy, co nie jest dla nas korzystne, wtedy właśnie sięgamy do takiego zasobu, jakim jest dokumentacja. Jeśli tej dokumentacji nie ma, no to nie powiem, gdzie jesteśmy, bo jak mnie oglądacie już kolejny odcinek, to wiecie, co zazwyczaj mówię w takiej sytuacji, gdzie my teraz jesteśmy bez tej dokumentacji. Więc to jest kolejna rzecz, która może nas zgubić, a o którą naprawdę warto zadbać.

 

Kolejna rzecz to brak takich systemów dziedzinowych i integracji między tymi systemami. Jeśli uważamy, że na przykład, a często jest taki pogląd, wiele integracji to jest duże ryzyko, bo te integracje mogą ze sobą nie działać i tak dalej, i budujemy jakiś duży monolit, no to de facto budujemy jeszcze większe ryzyko niż niedziałająca integracja. No zazwyczaj nie jest tak, że wszystkie padną. No chyba, że wszystkie stoją na tym samym serwerze i on naprawdę padnie w jakieś skrajne sytuacje, nie ma kopii zapasowych, ktoś naprawdę czegoś mocno tutaj nie dopilnował, no to wtedy jest ryzyko. Ale to ryzyko naprawdę na wiele sposobów da się minimalizować.

 

Natomiast ryzyko utworzenia monolitu i potem podzielenia go, jakiegoś wyodrębnienia albo wprowadzenia nagle systemów dziedzinowych, no to jest dużo większe ryzyko, dużo bardziej czasochłonne i kosztochłonne niż ryzyko utrzymania prawidłowych integracji między systemami dziedzinowymi, nawet jeśli tych systemów jest sporo.

 

Inna rzecz to już taka bardzo ludzka, to trochę takie działanie na skróty, czyli takie szybkie łatanie, szybkie doklejanie, szybkie wdrażanie jakichś prostych rzeczy, które nam się takie wydają, tak żeby było, czyli nie mamy tutaj takiego myślenia systemowego, strategicznego. Nie mamy tej strategii technologicznej, mamy tylko myślenie właśnie kawałkami, czyli jakby każdy dział, który chce coś zmienić, wprowadzić, też myśli o sobie, o tym kawałku biznesu, który ona musi obsłużyć, tak? O procesach, które musi obsłużyć.

 

I właśnie vendor lock-in to jest efekt braku tej strategii technologicznej, a nie złej woli czy to tych ludzi, którzy podejmują te decyzje, czy złej woli dostawcy. Po prostu brak strategii technologicznej. Jeżeli opierasz swój biznes na technologii, jeżeli dodajesz coraz więcej systemów, a nie tylko masz jakieś, nie wiem, jeden kawałek ERPA, to oprócz strategii sprzedażowej, marketingowej, strategii firmy, o tym się dużo mówi, musisz mieć również strategię technologiczną i musisz mieć kogoś, kto ma kompetencje do tego, żeby cię nauczyć, jak takie rzeczy robić.

 

 

Konsekwencje vendor lock-in

 

Przechodzimy teraz do konsekwencji vendor lock-in. Co cię czeka? Jeśli rzeczywiście już jesteś w takiej sytuacji, jak jesteś, to pewnie już wiele z tych rzeczy wiesz i będzie to oczywiste. Jak nie jesteś, to posłuchaj, co cię może czekać, i jeżeli już pojawiły się te pierwsze symptomy, to warto zacząć działać, żeby je odwrócić.

 

Konsekwencje to na przykład koszt migracji. On rośnie kilka razy. To może być trzy razy, 10 razy, w zależności od tego, do jakiej sytuacji już doszło w firmie. Jeżeli chodzi o ten vendor lock-in, każda zmiana może skutkować tym, że czekasz miesiącami i ponosisz wysokie koszty, co też blokuje rozwój twojego biznesu w takim tempie, w jakim byś chciał.

 

To może być sytuacja, w której dostawca dyktuje ci ceny, a ty, wiedząc, że jesteś uzależniony, nie masz pozycji negocjacyjnej. Ja nie mówię, że słabą, bo słabą często, ale czasami po prostu w ogóle nie masz żadnej pozycji negocjacyjnej. Te ceny są narzucane.

 

Dalej może to skutkować utratą kontroli nad procesami, nad tym, co dzieje się w twojej firmie. Dlatego, że jeżeli długo na przykład czekasz na te zmiany, to musisz funkcjonować w sposób, który jest już nieoptymalny, a który już dobrze wiesz, jak chcesz zmienić. Niestety blokuje cię tutaj właśnie ta technologia, zmiana w technologii.

 

To też jest brak możliwości skalowania swojego biznesu, brak możliwości pójścia dalej, ponieważ już w tym zakresie technologii doszliście do ściany i najpierw trzeba zrobić taki stop i najpierw uporządkować to, co jest, a potem dopiero znów wyruszyć w tą ścieżkę skalowania.

 

To rodzi też duże ryzyko operacyjne, ponieważ jeżeli te procesy nie są optymalne, jeżeli nie możesz ich zmieniać, jeżeli te rozwiązania nie są elastyczne, to może się okazać, że operacyjnie twoja firma w którymś momencie zrobi się po prostu niewydolna. A jeśli to odbije się na obsłudze klienta i na zadowoleniu klienta, no to już są poważne konsekwencje również sprzedażowe, przychodowe. Trochę jak takie domino, jak puścisz jednego klocka w ruch, to on po prostu obala następne i idzie to takim łańcuchem tych zmian, ale zmian niekorzystnych.

 

Kolejna rzecz to też taki strach, tak, technologiczny, zastój technologiczny. Też można o tym tak powiedzieć w firmie. Twoja firma po prostu przestaje się rozwijać technologicznie, przestaje być firmą nowoczesną technologicznie, zostaje zamknięta w jakiejś starej architekturze. Nie zawsze, ale często tak jest i też trzeba na to zwrócić uwagę, dlatego że ta technologia też się zmienia. Ona cały czas żyje. Ona się zmienia. Jeżeli ty nie zmieniasz się w firmie i nie masz ścieżki takiej elastycznej do tej zmiany, no to może się okazać, że ten zastój technologiczny odbije się na takim zastoju w ogóle rozwoju twojej firmy, zastoju w skalowaniu firmy.

 

 

Jak nie wpaść w vendor lock-in?

 

To teraz przechodzimy do tej pewnie najważniejszej części, na którą czekaliście, czyli jak uniknąć vendor lock-in.

 

Po pierwsze, ja zawsze uczę takich trzech zasad, ale po pierwsze: jedno źródło prawdy, czyli jeden system, który trzyma jakieś dane. Jeżeli to są na przykład ceny i dostępność, to umieszczamy je w ERP-ie. To jest nasze źródło prawdy o tych danych. Jeżeli informacja produktowa, to umieszczamy ją w PIM-ie. Jeżeli mamy taką sytuację, że mamy omnichannel, to wtedy może być tak, że źródło pewnych danych może być w różnych miejscach. To znaczy może być wiele źródeł informacji, ale musi być jedno miejsce, które to agreguje. Wtedy możemy tworzyć coś takiego jak hurtownia danych i tam agregować właśnie dane i to będzie to nasze źródło prawdy.

 

Bo żeby wam pokazać na przykładzie, no na przykład ze zgodami marketingowymi może być tak, że wystawiacie jakieś landing page i tam klient musi, żeby się coś zapisać w formularzu na coś, to musi odklikać zgodę marketingową: wyraża lub nie wyraża. W platformie wyraża bądź nie wyraża, może wycofać, jak się zaloguje na swoje konto. W każdym mailu, który dostanie z jakiejś kampanii, na dole ma, bo musi mieć możliwość wycofania zgody marketingowej.

 

I teraz akcje wykonane przez klienta związane z samą tą zgodą marketingową mogą mieć miejsce w różnych systemach i musimy je zbierać w jakimś jednym miejscu, takiej jednej master dacie, jednej bazie danych, i potem propagować je na inne systemy, czy przesyłać, przekazywać do innych systemów, które też te informacje posiadają i w jakimś celu ją wykorzystują. Tak, czyli mamy wiele miejsc wejścia i potem wiele miejsc wyjścia tej informacji, więc potrzebna nam jest, mówiąc kolokwialnie, taka skrzynka, która będzie agregować te informacje.

 

Więc sytuacje są różne. Nie jest zawsze tak idealnie, że zawsze możemy tą jedną kreskę narysować od jednego systemu do drugiego. Czasami jest to bardziej skomplikowane, ale na to też jest rozwiązanie, żeby było to jedno źródło prawdy o konkretnych informacjach. To nie zawsze będzie ten sam system w zależności od tego, jakie to będą dane. Czy to będą dane produktowe, dane o cenach, o dostępnościach, o klientach. Źródłem może być inny system. Raz źródłem danych o klientach może być ERP, a raz może być CRM, jeżeli mamy handlowców i mamy wdrożony CRM. Tak więc źródła też mogą być różne. Nie jest tak, że zawsze w przypadku klientów będzie to to samo źródło. To mocno zależy od tego, jak wygląda twój biznes. Ale powinniśmy dążyć do tego, żeby było jedno źródło prawdy.

 

Kolejna rzecz to systemy dziedzinowe. Jeżeli budujemy systemy dziedzinowe, czyli na przykład PIM to PIM, czyli system do zarządzania informacją produktową, CMS to CMS, CRM to CRM, ERP to system do na przykład zarządzania magazynem, finansami czy logistyką, to wtedy każdy z tych systemów działa w jakimś pewnym standardzie. Oczywiście plus dostosowanie do twojej specyfiki, ale powiedzmy, że w większości te funkcjonalności są jakimś uśrednionym nawet powiedzmy, ale rynkowym standardem. Czyli łatwiej nam wymienić to 1 do 1. Jak wyjmiemy klocek, który jest czerwonym trójkątem, to musimy szukać klocka, który jest czerwonym trójkątem, tak? I możemy sobie to wtedy wymieniać.

 

Jeżeli zrobimy jakiś dziwaczny, fikuśny kształt, to będzie nam dużo trudniej znaleźć system, który odpowiadałby temu wszystkiemu i który możemy wymienić jeden do jednego. Zazwyczaj się tak nie da. Im więcej rzeczy zrobisz na bazie systemów dziedzinowych, rozproszysz trochę też te systemy w zakresie dostawców, czyli nie masz wszystkich systemów od jednego dostawcy, tylko każdy system masz od innego dostawcy, to de facto wtedy bezpieczeństwo twojej firmy rośnie. Jesteś w stanie wymieniać te klocki prawie że jeden do jednego albo czasami jeden do jednego. Jesteś w stanie zmieniać agencję, wymieniać dostawców. Jest to łatwiejsze, jest to bezpieczniejsze dla firmy i nie generuje też dużych kosztów, chociaż może się tak wydawać, ale wcale tak nie jest w zakresie kosztów.

 

I kolejna rzecz, jak uniknąć: nie budować monolitu. Nie budować monolitu, jednego systemu, który miałby i pełniłby funkcję wszystkiego, tak? I PIM-a, i e-commerce’a, i ERPA, i nie wiadomo czego jeszcze. Tak, to jest zawsze niebezpieczne. Tego się nigdy nie da wymienić tak jeden do jednego. To już idzie w bardzo mocne specyfiki. Naprawdę niewiele jest takich biznesów, branż w Polsce, żeby iść w aż tak dedykowane rozwiązania. Nawet systemy ERP produkcyjne są już dzisiaj tak bardzo zaawansowane, tak bardzo rozbudowane, że można wiele, wiele specyficznych nawet, tak jak nam się wydaje, że są specyficzne, naszych procesów, można obsłużyć takim właśnie systemem prawie że gotowym albo nawet gotowym z rynku. Tutaj czasami tylko nasza głowa nas ogranicza w myśleniu właśnie o tych systemach, że my jesteśmy tacy specyficzni, a że te systemy czegoś nie mają lub nie mogą.

 

Kolejna rzecz, jak uniknąć tego vendor lock-in: robić dokumentację. Robić dokumentację, stosować też taką spójną architekturę zaplanowaną według naszej strategii i trzymać do tego dokumentację, żebyśmy wiedzieli, jak mamy to zrobione, jak mamy pointegrowane te systemy.

 

Kolejna rzecz: starać się zastosować na tyle, na ile to się da, standaryzację procesów. Nie zawsze jest tak, że te procesy są takie specyficzne i muszą takie być. Czasami to jest po prostu bałagan, tak, po prostu chaos w firmie, do którego doprowadziliśmy. I warto, zanim do tego chaosu zaczniecie budować dedykowane systemy, warto zrobić jeden krok do tyłu i spróbować uprościć, poczyścić te procesy, zweryfikować, co naprawdę jest konieczne, bo to czasami latami narastało i pewne rzeczy już w ogóle nie są potrzebne, więc zweryfikować to, uprościć i dopiero później wdrażać technologię, a nie odwrotnie.

 

Czyli kierunek standaryzacja, kierunek uproszczenia, czyszczenie również w procesach, nie tylko w danych, żeby uniknąć sytuacji, że tworzycie jakiegoś potworka typowo pod swoje wymagania. To jest chyba najważniejsze takie, można powiedzieć, cztery, pięć rzeczy, które wymieniłam, żeby uchronić się właśnie przed tym vendor lock-in, czyli jeszcze raz: jedno źródło prawdy, systemy dziedzinowe, integracje zamiast monolitu. Dokumentacja i standaryzacja procesów. Pięć. Wyszło mi, że pięć.

 

Pilnujcie się tych elementów, wtedy możecie dużo łatwiej uniknąć właśnie takiego vendor lock-ina.

 

 

Jak wyjść z vendor lock-in? (pierwsze kroki)

 

I na koniec informacja, co zrobić, jeśli już jesteście vender lock-in, a od czego właściwie zacząć w takiej sytuacji.

 

Po pierwsze, zrobić już wspomniany przeze mnie audyt systemów i architektury technologicznej w waszej firmie. Sprawdzić, co dokładnie macie, ile jest tych dodatkowych modułów do ERPA na przykład, czy z wszystkich korzystacie, tych rzeczy, jak i w jakim zakresie w ogóle są wykorzystywane pewne elementy funkcjonalności, bo może się okazać, że kiedyś korzystaliście z tego bardzo mocno, bardzo dużo osób korzystało z tego na przykład w firmie, a teraz coś jest po prostu niepotrzebne, bo już od dawna nie jest wykorzystywane. Jeżeli nie sprawdzaliście, nie monitorowaliście wykorzystania funkcjonalności w jakimś systemie, to można coś takiego wdrożyć, włączyć, poczekać miesiąc, dwa i zobaczyć wyniki, i wtedy dopiero podejmować decyzję.

 

Kolejna rzecz to opisanie procesów. Zacznijcie od opisywania procesów, żeby można było zweryfikować, na ile te procesy są standardowe, na ile mają jakieś specyfiki. I jeżeli byście chcieli iść do innego dostawcy, no to i tak musicie zrobić taką analizę tych procesów, analizę waszych wymagań, więc dobrze zacząć od tego, żeby te procesy opisać i żeby wiedzieć, co wy tak naprawdę macie w środku w tej firmie.

 

Kolejna rzecz to inwentaryzacja integracji. Sprawdzamy, ile tego jest, które systemy się integrują, z którymi, w jakim zakresie, jakie dane wymieniają, jakimi metodami, jak to jest zrobione od strony technologicznej, żebyśmy wiedzieli, co dalej możemy z tym zrobić.

 

Kolejna rzecz, tworzymy taką mapę zależności. W kluczowych procesach, kluczowych elementach i funkcjonalnościach tworzymy mapę zależności między sobą tych systemów, żebyśmy zobaczyli, który z tych klocków w układance jest taki najbardziej newralgiczny, który zrobił się nam takim fundamentem, bo nie zawsze rzeczywiście jest tak, jak nam się na pierwszy rzut oka wydaje, więc warto sobie coś takiego rozpisać.

 

Warto zidentyfikować też te systemy, które są źródłem prawdy. To znaczy, w którym systemie mamy, trzymamy dane i który jest takim właśnie źródłowym, pierwszym, z którego te dane wychodzą i idą dalej do pozostałych systemów. To nam się przyda w kontekście migracji, żebyśmy wiedzieli, w którym systemie mamy zawsze aktualne i najlepiej najszersze dane z danego obszaru.

 

Kolejna rzecz to trzeba określić, które elementy z tej całej układanki, jak już zrobicie te poprzednie punkty, to określamy sobie, które elementy z tej całej układanki możemy wymienić jako pierwsze, czyli które niosą najmniejsze ryzyko, też najmniejsze koszty, tak, dla tych procesów i dla firmy w ogóle. I ryzyko i koszty są tutaj najważniejszymi elementami, więc sprawdźcie, które z tych systemów niosą najmniejsze ryzyko i koszty i które możecie w pierwszej kolejności wymienić.

 

A potem planujemy etapy. Planujemy etapy zmieniania tych systemów, migracji danych, przechodzenia na inne systemy i robimy to krok po kroku, bo musicie pamiętać, że wychodzenie z tego vendor lock-in to nie jest jakaś rewolucja, to jest proces. To jest proces, który trwa zazwyczaj długo, w zależności ile macie tych systemów i jak bardzo jest to skomplikowane to, co zrobiliście, tak, w zakresie architektury systemowej do tej pory w swojej firmie. Więc to musi być nie jak operacja na otwartym sercu, tylko jak taki remont etapami, tak? Pokój po pokoju. Zmieniamy, wymieniamy i coś poprawiamy.

 

Pilnujcie się tej ścieżki. Jeżeli jesteście w takiej sytuacji, zaplanujcie to sobie na nowy rok jako jeden z ważniejszych elementów strategii waszej firmy.

 

Vendor lock-in to nie jest problem techniczny, to problem strategiczny twojej firmy, który potrafi zablokować jej rozwój na wiele lat do przodu. Jeśli po dzisiejszym odcinku zobaczyliście, że w waszej firmie pojawia się kilka chociażby z tych symptomów tego, że jesteście wendorin, to jest to dobry moment, żeby zatrzymać się i sprawdzić, czy technologia, którą macie, wspiera wasz biznes, czy może jesteście już na takim etapie, że ta technologia zaczyna wasz biznes ograniczać.

 

Pamiętajcie o tym, że uzależnienie od jednego systemu albo od jednego dostawcy to jest ryzyko operacyjne, ryzyko finansowe i niemożność skalowania waszej firmy. Że dobra architektura integracji tej dziedzinowej, systemów dziedzinowych daje wam wolność, a nie budowanie monolitu, i że wolność technologiczna to w zasadzie jest wolność biznesowa, więc nie można tego aspektu lekceważyć.