Trzej jeźdźcy apokalipsy projektowej. Studium przypadku nieudanego wdrożenia CRM

Opisujemy rzeczywisty projekt. Nazwę klienta i szczegóły pozwalające go zidentyfikować pominęliśmy.

Każdy projekt IT ma swoich bohaterów i antagonistów. Czasem jednak role się mieszają, a ci, którzy mieli być strażnikami sukcesu, stają się architektami porażki. Ta historia o nieudanym wdrożeniu autorskiego CRM-u w międzynarodowej korporacji motoryzacyjnej nie jest thrillerem, choć napięcia w niej nie brakuje. To raczej tragedia grecka, gdzie każdy uczestnik, działając zgodnie ze swoją naturą, przyczynia się do nieuchronnej katastrofy.

Wyobraź sobie cyfrowego Świętego Graala: jeden, autorski system, który łączy w sobie sprzedaż, zarządzanie produktem i obsługę klienta. Jedno kliknięcie, by zobaczyć całą historię interakcji, od pierwszego zapytania po serwis gwarancyjny. Dla potężnego koncernu z branży motoryzacyjnej to marzenie miało stać się rzeczywistością. Zgromadzono imponujący budżet, zaangażowano sztaby specjalistów i z wielką pompą rozpoczęto projekt wdrożenia autorskiego systemu CRM.

Zamiast triumfu była jednak spektakularna klęska. Projekt, który miał być dumą firmy, po miesiącach walki i przepalaniu pieniędzy został po cichu zamknięty. Oficjalna przyczyna? Zbyt wysokie koszty.

Prawdziwa przyczyna była jednak znacznie głębsza. To nie technologia zawiodła. Projekt został zniszczony od środka przez Trzech Jeźdźców Projektowej Apokalipsy. To studium przypadku jest ich anatomią.

Prolog: Wielkie ambicje, jeszcze większe nadzieje

Początek był jak z podręcznika zarządzania. Międzynarodowa korporacja z branży automotive postanowiła stworzyć autorski system CRM, który zintegruje zarządzanie produktem, sprzedażą i obsługą posprzedażową. Budżet? Hojny. Deadline? Ambitny, ale realny. Zespół? Najlepsi z najlepszych - przynajmniej na papierze.

W projekcie uczestniczyły cztery strony: wewnętrzny dział IT i bezpieczeństwa korporacji, renomowany software house, zespół managerów ze strony klienta oraz zewnętrzna agencja konsultingowa, która od lat obsługiwała wszystkie procesy operacyjne korporacji. Co mogło pójść nie tak?

Wszystko.

Rozdział 1: Aktorzy dramatu - kto budował, a kto przeszkadzał?

Na polu bitwy o nowy CRM stanęły cztery siły. Niestety, tylko jedna z nich chciała budować.

1. Klient (Managerowie) - Jeździec Niezdecydowania

W korporacyjnej zbroi, z wizją w oczach, ale bez mapy w dłoni. Managerowie po stronie klienta mieli definiować potrzeby i akceptować rozwiązania. To oni mieli wiedzieć, czego potrzebuje biznes, jak powinny wyglądać procesy, jakie funkcjonalności są kluczowe. Problem polegał na tym, że przez lata wszystko robiła za nich zewnętrzna agencja. Byli jak królowie, którzy zapomnieli, jak się rządzi królestwem.

Na spotkaniach projektowych padały pytania:

• "Jak obecnie wygląda proces reklamacji?"
• "Nie wiem dokładnie, agencja się tym zajmuje."
• "Jakie dane są kluczowe w raporcie sprzedażowym?"
• "Musimy zapytać agencję."
• "Kto będzie głównym użytkownikiem systemu?"
• "To zależy... może agencja?"

Każde pytanie o szczegóły wywoływało kaskadę spotkań i niepewności. Strach przed podjęciem złej decyzji paraliżował. Każda propozycja kończyła się sakramentalnym: "Musimy to przedyskutować wewnętrznie". Wewnętrzne dyskusje trwały tygodniami i zwykle kończyły się wnioskiem, że potrzeba więcej czasu lub więcej opinii. Co gorsza, w kulturze korporacyjnej, gdzie błąd może kosztować karierę, nikt nie chciał wziąć na siebie ostatecznej odpowiedzialności. Decyzje nie zapadały, a czas płynął.

2. Wewnętrzne IT i Bezpieczeństwo - Jeździec Obstrukcji

Jako strażnicy firmowej twierdzy, ich zadaniem było zapewnienie bezpieczeństwa. Dział IT wszedł do projektu niczym średniowieczni rycerze w lśniących zbrojach. Ich misja była jasna: żadne dane nie mogą wyciec, żaden haker nie może się wedrzeć, żadne zagrożenie nie może przeniknąć. Jednak ich podejście szybko zmieniło się z partnerskiego w paranoiczne. Zamiast pytać „Jak możemy wdrożyć to bezpiecznie?", ich domyślną odpowiedzią było „Nie, bo to niebezpieczne".

Każda propozycja funkcjonalności przechodziła przez sito wymogów bezpieczeństwa tak gęste, że niewiele przez nie przechodziło. Prosty formularz kontaktowy? Potrzebna trzystronicowa analiza ryzyka. Integracja z istniejącym systemem? Sześć tygodni audytu bezpieczeństwa. Chmura? Nie ma mowy - tylko serwery on-premise, najlepiej w bunkrze.

"Ale przecież konkurencja używa rozwiązań chmurowych bez problemu" - próbował argumentować software house.

"Konkurencja nie ma naszych standardów" - odpowiadał dział IT z dumą godną lepszej sprawy.

Narzucali archaiczne technologie, blokowali dostęp do standardowych narzędzi deweloperskich i wymagali wielotygodniowych audytów dla najprostszych funkcji. Każde ich „nie" i każde „poczekajcie" miało swoją, bardzo wysoką cenę, doliczaną do rachunku projektu.

3. Zewnętrzna Agencja - Jeździec Niekompetencji

Powołani jako ciało doradcze, mieli być głosem procesów obsługowych. Zewnętrzna agencja weszła do projektu jak deus ex machina. Oni znali wszystkie procesy, oni mieli doświadczenie, oni byli niezbędni. Problem? Byli agencją tradycyjną, której kompetencje cyfrowe kończyły się na umiejętności obsługi Excela.

Zamiast wspierać projekt swoją wiedzą operacyjną, agencja zaczęła generować to, co umiała najlepiej - raporty. Setki stron analiz, które nie wnosiły nic poza kolejnymi pytaniami. Każde spotkanie kończyło się listą "punktów do wyjaśnienia", która była dłuższa niż lista tematów, z którymi przyszli.

"Czy system będzie zgodny z naszymi procedurami?" - pytała agencja. "Jakie są wasze procedury?" - odpowiadał software house. "To skomplikowane. Przygotujemy raport."

Raport liczył 87 stron i nie zawierał ani jednej konkretnej procedury. Za to zawierał 43 nowe pytania, które "należy rozważyć przed podjęciem decyzji".

„Doradztwo” polegało na generowaniu setek pytań, tworzeniu wielostronicowych raportów i kwestionowaniu kolejnych decyzji. Proces się wydłużał, a liczba rozliczanych roboczogodzin rosła.

4. Software House - Budowniczowie w Klatce

To oni mieli zbudować system. Posiadali wiedzę, narzędzia i zespół gotowy do pracy. Problem polegał na tym, że budowali na fundamencie, który ciągle się zmieniał. Każda iteracja projektu była kwestionowana przez IT, każda funkcjonalność była niejasna dla managerów, każde rozwiązanie było analizowane przez agencję.

Programiści zaczęli żartować, że piszą kod w stylu Schrödingera - jednocześnie działa i nie działa, dopóki ktoś nie podejmie decyzji. Frustracja rosła wraz z kolejnymi zmianami wymagań.

"W zeszłym tygodniu mówiliście, że ma być tak" - argumentowali. "Tak, ale bezpieczeństwo ma wątpliwości" - odpowiadali managerowie. "A agencja przygotowała analizę" - dodawali. "Która sugeruje, że może powinno być inaczej" - konkludowali.

Zespół wykonawczy pracował bez stabilnych wymagań i zamkniętej ścieżki decyzyjnej. Kolejne wątpliwości działu IT, zmiany po stronie managerów i analizy agencji wracały jako następne poprawki. Kod powstawał, ale cel projektu wciąż się przesuwał.

Z perspektywy czasu software house też powinien był wcześniej postawić granicę: bez właściciela produktu, ustalonego procesu decyzyjnego i wspólnych zasad bezpieczeństwa ten projekt nie był gotowy do rozpoczęcia.

Rozdział 2: Punkty krytyczne - trzy gwoździe do trumny projektu

Ta toksyczna dynamika zrodziła trzy problemy, które ostatecznie pogrzebały projekt.

Gwóźdź #1: Forteca bezpieczeństwa, która broniła przed postępem

Każda propozycja funkcjonalności wpadała w czarną dziurę działu bezpieczeństwa. Prośba o użycie nowoczesnej, standardowej biblioteki open-source kończyła się miesięcznym audytem i finalnym odrzuceniem na rzecz przestarzałego, ale „wewnętrznie zatwierdzonego" rozwiązania. To z kolei wymagało napisania dziesiątek dodatkowych linii kodu, by osiągnąć ten sam efekt. Koszty i frustracja rosły z każdym dniem.

Gwóźdź #2: Próżnia decyzyjna i spirala spotkań

Cykl życia prostego pytania wyglądał następująco:

1. Software house zadaje pytanie o logikę biznesową.
2. Managerowie nie znają odpowiedzi i przekazują je do agencji.
3. Agencja wraca z dziesięcioma nowymi, nieistotnymi pytaniami.
4. Managerowie są jeszcze bardziej zdezorientowani i organizują kolejne spotkanie.
5. Po tygodniu software house wciąż nie ma odpowiedzi, a licznik roboczogodzin bije.

Żaden etap prac nie mógł zostać formalnie zamknięty, bo nikt nie chciał złożyć pod nim swojego podpisu.

Gwóźdź #3: Doradztwo jako sztuka generowania kosztów

Agencja doradcza udowodniła, że można być jednocześnie hamulcem i generatorem kosztów. Ich praca nie wnosiła żadnej wartości merytorycznej, ale doskonale uzasadniała kolejne faktury. Kwestionowali wszystko - od koloru przycisku po architekturę bazy danych - nie oferując żadnej sensownej alternatywy. Byli doskonałym przykładem tego, jak niewłaściwy konsultant może aktywnie niszczyć projekt.

Rozdział 3: Efekt finalny - śmierć przez tysiąc cięć

Początkowo każdy problem wydawał się mały. Tydzień opóźnienia tu, kilka dodatkowych roboczogodzin tam. Ale te małe cięcia sumowały się, tworząc krwawiącą ranę w budżecie. Harmonogram rozciągnął się jak guma, a prognozowane koszty poszybowały w kosmos.

W końcu nadszedł moment prawdy. Na spotkaniu komitetu sterującego przedstawiono zaktualizowany budżet, który wielokrotnie przekraczał pierwotne założenia. Na twarzach zarządu malowało się niedowierzanie i gniew. Decyzja była szybka i brutalna: projekt zostaje zamknięty.

Oficjalna przyczyna porażki: KOSZTY.

Ale koszty nie były chorobą. Były zaledwie jej gorączkowym objawem.

Morał bez moralizowania

Ta historia nie jest wyjątkowa. Dzieje się codziennie w korporacjach na całym świecie. Trzej jeźdźcy apokalipsy projektowej krążą od projektu do projektu, zostawiając za sobą cyfrowy cmentarz niedokończonych systemów.

Co mogło uratować ten projekt? Może odwaga podjęcia decyzji. Może zdrowy rozsądek w kwestiach bezpieczeństwa. Może uczciwe przyznanie się do braku kompetencji. Może po prostu mniej uczestników przy stole decyzyjnym.

Paradoks polega na tym, że każda ze stron działała racjonalnie w ramach swojej logiki. IT chronił firmę przed zagrożeniami. Managerowie chronili siebie przed odpowiedzialnością. Agencja chroniła swoją pozycję. Software house próbował chronić projekt. Suma tych racjonalności dała irracjonalny rezultat.

Epilog: co dalej?

Korporacja nadal potrzebuje CRM-u. Prawdopodobnie kupi gotowe rozwiązanie od międzynarodowego dostawcy. Będzie droższe w utrzymaniu, mniej dopasowane do potrzeb, ale przynajmniej będzie działać. I co najważniejsze, jeśli coś pójdzie nie tak, można będzie winić zewnętrznego dostawcę.

Dział IT dalej pilnuje bezpieczeństwa, teraz jeszcze bardziej restrykcyjnie, w końcu poprzedni projekt pokazał, jak ważna jest ostrożność. Managerowie nauczyli się ważnej lekcji: lepiej nie podejmować decyzji, niż podjąć złą. Agencja przygotowała case study o tym, jak pomogła zidentyfikować ryzyka w projekcie. Software house... cóż, software house ma teraz bogatsze doświadczenie i lepsze historie do opowiadania przy piwie.

A gdzieś tam, w równoległym wszechświecie, istnieje wersja tej historii, gdzie zdrowy rozsądek zwyciężył, projekt się udał, a CRM działa jak marzenie. Ale to już zupełnie inna opowieść.

Posłowie: jak uniknąć projektowej apokalipsy?

Ta historia to bolesna, ale cenna lekcja dla każdego, kto zarządza lub uczestniczy w projektach technologicznych.

• Lekcja 1: Musi istnieć JEDEN, prawdziwy właściciel produktu (Product Owner). Projekt potrzebuje jednej, umocowanej osoby po stronie klienta, która ma wiedzę, władzę do podejmowania decyzji i bierze za nie pełną odpowiedzialność. Bez tego projekt dryfuje ku katastrofie.
• Lekcja 2: IT i Bezpieczeństwo muszą być partnerami, a nie strażnikami. Ich rolą jest umożliwianie biznesu w bezpieczny sposób, a nie blokowanie go w imię teoretycznych zagrożeń. Podejście oparte na analizie ryzyka jest zawsze lepsze niż podejście oparte na strachu.
• Lekcja 3: Weryfikuj kompetencje, a nie tylko nazwy. Zatrudnianie zewnętrznego doradcy bez udokumentowanych, realnych kompetencji w danej dziedzinie to proszenie się o kłopoty. Konsultant musi wnosić wartość, a nie tylko faktury.
• Lekcja 4: Koszt jest wynikiem, a nie przyczyną. Projekt nie upadł, bo był drogi. Stał się drogi, bo upadał z powodu fundamentalnych błędów w zarządzaniu, komunikacji i strukturze. Kontrola nad budżetem zaczyna się od kontroli nad procesem.

Projekt tego motoryzacyjnego giganta nie upadł z powodu błędów w kodzie. Upadł z powodu błędów w ludzkiej dynamice. Został pokonany przez niezdecydowanie, obstrukcję i niekompetencję.

Pamiętajmy: najdroższym elementem każdego projektu IT nie są serwery czy licencje. Jest nim koszt ludzkich dysfunkcji. Inwestycja w jasne zasady, zaufanie i kompetentnych ludzi zawsze będzie tańsza niż sprzątanie po przejściu Trzech Jeźdźców Apokalipsy.

Czy Twój projekt IT też ma swoich jeźdźców?

Jeśli w Twoim projekcie decyzje nie mają właściciela, spotkania mnożą się szybciej niż ustalenia, a wymagania zmieniają się przy każdej rozmowie, warto zatrzymać się, zanim rachunek zacznie rosnąć.

Chcesz spojrzeć na projekt z zewnątrz? Napisz do nas. Bez presji i gotowej recepty - najpierw posłuchamy, jak wygląda sytuacja.

Lepiej rozpoznać jeźdźców przed startem niż spotkać ich w połowie wdrożenia.