- Wybór dostawcy CRM po nieudanym wdrożeniu – jak Project Manager przełamuje bias zespołu? - 10 lipca 2026
- Otwarte oprogramowanie jako dobro publiczne – co to oznacza dla firm wdrażających CRM i HCM? - 8 lipca 2026
- Suwerenność cyfrowa zaczyna się od stosu technologicznego – dlaczego vendor lock-in to ryzyko biznesowe - 29 czerwca 2026
Nieudane wdrożenie CRM zostawia w organizacji więcej niż stratę budżetu. Zostawia filtr, przez który zespół i Zarząd oceniają każdą kolejną propozycję systemu – często nieświadomie odrzucając rozwiązania, które faktycznie odpowiadają na potrzeby firmy. Ten filtr to bias decyzyjny, a wybór dostawcy CRM po nieudanym wdrożeniu wymaga świadomego przełamania właśnie tego mechanizmu, nie tylko oceny nowej oferty. Project Manager, który wraca z rekomendacją nowego dostawcy CRM, nie przekonuje wtedy argumentami merytorycznymi – przekonuje wbrew emocjonalnemu osadowi poprzedniego projektu.
Czym jest bias decyzyjny po nieudanym wdrożeniu CRM?
Bias decyzyjny po nieudanym wdrożeniu to tendencja do oceniania nowych ofert systemów CRM przez filtr przeszłej porażki, nie przez ich rzeczywiste parametry. Psychologowie Daniel Kahneman i Amos Tversky opisali mechanizm awersji do straty (loss aversion) już w 1979 roku (Kahneman, Tversky, Prospect Theory, 1979) – strata boli psychicznie mocniej niż odpowiadający jej zysk, co tłumaczy, czemu organizacje po porażce projektowej wolą nie ryzykować niż spróbować ponownie.
W praktyce bias przyjmuje kilka konkretnych postaw: automatyczne odrzucanie całej kategorii dostawców (np. „więcej Open Source, nigdy więcej”), nadmierną nieufność wobec metodyki, która wcześniej „nie zadziałała”, lub przeciwnie – trzymanie się starego dostawcy z obawy przed nieznanym, nawet gdy system już nie spełnia potrzeb firmy.
Jak nieudane wdrożenie wpływa na pozycję Project Managera?
Project Manager ponosi ciężar rekomendacji, mimo że decyzję ostateczną podejmuje Zarząd. To on przedstawia argumenty za nowym dostawcą, on odpowiada za wynik przed przełożonymi i on zostaje z poczuciem, że kolejna porażka będzie już wyłącznie jego winą – niezależnie od tego, czy poprzednie wdrożenie prowadził. Persony decyzyjne w projektach IT wprost wskazują na obawę o „utratę pozycji w firmie, ocenę kompetencji, awans” jako kluczowy pain point PM-a.
Do tego dochodzi izolacja. PM, który wcześniej samodzielnie „ugasił pożar” po nieudanym projekcie, często zostaje też sam z decyzją o wyborze następnego dostawcy – bez wsparcia zespołu, który wolałby unikać tematu CRM w ogóle.
Jakie są sygnały, że wybór dostawcy odbywa się pod wpływem biasu, nie danych?
Decyzję podjętą pod wpływem biasu rozpoznasz po tym, że kryteria wyboru zmieniają się w reakcji na przeszłość, nie na przyszłość projektu. Konkretne sygnały ostrzegawcze:
Każdy z tych sygnałów wskazuje, że dyskusja przesunęła się z oceny produktu na zarządzanie stresem.
Decyzja pod wpływem biasu a decyzja oparta na strukturze
| Kryterium | Decyzja pod wpływem biasu | Decyzja oparta na strukturze |
| Punkt odniesienia | Emocje po poprzednim projekcie | Zdefiniowane wcześniej kryteria wyboru |
| Ocena dostawcy | Cała kategoria (np. Open Source) na podstawie jednego przypadku | Indywidualna ocena każdej oferty wg tych samych kryteriów |
| Rola referencji | Odrzucane lub przyjmowane bez weryfikacji | Weryfikowane przez rozmowę z klientem referencyjnym |
| Tempo decyzji | Odkładanie bez nowych danych | Harmonogram z konkretnymi punktami kontrolnymi |
| Odpowiedzialność | Skoncentrowana na jednej osobie (PM) | Rozłożona między Zarząd, PM i zespół wdrożeniowy |
Jak Project Manager może zbudować proces wyboru odporny na bias?
Odporność na bias buduje się poprzez rozdzielenie oceny produktu od zarządzania ryzykiem emocjonalnym – to dwa różne zadania, które wymagają różnych narzędzi. Cztery mechanizmy, które PM może wprowadzić przed kolejną rekomendacją:
Pierwszy: sformalizowane kryteria wyboru ustalone przed rozpoczęciem researchu, nie w trakcie rozmów z dostawcami. Kryteria zapisane wcześniej trudniej naginać pod wpływem emocji.
Drugi: rozmowa z klientem referencyjnym z branży zbliżonej do własnej – nie lista logotypów na stronie dostawcy, a możliwość zadania pytań o to, co faktycznie nie zadziałało w poprzednich projektach danego dostawcy.
Trzeci: rozdzielenie odpowiedzialności decyzyjnej między PM, działem IT i Zarządem na piśmie – jasne określenie, kto akceptuje jaki etap, ogranicza poczucie osamotnienia PM-a i realnie rozprasza ryzyko.
Czwarty: audyt przyczyn poprzedniej porażki przed wyborem nowego dostawcy. Statystyki są tu jednoznaczne – Forrester wylicza wskaźnik niepowodzeń projektów CRM na poziomie 45%, Gartner na 50% (za: eVolpe, Błędy we wdrożeniach, które mogą kosztować miliony, 2025) – w większości przypadków przyczyną nie był sam system, a proces zarządzania zmianą. Zrozumienie tego rozróżnienia zmienia sposób, w jaki organizacja ocenia kolejnego kandydata.
Podsumowanie
Wybór dostawcy CRM po nieudanym wdrożeniu to proces decyzyjny, nie tylko techniczny przegląd ofert – wymaga rozpoznania biasu, zanim zacznie on kształtować kryteria wyboru. Project Manager, który oddziela ocenę produktu od zarządzania ryzykiem emocjonalnym, przygotowuje formalne kryteria z wyprzedzeniem i weryfikuje referencje bezpośrednio u klientów, realnie zwiększa szansę na to, że kolejna rekomendacja zostanie oceniona na podstawie faktów, a nie echa poprzedniej porażki.
Jesteś gotowy na prowadzenie dużego projektu wdrożeniowego w Twojej firmie?
Wiesz, o co zapytać dostawcę? Jak przygotować własny zespół? Jak stworzyć skuteczne zapytanie ofertowe? Jaką metodykę wybrać? Na co zwrócić uwagę negocjując umowę wdrożeniową i serwisową?
Specjalnie dla Ciebie stworzyliśmy darmowy kurs mailowy przygotowujący do prowadzenia wdrożeń.
Codziennie przez dwa tygodnie otrzymasz od nas na swoją skrzynkę kolejną dawkę wiedzy, która pozwoli odnaleźć Ci się w tym skomplikowanym procesie.
Darmowy kurs mailowy
Źródła:
- Wybór dostawcy CRM po nieudanym wdrożeniu – jak Project Manager przełamuje bias zespołu? - 10 lipca 2026
- Otwarte oprogramowanie jako dobro publiczne – co to oznacza dla firm wdrażających CRM i HCM? - 8 lipca 2026
- Suwerenność cyfrowa zaczyna się od stosu technologicznego – dlaczego vendor lock-in to ryzyko biznesowe - 29 czerwca 2026


