Problem · nieudane wdrożenie systemu

Nieudane wdrożenie systemu: termin minął, a końca nie widać.

Projekt się przeciąga, koszty biegną dalej, a rozmowy o nim robią się coraz ostrożniejsze. Nieudane wdrożenia nie są do siebie podobne i nie leczy się ich tak samo. Od tego rozróżnienia zależy wszystko dalej.

Bogusław Tolarz · aktualizacja: 20 sierpnia 2026

Sygnały, że projekt stoi

Termin przesuwał się już kilka razy, zawsze o „jeszcze miesiąc” i zawsze z dobrym uzasadnieniem.
Ludzie prowadzą równolegle stary sposób pracy — arkusz, zeszyt, osobny plik — bo nowemu nie ufają.
Spotkania statusowe kończą się listą pytań, a nie listą decyzji.
Nikt nie potrafi powiedzieć jednym zdaniem, co się zmieni w dniu, w którym system będzie gotowy.
Rozmowy z wykonawcą coraz częściej dotyczą tego, co było ustalone, a nie tego, co ma działać.
Płacisz jednocześnie za nowy system i za utrzymywanie starego sposobu pracy.

Dlaczego to wygląda właśnie tak

Wdrożenia rzadko się przewracają. One się osuwają. Nie ma dnia, w którym coś pękło i wszyscy to zobaczyli — jest szereg tygodni, z których każdy miał sensowne wytłumaczenie: sezon, choroba, „poczekajmy na dane z księgowości”, jedna rozsądna zmiana zakresu, o którą sam poprosiłeś. Osobno wszystko do obrony. Razem — stan, którego nikt nie nazwał.

Dochodzi do tego coś, o czym mówi się niechętnie: przez pewien czas obu stronom opłaca się tego stanu nie nazywać. Wykonawca ma harmonogram, zespół i fakturę. Zamawiający ma decyzję, którą trzeba by teraz ocenić przed wspólnikiem, zarządem albo przed samym sobą. Milczenie jest krótkoterminowo tańsze i dlatego trwa dłużej, niż powinno.

Kiedy w końcu pada zdanie, że projekt informatyczny się nie udał, przyczyna prawie zawsze leży po obu stronach. Najczęstszy rozkład sił jest taki: wykonawca zbudował to, co zostało opisane, a firma opisała to, co potrafiła opisać, zanim zobaczyła nowy sposób pracy w praktyce. Nikt nie działał w złej wierze — i właśnie dlatego szukanie winnego niczego nie odblokuje.

Warto też zauważyć, kto zwykle odpowiada na to pytanie w internecie: najczęściej firmy, które wdrożenia sprzedają. Wnioski wychodzą wtedy przewidywalne — zabrakło zaangażowania albo wybrano nie ten system. Trudniejsza część, że czasem projekt trzeba po prostu zatrzymać, w takim tekście się nie mieści.

Cztery rodzaje — nie leczy się ich tak samo

Zanim padnie jakakolwiek propozycja, trzeba ustalić, co dokładnie się nie udało. To najczęściej pomijany krok: firma wie, że jest źle, i od razu przechodzi do pytania „zmieniamy dostawcę czy dajemy im jeszcze szansę” — czyli do rozwiązania przed rozpoznaniem. Nieudane wdrożenie ERP i utknięty projekt małego narzędzia mają zresztą ten sam rozkład przyczyn; różnią się tylko skalą rachunku.

Rozjazd zakresu

System opisano tak, jak praca miała wyglądać, a nie jak wygląda. Wyjątki będące w firmie codziennością trafiły do rubryki „przypadek brzegowy, ustalimy później”. Później nadeszło i okazało się, że to połowa ruchu.

Dane, których nie dało się przenieść

Migracja przeszła technicznie, ale kartoteki mają duplikaty, martwe indeksy i pola wypełniane latami według trzech zwyczajów. System działa i pokazuje nieprawdę — a wtedy ludzie przestają wierzyć wszystkiemu, co z niego wychodzi.

Ludzie nie przeszli

Narzędzie działa, szkolenie się odbyło, a praca dalej dzieje się obok. Zwykle nie z niechęci: nowy sposób jest dłuższy o kilka kliknięć w czynności powtarzanej dziesiątki razy dziennie i nikt tego nie zmierzył.

Zepsuta współpraca z wykonawcą

Zmienił się zespół po drugiej stronie, każda zmiana wymaga osobnej wyceny, ustalenia zapadają na rozmowach i nigdzie nie zostają zapisane. Produkt bywa w porządku — nie działa droga dojścia do niego.

W praktyce występują po dwa naraz, bo jeden pociąga drugi: rozjazd zakresu kończy się tym, że ludzie nie przechodzą, a złe dane psują relację z wykonawcą. Ustal, który był pierwszy — tylko on wymaga decyzji teraz.

O co pytam, gdy projekt już stoi

Zadaję je w tej kolejności i zwykle wystarczają, żeby powiedzieć, która droga wyjścia jest u Ciebie realna. Kilka jest niewygodnych — to nie przypadek, bo właśnie te odpowiedzi zmieniają decyzję.

Co dokładnie działa dziś?

Nie „ile procent jest zrobione”, tylko lista rzeczy, których dałoby się użyć jutro rano. Prawie zawsze jest dłuższa, niż wynika z nastroju w firmie — i to od niej liczę wszystko inne.

Kto tego naprawdę używa?

Osobno pytam, kto był na szkoleniu, a osobno, kto wprowadził w systemie coś w zeszłym tygodniu. Różnica między tymi dwiema listami mówi o wdrożeniu więcej niż cały raport ze statusu projektu.

Ile kosztuje miesiąc trwania obecnego stanu?

Abonamenty i raty, godziny pracy równoległej, decyzje czekające, bo nie ma na czym ich oprzeć. Dopóki tej kwoty nie ma, rozmowa o „daniu temu jeszcze trochę czasu” jest rozmową bez ceny.

Co zostało formalnie ustalone i odebrane?

Pytam o dokumenty: zakres, protokoły, korespondencję, w której ktoś coś potwierdził. Nie po to, żeby szukać winnego — po to, żeby wiedzieć, na czym można się oprzeć w rozmowie z wykonawcą.

Czy dane da się z tego wyjąć?

Eksport, format, kto go wykona i w jakim czasie. Zadaję to pytanie wcześnie, bo od odpowiedzi zależy, czy zmiana wykonawcy jest realną opcją, czy tylko scenariuszem na papierze.

Gdybyś zaczynał dziś od zera, zamawiałbyś to samo?

Najbardziej niewygodne pytanie z tej listy i zwykle najbardziej użyteczne. „Nie, dziś wiem, że potrzebujemy czegoś innego” to najtańsza informacja, jaką da się w tym momencie zdobyć.

Co da się z tym zrobić

Firma w takiej sytuacji patrzy zwykle od razu na ostatnią pozycję, bo jest najbardziej stanowcza — a rozstrzygnięcie częściej leży w pierwszych trzech.

1
Zatrzymanie zegara i spisanie stanu
Jedna kartka: co działa, co nie działa, co zostało ustalone, gdzie są dane. Nic tu nie kupujesz i niczego nie przerywasz. Najtańszy możliwy krok — a bez niego każda kolejna decyzja zapada na podstawie tego, kto ostatni był w gabinecie.
2
Zawężenie zakresu do części, która działa
Zamiast czekać na całość, uruchamiasz na poważnie ten fragment, który jest gotowy, i świadomie odkładasz resztę. Różnica między odłożeniem a poślizgiem polega na tym, że odłożenie jest decyzją: ma datę powrotu i nazwisko osoby, która o niej pamięta.
3
Naprawa danych i wejść zamiast systemu
Zaskakująco często to, co w firmie nazywa się wadą systemu, jest wadą tego, co do niego wchodzi. Uporządkowanie kartotek, ustalenie jednego sposobu nazywania rzeczy i zmiana formy, w jakiej dane trafiają do środka, bywa tańsze niż jeden tydzień prac programistycznych.
4
Wznowienie z wykonawcą na nowych warunkach
Jeden pisemny opis stanu docelowego zamiast łańcucha ustaleń z rozmów, ustalona kolejność prac i jasne punkty odbioru, po których widać postęp. Ta droga ma sens, gdy produkt jest w porządku, a zawiodła droga dojścia do niego.
5
Zmiana wykonawcy albo zamknięcie projektu
Najdroższa droga i czasem jedyna sensowna. Ma dwa warunki wstępne: dane muszą dać się wyjąć, a wiedza z ostatnich miesięcy — spisać. Bez tego zaczynasz ten sam projekt drugi raz, z tą samą niewiedzą na starcie.

Najtrudniejsza część tej roboty

Nie technika. Trudne jest ustalenie, jak jest naprawdę — bo każdy relacjonuje ze swojego miejsca i prawie każdy mówi szczerze. Magazyn widzi narzędzie, które przeszkadza. Kierownik widzi ludzi, którzy nie chcą się nauczyć. Wykonawca widzi zakres zmieniany co dwa tygodnie. Trzy prawdziwe opisy, trzy różne wnioski, żaden nie wystarcza do decyzji.

Jest też warstwa emocjonalna i nie ma sensu udawać, że jej nie ma. Ktoś ten system wybrał, obronił i podpisał. Teraz ta sama osoba ma go ocenić — i zwykle jest to osoba, która czyta taki tekst jak ten. Dlatego rozdzielenie „ta decyzja była zła” od „ta decyzja była rozsądna przy tym, co wtedy wiedzieliśmy” jest realną częścią tej pracy.

Do tego wdrożenie pokazuje bałagan, który wcześniej mieścił się w głowach i arkuszach — łatwo pomylić ujawnienie problemu z jego spowodowaniem. Zaczynam więc od ustalenia stanu faktycznego, nawet jeśli wniosek brzmi „tu nie potrzebujesz nikogo z zewnątrz, wystarczy jedna decyzja u siebie”.

Czego bym teraz nie robił

Nie zaczynałbym od szukania winnego

Najbardziej naturalny i najbardziej kosztowny pierwszy ruch. Gdy zaczyna się ustalanie, kto zawinił, ludzie przestają mówić, jak jest naprawdę, i zostają opowieści zamiast stanu faktycznego. Rozliczenie odpowiedzialności ma sens — ale dopiero po ustaleniu faktów.

Nie dokładałbym funkcji, żeby uratować wdrożenie

„Jak dorobimy ten moduł, ludzie w końcu zaczną korzystać” — to zdanie pada w większości projektów, które utknęły. Jeśli prawdziwym powodem jest to, że nowy sposób pracy jest wolniejszy od starego, kolejna funkcja tylko dokłada kliknięć tam, gdzie już jest ich za dużo.

Nie zmieniałbym systemu, zanim wiadomo, co zawiodło

Wymiana narzędzia bez rozpoznania przyczyny to zwykle powtórzenie tej samej historii z innym logo i drugą fakturą. Jeśli projekt rozjechał się na zakresie albo na danych, nowy system odziedziczy ten sam zakres i te same dane.

Nie traktowałbym wydanych pieniędzy jako argumentu

„Za dużo w to włożyliśmy, żeby teraz przerwać” brzmi rozsądnie, a jest odwróconą logiką. Te pieniądze nie wrócą przy żadnej z możliwych decyzji, więc nie powinny w niej uczestniczyć. Liczy się tylko to, ile kosztuje następny miesiąc i co za niego dostajesz.

Bywa, że najlepszą decyzją jest zatrzymanie projektu.

Jeśli sprawa weszła już w spór prawny z wykonawcą, pierwsza rozmowa powinna być z prawnikiem, nie ze mną. Opinia o stanie technicznym bywa wtedy potrzebna, ale służy czemu innemu i powstaje w innym trybie.

Jeśli firma jest w środku sezonu i najbliższe tygodnie zjadają wszystkich, odradzam zaczynanie teraz. Kolejny nieudany podbieg kosztuje więcej niż odłożenie tematu — pod jednym warunkiem: to ma być data w kalendarzu, a nie „jak się uspokoi”.

Jeśli decyzja już zapadła i potrzebne jest tylko jej potwierdzenie z zewnątrz, też odradzam. Może być trafna — po prostu nie ma wtedy czego rozpoznawać.

Zanim się odezwiesz, policz u siebie koszt miesiąca w obecnym stanie: abonamenty i raty za system, plus godziny tracone na prowadzenie pracy w dwóch miejscach razy stawka tych osób. Zestaw tę kwotę z tym, czego spodziewasz się po kolejnym miesiącu czekania. Jeśli wychodzi niewiele — masz czas i nie ma w tym nic złego. Jeśli dużo, to właśnie tej liczby brakowało dotąd na spotkaniach.

Napisz, na czym to stanęło.

Nie musisz mieć uporządkowanej wersji wydarzeń ani dokumentacji pod ręką. Napisz, co miało powstać, co dziś działa i w którym momencie zrobiło się nieprzyjemnie — odpowiem, do którego z czterech rodzajów to według mnie należy i którą drogę wyjścia sprawdziłbym najpierw. Nie mam w ofercie jednego narzędzia, które musiałbym Ci pokazać, więc jedną z możliwych odpowiedzi jest „zatrzymaj to”.

Opisz swoją sytuacjębez płatności i zobowiązań

Jeśli rozważasz start od nowa i tym razem inaczej: jak wybrać system ERP dla małej firmy → A jeśli chcesz najpierw zobaczyć, jak wygląda samo rozpoznanie stanu: przeczytaj przykładową analizę →