Zmiana dostawcy oprogramowania: jak to zrobić bez chaosu

Zmiana dostawcy oprogramowania w trakcie wdrożenia systemu, aplikacji czy narzędzia dla produkcji brzmi jak stres. Najczęściej problem nie leży w tym, że „ktoś pisał zły kod”, tylko w tym, że projekt przestaje być sterowalny: nie wiadomo, co działa, co jest ryzykiem, ile potrwa dowiezienie i kto za co odpowiada.

Ten artykuł to prosty, nietechniczny przewodnik: jak podejść do przejęcia projektu tak, żeby odzyskać kontrolę i ograniczyć straty.

Kiedy zmiana dostawcy ma sens (sygnały ostrzegawcze)

Jeśli widzisz kilka z poniższych punktów, to zwykle nie jest „chwilowy kryzys”:

• Dostajesz ogólne wiadomości, ale bez konkretów: co jest zrobione, co nie działa, co blokuje.
• Terminy się przesuwają, a uzasadnienia są mgliste albo za każdym razem inne.
• Projekt „trzyma się” na 1–2 osobach („to wie tylko X”).
• Budżet jest wydawany, a wartość biznesowa nie rośnie proporcjonalnie.

Jeśli tak jest, warto myśleć zmianie dostawcy IT lub przynajmniej o uporządkowaniu sytuacji z zewnątrz.

Największy błąd przy zmianie dostawcy IT

Najgorszy scenariusz to: „jedziemy dalej, tylko z nową ekipą”.

Jeżeli wcześniej brakowało przejrzystości, to po zmianie dostawcy chaos zwykle się pogłębia: dochodzi brak kontekstu, różne interpretacje „co miało być”, presja czasu i spory o odpowiedzialność.

Dlatego zmianę dostawcy oprogramowania zaczyna się od odzyskania przejrzystości i kontroli, a dopiero potem od „przyspieszania”.

Co trzeba zabezpieczyć, zanim zacznie się cokolwiek robić

To punkt, który najczęściej decyduje o tym, czy przejęcie będzie „w miarę gładkie” czy bolesne.

Upewnij się, że po stronie firmy są:

• dostępy do wszystkich narzędzi i kont (repozytoria, hosting, analityka, integracje),
• kod i historia zmian (żeby nie „zgadywać”, co było robione),
• backlog / lista funkcji i decyzji (co jest priorytetem i dlaczego),
• dokumentacja użytkowa (jak uruchomić / wdrożyć / testować),
• lista znanych problemów i ryzyk (nawet jeśli niepełna).

Jeśli tego nie ma — to nie jest „drobny brak”. To ryzyko, że nowy dostawca zacznie od odtwarzania wiedzy zamiast od poprawy projektu.

Checklista: 12 pytań, które dają kontrolę (bez technicznej wiedzy)

1. Czy umiemy w 1–2 zdaniach powiedzieć, po co jest ten projekt (cel biznesowy)?
2. Co dziś działa i jest używane przez ludzi?
3. Co nie działa / nie jest używane i dlaczego?
4. Jakie są 3 największe ryzyka, które mogą pogrążyć projekt?
5. Czy firma ma pełne dostępy do kluczowych zasobów projektu?
6. Czy jest właściciel po stronie biznesu, który podejmuje decyzje?
7. Kto testuje i odbiera efekty (konkretne osoby, nie „zespół”)?
8. Co jest „do wycięcia”, bo nie wnosi wartości?
9. Czy wiemy, co jest najpilniejsze dla użytkowników tu i teraz?
10. Czy ktoś potrafi jasno opisać aktualny stan projektu (bez ogólników)?
11. Czy da się pokazać działający element (nawet mały), zamiast obiecywać „już niedługo”?
12. Czy wiemy, kto odpowiada za co: biznes, IT, dostawca?

Im więcej odpowiedzi „nie” — tym bardziej przejęcie powinno zacząć się od uporządkowania, a nie od „dalszego dowożenia funkcji”.

Najczęstsze pułapki (i jak ich uniknąć)

Pułapka 1: „Mamy dokumentację”
Dokumentacja bywa „teoretyczna”. W przejęciu liczy się ta praktyczna: jak uruchomić, jak wdrażać, jak testować, co jest ryzykiem.

Pułapka 2: „Nie ruszajmy, żeby nie pogorszyć”
Brak decyzji kosztuje. Projekt, który stoi, generuje obejścia, frustrację i spadek zaufania — a to uderza w kolejne inicjatywy.

Pułapka 3: „Zróbmy wszystko naraz”
Przejęcie wymaga selekcji. Najpierw porządek i sterowność, potem rozbudowa.

Co możesz zrobić od razu (krótko)

• Poproś swojego aktualnego dostawcę rozwiązań IT o czytelny status: co działa / co nie działa / ryzyka / najbliższe priorytety.
• Sprawdź, czy Twoja firma ma pełne dostępy i czy wiedza nie jest „u dostawcy”.
• Ustal jedną osobę po stronie biznesu, która podejmuje decyzje (to zaskakująco często brakujący element).

Jeśli potrzebujesz wsparcia w sytuacji, gdy projekt utknął albo wymaga przejęcia, w Pragmatic Coders pomagamy właśnie w takich „problematycznych projektach”.

Dla tych, którzy wolą checklisty (2 szybkie linki)

• Lista kontrolna przejęcia projektu
• Jak bezpiecznie zmienić software house w trakcie projektu (praktyczny przewodnik)