Możesz negocjować. Możesz się zdenerwować. Możesz nawet powiedzieć, że zmienisz dostawcę.
Tylko czy naprawdę możesz?
Sytuacja, którą warto sobie wyobrazić
Prowadzisz firmę zatrudniającą 150 osób. Od ośmiu lat korzystasz z systemu dostarczanego przez jedną firmę IT.
Na początku współpraca układała się świetnie. Dostawca wdrożył system, przeniósł dane, przeszkolił pracowników. Z czasem zamawiałeś kolejne funkcjonalności.
Nowy sposób naliczania prowizji? Zrobione.
Automatyczna obsługa reklamacji? Zrobione.
Specjalny algorytm oceny klientów, opracowany przez Twój zespół? Też zrobione.
Za każdą z tych rzeczy zapłaciłeś.
Po ośmiu latach system obsługuje praktycznie całą firmę. Zawiera historię klientów, dokumenty, rozliczenia i kilkadziesiąt procesów biznesowych.
I wtedy przychodzi wiadomość o podwyżce.
Zamiast 200 tysięcy złotych rocznie masz płacić 360 tysięcy.
Dzwonisz do konkurencji. Nowy dostawca chętnie wdroży swój system. Potrzebuje jednak kilkunastu miesięcy, żeby przenieść dane, odtworzyć procesy i przygotować wszystkie integracje.
Koszt? Być może milion złotych. Do tego ryzyko przestoju i konieczność przeszkolenia pracowników.
Podwyżka o 160 tysięcy nagle wydaje się mniejszym problemem.
Płacisz.
I właśnie na tym polega vendor lock-in.
Co to jest vendor lock-in?
Vendor lock-in to sytuacja, w której firma staje się tak zależna od jednego dostawcy technologii, że jego zmiana jest bardzo kosztowna, trudna albo ryzykowna.
Nie oznacza to, że dostawca robi coś nieuczciwego.
Czasami po prostu przez lata budowaliście wspólnie rozwiązanie, które tak mocno wrosło w organizację, że trudno je zastąpić.
Problem pojawia się wtedy, gdy koszt odejścia staje się na tyle wysoki, że przestajesz mieć realny wybór.
Można to porównać do wynajmowanego lokalu, w którym przez lata urządzałeś swoją restaurację.
Kupiłeś wyposażenie, wyremontowałeś kuchnię, zainwestowałeś w instalacje. Klienci znają adres, pracownicy znają lokal.
Właściciel budynku podnosi czynsz.
Teoretycznie możesz się wyprowadzić.
Praktycznie oznacza to remont nowego lokalu, przeniesienie wyposażenia, zamknięcie restauracji na kilka tygodni i ryzyko utraty klientów.
Im więcej zainwestowałeś w miejsce, tym trudniej z niego odejść.
Z systemami IT bywa podobnie.
API nie oznacza, że jesteś niezależny
Często słyszę argument: „Nasz system ma API, więc możemy się z nim integrować. Nie jesteśmy uzależnieni od dostawcy”.
To nie takie proste.
API pozwala systemom wymieniać dane i wywoływać określone operacje. Jest bardzo przydatne i często stanowi podstawę dobrze zaprojektowanej architektury.
Ale samo API nie rozwiązuje wszystkich problemów.
Wyobraź sobie, że Twój system udostępnia API do pobierania klientów, dokumentów i rozliczeń.
Możesz zbudować własny portal klienta. Możesz przygotować dodatkowe raporty. Możesz połączyć ERP z innymi aplikacjami.
Świetnie.
Ale co się stanie, jeżeli dostawca podwoi opłatę za podstawową licencję?
Albo zmieni zasady korzystania z API?
Albo uzależni dostęp do części danych od wykupienia dodatkowego modułu?
Twoje aplikacje nadal potrzebują systemu dostawcy, żeby działać.
API ułatwia integrację, ale nie gwarantuje możliwości zastąpienia dostawcy.
Prawdziwą miarą niezależności jest to, jak trudno zastąpić dany komponent bez zatrzymywania firmy.
Najdroższa zależność może być niewidoczna
Jest jeszcze jeden problem, o którym mówi się zdecydowanie za mało.
Know-how.
Wyobraź sobie, że Twój zespół opracował świetny algorytm wyznaczania cen.
Przez lata zbieraliście doświadczenia, analizowaliście zachowania klientów, testowaliście różne podejścia.
W końcu powstał mechanizm, który daje Wam przewagę nad konkurencją.
Idziesz do dostawcy ERP i mówisz:
„Chcemy, żeby system automatycznie wyznaczał ceny według tych reguł”.
Przekazujesz dokumentację, opisujesz wyjątki, tłumaczysz zależności. Dostawca tworzy moduł.
Płacisz za jego wykonanie.
Po pewnym czasie podobny mechanizm pojawia się w standardowej wersji systemu, oferowanej innym klientom.
Czy dostawca miał do tego prawo? To zależy od umowy, zakresu przekazanych informacji, praw do oprogramowania i ochrony tajemnicy przedsiębiorstwa.
Ale zwróć uwagę na coś ważniejszego.
Przekazałeś zewnętrznej firmie wiedzę, którą budowałeś latami.
Nawet jeżeli umowa zabrania jej wykorzystania, pojawia się praktyczny problem: jak udowodnić, że podobne rozwiązanie powstało dzięki Twojemu know-how?
Nie zawsze będzie to proste.
Dlatego ochrony wiedzy biznesowej nie warto opierać wyłącznie na zapisach umownych.
Warto również odpowiednio zaprojektować architekturę systemów.
Dostawca nie musi wiedzieć wszystkiego
Wróćmy do algorytmu wyznaczania cen.
Czy naprawdę musi on znajdować się wewnątrz ERP?
Niekoniecznie.
Można zbudować osobny moduł, który otrzymuje dane potrzebne do obliczeń, wykonuje algorytm i zwraca wynik.
ERP wysyła informacje o zamówieniu.
Moduł oblicza cenę.
ERP otrzymuje gotową kwotę.
To wszystko.
Dostawca ERP nie musi znać wszystkich reguł obliczeniowych, wag, parametrów ani sposobu podejmowania decyzji.
Cała logika może działać w aplikacji kontrolowanej przez Twoją firmę.
Oczywiście nie każdy proces da się w ten sposób odizolować. Czasami integracja wymaga ujawnienia części reguł lub dostępu do dodatkowych danych.
Ale tam, gdzie jest to możliwe, takie podejście daje dwie korzyści.
Po pierwsze, ograniczasz przekazywanie strategicznej wiedzy na zewnątrz.
Po drugie, możesz zmienić ERP bez konieczności odtwarzania całego algorytmu.
Nowy system musi jedynie wiedzieć, jakie dane wysłać i jak odebrać wynik.
Twoje know-how pozostaje tam, gdzie powinno: pod Twoją kontrolą.
Nie musisz wymieniać całego systemu
Kiedy firma odkrywa, że jest mocno uzależniona od dostawcy, naturalną reakcją bywa pomysł wymiany ERP.
To często bardzo kosztowna odpowiedź na problem, który można rozwiązywać stopniowo.
W artykule o rozbrajaniu monolitu opisywałem podejście polegające na wydzielaniu kolejnych funkcjonalności do niezależnych modułów.
Tutaj można zastosować podobną zasadę.
Zamiast wymieniać cały system, wybierz jeden obszar, w którym zależność jest najbardziej dotkliwa.
Na przykład komunikację z klientami.
Dzisiaj wysyłanie wiadomości SMS i e-mail odbywa się przez moduł ERP. Każda zmiana szablonu, dodanie nowego kanału komunikacji czy zmiana sposobu wysyłki wymaga pracy dostawcy.
Można zbudować osobny moduł komunikacyjny.
ERP przekazuje mu informację, co należy wysłać.
Moduł odpowiada za szablony, harmonogramy, dostawców wiadomości, historię komunikacji i obsługę błędów.
Przy następnym pomyśle biznesowym nie musisz zamawiać kolejnej modyfikacji ERP.
Rozwijasz własny moduł.
A kiedy kiedyś zdecydujesz się wymienić ERP, moduł komunikacyjny zostaje.
Wymieniasz tylko sposób połączenia.
Warunek jest jeden: obecny system musi udostępniać odpowiednie możliwości integracji, a sposób ich wykorzystania musi być zgodny z licencją i umową.
A co, jeśli system nie ma API?
To trudniejszy przypadek, ale nie zawsze sytuacja bez wyjścia.
Niektóre starsze systemy udostępniają jedynie bazę danych. Inne pozwalają na eksport plików albo wymianę danych przez określone mechanizmy integracyjne.
W takim przypadku trzeba sprawdzić trzy rzeczy.
Po pierwsze: możliwości techniczne. Czy można bezpiecznie odczytywać dane? Czy istnieje dokumentacja struktury bazy? Czy system pozwala importować wyniki działania zewnętrznych aplikacji?
Po drugie: ograniczenia prawne. Co dopuszcza licencja? Czy klient ma prawo korzystać z bazy w taki sposób? Czy umowa ogranicza integracje lub modyfikacje?
Po trzecie: ryzyko operacyjne. Czy zewnętrzna aplikacja nie naruszy spójności danych? Czy aktualizacja systemu nie zepsuje integracji?
Szczególnie uważałbym na bezpośrednie modyfikowanie tabel i kolumn w bazie dostawcy.
Nawet jeśli technicznie jest to możliwe, może prowadzić do problemów z integralnością danych i przyszłymi aktualizacjami.
Zwykle bezpieczniej jest zbudować własną warstwę danych i mechanizm synchronizacji, niż zmieniać strukturę cudzego systemu.
A jeżeli dostęp jest całkowicie zamknięty?
Wtedy trzeba uczciwie powiedzieć, że możliwości ograniczenia zależności są niewielkie bez współpracy dostawcy lub przygotowania migracji.
Nie każdą blokadę da się obejść technologią.
Jak sprawdzić, czy masz problem z vendor lock-in?
Nie zaczynałbym od analizy kodu ani dokumentacji API.
Zacząłbym od kilku pytań biznesowych.
- Ile kosztowałaby zmiana dostawcy? Nie tylko zakup nowego systemu, ale również migracja danych, odtworzenie procesów, integracje, testy i szkolenia.
- Co się stanie, jeśli dostawca znacząco podniesie ceny? Czy masz alternatywę, którą możesz uruchomić w rozsądnym czasie?
- Które procesy możesz rozwijać samodzielnie? Czy każda nowa funkcjonalność wymaga zlecenia prac obecnemu dostawcy?
- Gdzie znajduje się Twoje know-how? Czy kluczowe algorytmy i reguły biznesowe są udokumentowane i kontrolowane przez Twoją firmę?
- Czy masz dostęp do swoich danych w użytecznej postaci? Sam eksport do pliku nie zawsze wystarcza do odtworzenia działania procesów.
- Czy możesz zastąpić pojedynczy moduł? Czy musisz wymienić cały system, żeby zmienić jeden obszar?
- Co się stanie, jeśli dostawca zakończy współpracę? Czy możesz nadal korzystać z systemu, utrzymywać go i rozwijać zgodnie z posiadanymi prawami?
Odpowiedzi pozwalają ocenić, czy zależność jest akceptowalna, czy zaczyna stanowić realne ryzyko dla biznesu.
Nie każdy vendor lock-in jest zły
Warto zachować rozsądek.
Korzystanie z jednego dostawcy może być bardzo wygodne.
Jeden system, jedna umowa, jeden zespół wsparcia. Mniej integracji i mniej odpowiedzialności po stronie własnego IT.
Czasami takie rozwiązanie jest po prostu najtańsze.
Nie ma sensu budować własnego modułu tylko dlatego, że technicznie jest to możliwe.
Własne oprogramowanie też trzeba utrzymywać, aktualizować, monitorować i zabezpieczać.
Dlatego celem nie powinno być całkowite wyeliminowanie zależności od dostawców.
To prawdopodobnie niemożliwe.
Celem jest świadome zarządzanie zależnością.
Jeśli dostawca zapewnia świetną usługę w rozsądnej cenie, korzystaj z niej.
Ale zadbaj o to, żebyś miał realną alternatywę, gdy warunki przestaną być korzystne.
Jak zacząć rozbrajanie zależności?
Nie proponowałbym wielkiego projektu transformacyjnego na dwa lata.
Zacząłbym od jednego procesu.
Najlepiej takiego, który często się zmienia, generuje wysokie koszty rozwoju albo zawiera istotne know-how.
Następnie:
- Sprawdź, od jakich elementów obecnego systemu zależy ten proces.
- Zweryfikuj możliwości integracji i ograniczenia licencyjne.
- Zaprojektuj granicę między obecnym systemem a nowym modułem.
- Przenieś wybraną logikę do niezależnego rozwiązania.
- Przetestuj działanie, synchronizację danych i scenariusz awarii.
- Sprawdź, czy nowy moduł rzeczywiście można podłączyć do innego systemu.
Ten ostatni punkt jest szczególnie ważny.
Bo można zbudować osobną aplikację, która nadal będzie całkowicie zależna od obecnego ERP.
Wtedy nie rozwiązałeś problemu. Jedynie przeniosłeś go w inne miejsce.
Na koniec
Vendor lock-in nie zaczyna się w dniu, w którym dostawca podnosi ceny.
Powstaje latami.
Z każdą nową funkcjonalnością, kolejną integracją i procesem, który zaczyna działać wyłącznie wewnątrz jednego systemu.
Często nikt nie podejmuje świadomej decyzji o uzależnieniu firmy od dostawcy.
Po prostu tak wychodzi.
Nie oznacza to jednak, że trzeba wszystko wyrzucić i zaczynać od początku.
Można stopniowo wydzielać procesy, budować niezależne moduły, odzyskiwać kontrolę nad danymi i chronić własne know-how.
Dobry dostawca IT powinien pomagać Ci rozwijać biznes, a nie być jedynym powodem, dla którego nie możesz zmienić sposobu jego prowadzenia.
I właśnie o to chodzi w technologicznej niezależności.
Chcesz sprawdzić, jak bardzo Twoja firma zależy od dostawców IT?
W Solvart pomagamy identyfikować zależności od dostawców systemów, projektować niezależne moduły i stopniowo wydzielać procesy biznesowe z istniejących aplikacji.
Nie zaczynamy od propozycji wymiany całego ERP.
Zaczynamy od sprawdzenia, gdzie zależność naprawdę kosztuje Cię pieniądze, ogranicza rozwój albo naraża Twoje know-how.
Porozmawiajmy. Pierwsza konsultacja jest bezpłatna. Przyjrzymy się Twojej sytuacji i sprawdzimy, czy istnieje rozsądny sposób na zmniejszenie zależności bez wielkiej migracji.