Ryzyka zmiany dostawcy oprogramowania: 10 pułapek, o których warto wiedzieć przed wypowiedzeniem umowy

W tym artykule omawiam 10 ryzyk towarzyszących zmianie dostawcy oprogramowania. Pierwsze pięć to ryzyka oczywiste – te, których spodziewa się każdy CTO i Head of Product, kiedy siada do decyzji. Kolejne pięć to ryzyka nieoczywiste – te, które zaskakują dopiero w środku procesu.

Dlaczego decyzja o zmianie dostawcy zwykle zapada za późno

Wbrew pozorom zarządy rzadko podejmują decyzję o zmianie dostawcy pochopnie. Wręcz przeciwnie. Większość firm doskonale zdaje sobie sprawę, jak kosztowna i ryzykowna jest taka operacja, i właśnie ta świadomość sprawia, że dają obecnemu dostawcy kolejne szanse na zbyt długo. W rezultacie decyzja zapada dopiero wtedy, gdy stan projektu jest już znacznie gorszy niż w momencie, w którym pojawiły się pierwsze poważne sygnały.

Paradoks polega na tym, że im dłużej się zwleka, tym większość ryzyk opisanych w tym artykule rośnie.

Oczywiste ryzyka zmiany dostawcy oprogramowania

1. Utrata wiedzy o systemie wraz z odchodzącym zespołem

W każdym projekcie dedykowanego oprogramowania, który trwa dłużej niż rok, stopniowo gromadzi się wiedza, której nie da się wyczytać z samego kodu. To decyzje architektoniczne, które zapadały jako kompromisy, integracje, które dziś wyglądają inaczej niż kiedyś, czy logika biznesowa, którą trudno spisać, bo wielokrotnie się zmieniała. Tę wiedzę mają konkretni inżynierowie po stronie dostawcy – i gdy opuszczają projekt, ona znika razem z nimi.

Badania nad rotacją w zespołach inżynieryjnych określają ten problem jako „parowanie wiedzy architektonicznej” (architectural knowledge vaporization). Gdy lider techniczny opuszcza projekt bez uprzedniego przekazania uzasadnień swoich decyzji, zespół traci zrozumienie kompromisów, których nie widać w samym kodzie. Nowy zespół wie, „co” zostało zrobione, ale nie wie, „dlaczego”. Efekt jest taki, że przez długi czas można bezpiecznie wprowadzać wyłącznie drobne zmiany – dopóki to „dlaczego” nie zostanie na nowo odkryte.

Co z tym zrobić. 

Pogódź się z tym, że części wiedzy architektonicznej nie odzyskasz – „dlaczego” za wieloma decyzjami istnieje wyłącznie w głowach ludzi, którzy je podejmowali, a odtworzenie tego po fakcie to zwykle praca nowego zespołu, nie odchodzącego. Realnie poprawiają sytuację trzy rzeczy. 

Po pierwsze: konkretna lista pytań do odchodzącego dostawcy zamiast prośby o „dokumentację” – 30 precyzyjnych pytań ma szansę dostać odpowiedzi, otwarte „opiszcie architekturę” zwykle nic nie daje. 

Po drugie: krótkie, nagrane sesje walkthrough kluczowych modułów – łatwiej wynegocjować 2 godziny screen-share’u z osobą, która pisała dany kawałek systemu, niż 200 stron dokumentacji powstającej po fakcie. 

Po trzecie: jak tylko nowy zespół przejmie kod, niech zacznie pisać testy charakteryzacyjne utrwalające obecne zachowanie systemu (nawet z błędami). Nie odzyskasz „dlaczego”, ale zabezpieczysz „co” – a to wystarczy, żeby później bezpiecznie refaktoryzować.

2. Mierzenie pierwszych tygodni przejęcia liczbą funkcji

Zarząd – sfrustrowany rozjechaną roadmapą poprzedniego dostawcy – oczekuje szybkiego dowodu, że zmiana działa. Najprostszy dowód, jaki przychodzi do głowy, to nowe funkcje na produkcji. To miara, która w pierwszych 4–8 tygodniach po przejęciu systematycznie wprowadza w błąd.

W dobrze poprowadzonym przejęciu nowy dostawca dostarcza w tym czasie coś cenniejszego niż kolejny feature: odzyskaną kontrolę i informację, na której można oprzeć dalsze decyzje. Raport z audytu kodu z wyceną długu, działający CI/CD, itd. Jeśli zarząd mierzy to liczbą zamkniętych ticketów per sprint, pierwsze tygodnie wyglądają jak regres – „płacimy więcej, a robi się mniej” – i zaufanie wypala się, zanim nowa relacja ma szansę dowieść swojej wartości.

Co z tym zrobić. Nie sprzedawaj zarządowi „okna stabilizacji” – po doświadczeniach z poprzednim dostawcą cierpliwości już nie ma, a 4–8-tygodniowa pauza bez widocznego output bywa po prostu „no go”. Zamiast tego wymagaj od nowego dostawcy planu z mierzalnym output tydzień w tydzień: odzyskane dostępy, raport z audytu, działający CI/CD, baseline’owe testy charakteryzacyjne i commitment na pierwsze konkretne inkrementy biznesowe. Mierzalny postęp tydzień w tydzień zarząd jest w stanie zaakceptować. Jeśli nowy dostawca nie potrafi takiego planu zaproponować, dopiero sam zaczyna się uczyć projektu – a wtedy 4 tygodnie zamieniają się w 4 miesiące.

3. Ukryte koszty rozstania: kary umowne, opłaty za wsparcie w przekazaniu projektu, podwójne faktury

Rzadko kiedy rozstanie z dotychczasowym dostawcą jest bezkosztowe. Materiały Project Management Institute wskazują typowe opłaty związane z zakończeniem współpracy: kary za wcześniejsze rozwiązanie umowy (im bliżej początku kontraktu, tym są wyższe), opłaty za tzw. „transition assistance” (czyli wsparcie przy przekazywaniu projektu przez poprzedniego dostawcę), a także okres wypowiedzenia – zazwyczaj 90 dni – w którym płacisz za pełen zakres usług, choć ich realna wartość zazwyczaj spada.

Dochodzi do tego czas, gdy obaj dostawcy działają równolegle. Najczęściej taki okres nakładania się trwa 4–8 tygodni, a w tym czasie firma płaci za usługi obu partnerów jednocześnie. To wydatek, którego zazwyczaj nie uwzględnia się w tym samym arkuszu kalkulacyjnym, co potencjalne oszczędności — przez co te liczby nigdy się tak naprawdę nie spotkają.

Co z tym zrobić. Przejrzyj umowę pod kątem kosztów wyjścia jeszcze przed decyzją o zmianie dostawcy – to jeden z faktów, na których ta decyzja powinna się opierać, a nie jej konsekwencja. Sprawdź z prawnikiem różnicę między „termination for cause” (wina dostawcy – zwykle bez kar) a „termination for convenience” (decyzja własna – z karami). Jeśli masz dowody niewywiązywania się z SLA (wskaźniki uptime, lista regresji, przesunięte terminy), koszt wyjścia może okazać się znacząco niższy, niż domyślnie zakładasz – co realnie zmienia odpowiedź na pytanie „czy w ogóle stać mnie na zmianę dostawcy”.

4. Niepełny dostęp do kodu, repozytoriów i infrastruktury

W teorii jesteś właścicielem kodu, bo tak mówi umowa. W praktyce, w wielu firmach to dotychczasowy dostawca jest administratorem organizacji w GitHubie czy GitLabie. To on ma dostęp do konta AWS, do bramki płatności, do narzędzi do monitoringu. 

To zjawisko określa się jako vendor lock-in i najczęściej nie jest efektem złej woli, tylko wynikiem wygody. Klient nie chce samodzielnie zarządzać dostępami, więc przekazuje tę odpowiedzialność dostawcy. Po kilku latach okazuje się, że odzyskanie pełnej kontroli to co najmniej dwa tygodnie pracy i trudnych rozmów – zanim nowy dostawca w ogóle będzie mógł zacząć działać.

Co z tym zrobić. Zanim wypowiesz umowę, dyskretnie sprawdź wszystkie dostępy. Upewnij się, że organizacja na GitHubie czy GitLabie jest założona na Ciebie, a nie na poprzedniego dostawcę. Zweryfikuj, czy konta AWS, Azure lub GCP są faktycznie zarejestrowane na Twoją firmę. Sprawdź, do kogo należą domeny, certyfikaty SSL, konta w App Store i Google Play. Ustal też, kto kontroluje klucze do bramki płatności, narzędzi analitycznych oraz systemów do wysyłki maili. Jeśli zauważysz braki, zacznij je stopniowo uzupełniać jeszcze przed podjęciem oficjalnej decyzji o zmianie. Więcej o procesie przejęcia projektu IT znajdziesz w osobnym artykule.

5. Niewystarczająca lub przestarzała dokumentacja

Dokumentacja w projektach dedykowanego oprogramowania ma tę wadę, że starzeje się szybciej niż sam kod. Diagram architektury stworzony podczas piątego sprintu po dwóch latach przedstawia system, który już dawno wygląda inaczej. 

Sytuacja nie jest jeszcze problematyczna, dopóki w projekcie pracują osoby znające system. Kłopot pojawia się w momencie ich odejścia i konieczności wdrożenia nowych członków zespołu. Nieaktualna dokumentacja jest bardziej szkodliwa niż jej brak, bo daje złudne poczucie pewności. Nowy zespół opiera swoje działania na dokumencie opisującym przeszły stan systemu i zderza się z niezgodnościami dopiero w trakcie pracy.

Co z tym zrobić. Zanim wypowiesz umowę, poproś dostawcę o uaktualnienie najważniejszych dokumentów: aktualnego diagramu architektury, opisów działania kluczowych funkcjonalności systemu (np. autoryzacja, płatności, powiadomienia), instrukcji uruchamiania środowiska deweloperskiego oraz listy zależności i wykorzystywanych wersji bibliotek. Potraktuj to jako element bieżącej współpracy, a nie „ekstra usługę”. Miej świadomość, że dokumentacja przygotowana pod presją rozstania może nie być tak rzetelna jak ta opracowywana na bieżąco – ale to wciąż lepsze niż jej brak. Nowy zespół i tak prawdopodobnie będzie musiał ją zweryfikować i uzupełnić, analizując kod źródłowy.

Nieoczywiste ryzyka zmiany dostawcy oprogramowania

6. Oportunistyczne zachowanie odchodzącego dostawcy

To ryzyko prawie nigdy nie pojawia się w analizach, bo trudno otwarcie stwierdzić, że po drugiej stronie kontraktu ludzie mogą nie działać w pełni fair. Niestety, badania pokazują, że to raczej reguła niż wyjątek. Smite i Moe w swoim badaniu opisują, że odchodzący dostawca niemal zawsze przechodzi przez fazę negatywnych emocji – szoku, frustracji, obaw o swoją przyszłość – a to często skutkuje zachowaniami oportunistycznymi podczas przekazywania wiedzy.

Oportunizm rzadko przyjmuje formę otwartego sabotażu. Przejawia się raczej w mniej oczywisty sposób. Przekazanie wiedzy zostaje skrócone, bo „kluczowe osoby są chore”. Dokumentacja powstaje, ale zawiera głównie ogólne informacje, pomijając te naprawdę istotne. Na pytania mailowe nowego zespołu odpowiedzi przychodzą z dużym opóźnieniem. Wybrane komponenty są określane jako „proprietary” i nie są udostępniane. Każde z tych zachowań można łatwo wytłumaczyć, każda pojedyncza decyzja może wydawać się logiczna. Jednak w sumie prowadzi to do opóźnienia projektu nawet o kilka miesięcy.

To ryzyko jest tym większe, im bardziej osobiście odchodzący zespół był związany z produktem. Inżynierowie, którzy budowali system pięć lat, traktują wypowiedzenie jako osobistą porażkę, nawet jeśli formalnie decyzję podjął ich pracodawca. Stąd niechęć do „uczenia konkurencji”.

Co z tym zrobić. Rozstanie przeprowadź z klasą i w sposób profesjonalny, bez niepotrzebnego podkreślania własnej przewagi. Przekaż informację o zmianie dostawcy tak, by inżynierowie nie czuli się upokorzeni. W umowie z poprzednim dostawcą ustal precyzyjne i mierzalne warunki przekazania projektu — określ liczbę godzin sesji wdrożeniowych, maksymalny czas odpowiedzi na pytania nowego zespołu czy szczegółową listę dokumentów i materiałów, które mają zostać przekazane. Zadbaj o to, by wypłata za okres przejściowy była uzależniona od rzeczywistego przekazania tych materiałów, a nie jedynie od upływu czasu. Dobrą praktyką jest też dodanie klauzuli umożliwiającej skontrolowanie, czy przekazanie rzeczywiście zostało wykonane zgodnie z ustaleniami.

7. Pułapka „lepiej przepisać wszystko od zera” u nowego dostawcy

To jeden z najczęściej spotykanych schematów podczas przejmowania projektów IT. Nowy dostawca po otrzymaniu kodu szybko proponuje jego przepisanie od zera. Przytaczane argumenty są techniczne: przestarzała technologia, niska jakość architektury, brak testów czy narastający dług technologiczny. Choć każdy z tych powodów może być uzasadniony, decyzja o całkowitym rewrite nie zawsze jest rzeczywiście najlepszym rozwiązaniem.

Dlaczego nie zawsze? Z dwóch powodów. Po pierwsze, przepisanie kodu od zera daje dostawcy znacznie większą marżę niż stopniowy refaktoring, więc naturalnie bardziej się to opłaca. Po drugie, rewrite oznacza wiele miesięcy, w których produkt nie zyskuje żadnej nowej wartości biznesowej, a w tym czasie ryzyko wystąpienia błędów regresyjnych znacząco rośnie. Joel Spolsky stwierdził kiedyś, że przepisanie systemu od zera to „najgorszy możliwy błąd strategiczny, jaki może popełnić firma”. To podejście wciąż jest szeroko cytowane, bo i dziś pasuje do większości sytuacji branżowych.

Zdarza się, że przy przejęciu systemu pojawia się oczekiwanie przepisania całości kodu od zera. Jednak po przeprowadzeniu audytu często okazuje się, że znacząca część kodu – na przykład około 70% – jest możliwa do dalszego utrzymania. Największe wyzwania zwykle dotyczą kilku obszarów, takich jak dług technologiczny w warstwie integracji, brak CI/CD, brak monitoringu oraz brak testów charakteryzacyjnych. Dopiero po doprowadzeniu tych elementów do oczekiwanego poziomu można merytorycznie zdecydować, które części faktycznie wymagają całkowitego przepisania.

Co z tym zrobić. Zanim zaakceptujesz plan rewrite’u, wymagaj od nowego dostawcy konkretnego uzasadnienia per moduł. Niech wskaże, które elementy nadają się do refaktoringu, a które naprawdę muszą zostać przepisane. Wymagaj wstępnego audytu i planu przejęcia, który balansuje spłatę długu z dostarczaniem nowej wartości biznesowej. 

8. Przerzucanie winy na poprzedniego dostawcę jako długotrwała wymówka

To ryzyko ujawnia się zazwyczaj dopiero po kilku miesiącach od przejęcia projektu i należy do tych trudniejszych do zauważenia. Po zmianie dostawcy każda awaria, opóźnienie czy błąd regresyjny może być tłumaczony jako „dziedzictwo po poprzedniku”. Czasem rzeczywiście tak jest, ale nie zawsze.

Problem polega na tym, że przez pierwsze miesiące po zmianie dostawcy klient zazwyczaj nie jest w stanie ocenić, kiedy tłumaczenia nowego zespołu przestają mieć pokrycie w rzeczywistości. „Stary dług” staje się uniwersalnym usprawiedliwieniem każdego opóźnienia czy błędu. Po pół roku można się zorientować, że nowy dostawca nie tylko nie rozwiązał dawnych problemów, ale dołożył własne – wszystko jednak wciąż jest zrzucane na „dziedzictwo po poprzedniku”. Zaufanie, które miało się odbudować wraz ze zmianą dostawcy, w rzeczywistości nie rośnie, a nowy zespół skutecznie unika odpowiedzialności, tłumacząc się wciąż przeszłością.

Co z tym zrobić. W pierwszym miesiącu po przejęciu projektu poproś nowego dostawcę o sporządzenie i udostępnienie listy „odziedziczonego długu” — czyli konkretnych rzeczy, które wymagają poprawy, z oszacowaniem czasu i kosztów naprawy każdego z punktów. Każda pozycja powinna mieć też określony termin realizacji. Po upływie trzech miesięcy wróć do tej listy i sprawdź postępy. Jeżeli pojawiają się na niej kolejne zadania oznaczone jako „dawne zadłużenie”, a wcześniejsze nadal nie zostały rozwiązane — to sygnał, że pojawił się problem. Warto także ustalić mierzalne wskaźniki, które trudno zmanipulować, np.: liczba incydentów na produkcji, średni czas wdrożenia zmian, czy częstotliwość pojawiania się regresji.

9. Ryzyko luk bezpieczeństwa przy przekazywaniu uprawnień i kluczy

W trakcie zmiany dostawcy organizacja przechodzi przez okres, w którym dziesiątki uprawnień, kluczy i danych dostępowych zmieniają właścicieli. Stary zespół ma jeszcze dostęp do produkcji, bo musi wesprzeć handover. Nowy zespół już ma dostępy, bo musi zacząć pracować. Niektóre konta zostają zapomniane, niektóre hasła nigdy nie są rotowane, niektórzy byli pracownicy starego dostawcy nadal mają działające klucze SSH.

To moment, w którym bezpieczeństwo systemu jest szczególnie narażone, a rzadko kiedy ktoś się do niego odpowiednio przygotowuje. Analizy operacyjnego ryzyka źle zarządzanych zmian dostawców pokazują, że najpoważniejsze luki pojawiają się właśnie w fazie przekazywania uprawnień.

Do tego dochodzi kwestia regulacyjna. Jeśli stary dostawca miał dostęp do danych osobowych (RODO), masz obowiązek udokumentowania usunięcia tych danych po zakończeniu współpracy. Zaniedbanie tego punktu może kosztować więcej niż cała migracja.

Co z tym zrobić. Zacznij od inwentaryzacji wszystkich kont, kluczy i dostępów, które kiedykolwiek otrzymał stary dostawca. Wskaż datę graniczną, po której każdy z nich zostanie rotowany lub odebrany. Zarządź obowiązkową rotację kluczy SSH, tokenów API, haseł do baz danych i kluczy do bramek płatności. Sprawdź historię commitów pod kątem przypadkowych ujawnień danych dostępowych – to częstszy problem, niż się wydaje. Skonsultuj z prawnikiem proces usunięcia danych osobowych po stronie odchodzącego dostawcy i wymagaj pisemnego potwierdzenia.

10. Komponenty współdzielone i biblioteki, które zostają u starego dostawcy

To ryzyko dotyczy szczególnie tych dostawców, którzy realizują wiele projektów, opierając je na swoim wewnętrznym frameworku. „Mamy własny system uwierzytelniania, korzystamy z niego w 30 projektach.” Na pierwszy rzut oka brzmi to korzystnie – aż do chwili, gdy zdecydujesz się na zmianę dostawcy i okazuje się, że ten autorski moduł stanowi własność intelektualną firmy IT, a nie Twoją. Formalnie cały kod Twojego produktu należy do Ciebie. W praktyce jednak – bez dostępu do ich modułu autoryzacji – Twój system po prostu się nie uruchomi.

W umowach o własności kodu często pomijane są tzw. komponenty „wielokrotnego użytku”, które należą do dostawcy. W praktyce może się więc okazać, że istotna część Twojego systemu formalnie wprawdzie jest „na licencji”, ale po zakończeniu współpracy dostawca nie ma już obowiązku jej przedłużać. W takiej sytuacji nowy zespół musi albo przepisać te elementy od początku (co może zająć od kilku tygodni do kilku miesięcy), albo negocjować z poprzednim dostawcą możliwość dalszego korzystania – zwykle na niezbyt korzystnych warunkach.

To samo dotyczy bibliotek open-source z dodatkowymi modyfikacjami, narzędzi do administracji, własnych frameworków testowych, customowych pluginów do CI/CD. Wszystko to może być Twoje formalnie, a praktycznie niewykorzystywalne bez współpracy z poprzednikiem.

Co z tym zrobić. Zanim złożysz wypowiedzenie, poproś dotychczasowego dostawcę o pełną listę wszystkich komponentów wielokrotnego użytku wykorzystanych w Twoim projekcie, wraz z informacją o ich statusie prawnym. Przejrzyj zapisy dotyczące własności intelektualnej w obowiązującej umowie. Jeśli są one sformułowane ogólnie („klient jest właścicielem kodu”), w praktyce mogą okazać się niewystarczające. Przy audycie realizowanym przez nowego dostawcę poproś również o analizę zależności od bibliotek stworzonych przez poprzedniego wykonawcę – to aspekt, który często generuje największe koszty przy przejęciu projektu. Vendor lock-in w projektach IT często przybiera właśnie taką postać: formalnie nie występuje, ale w praktyce uniemożliwia płynne przejęcie systemu.

Podsumowanie

Zmiana dostawcy oprogramowania niemal zawsze okazuje się dużo bardziej skomplikowana, niż można to wywnioskować z kalkulacji przedstawionych w Excelu. 

Najważniejsze, co możesz zrobić przed wypowiedzeniem umowy, to przeprowadzić dyskretny audyt aktualnego stanu projektu. Równie istotne jest wybór nowego dostawcy, który przed wyceną przejęcia samodzielnie przeprowadzi audyt kodu i przedstawi konkretny plan przejęcia, uwzględniający zarówno spłatę długu technologicznego, jak i dalszy rozwój biznesowy.

Jeśli dostrzegasz u siebie więcej niż dwa lub trzy z wymienionych powyżej ryzyk, najpierw zleć nam niezależną ocenę sytuacji, zanim zdecydujesz się wypowiedzieć umowę. Podjęcie decyzji w oparciu o pełny obraz zagrożeń jest dużo mniej kosztowne niż późniejsze korygowanie jej w trakcie migracji.