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. To historia o nieudanym wdrożeniu autorskiego CRM-u w międzynarodowej korporacji motoryzacyjnej to nie thriller, choć napięcie było nie do zniesienia. 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, bezwartościowych raportów i kwestionowaniu wszystkiego, co opóźniało proces i podnosiło ich własne przychody, liczone w roboczogodzinach.
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 Schrodingera - 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.
Byli w pełni zależni od decyzji klienta, który bał się decydować. Byli blokowani przez IT, które torpedowało nowoczesne rozwiązania. Byli zalewani szumem informacyjnym przez agencję, która sabotowała proces, udając, że pomaga.
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:
- Software house zadaje pytanie o logikę biznesową.
- Managerowie nie znają odpowiedzi i przekazują je do agencji.
- Agencja wraca z dziesięcioma nowymi, nieistotnymi pytaniami.
- Managerowie są jeszcze bardziej zdezorientowani i organizują kolejne spotkanie.
- 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: wnioski i lekcje na przyszłość: jak uniknąć 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?
Ta historia to nie opowieść o technologii, ale o ludziach i procesach. To dowód na to, że największym ryzykiem w projekcie nie jest błędny kod, ale chaos organizacyjny.
Być może właśnie stoisz u progu własnego, wielkiego wdrożenia. Być może widzisz na horyzoncie tych samych Jeźdźców: Niezdecydowanie, Obstrukcję oraz Niekompetencję i zastanawiasz się, jak nie dopuścić ich do głosu.
Jeśli podczas czytania poczułeś dreszcz rozpoznania, nie jesteś sam. Te same mechanizmy destrukcji powtarzają się w projektach na całym świecie. Różnią się tylko imiona aktorów i nazwy systemów.
Jeśli chcesz po prostu porozmawiać o tym, jak zbudować projekt na zaufaniu i zdrowym rozsądku, a nie na strachu i chaosie, jesteśmy do Twojej dyspozycji. Bez presji, bez gotowych ofert. Chętnie posłuchamy i podzielimy się naszym doświadczeniem.
A jeśli na razie wolisz poczytać więcej o tym, jak unikać podobnych pułapek w świecie IT, zapraszamy na naszego bloga. Tam znajdziesz więcej analiz, które pomogą Ci nawigować po skomplikowanym świecie technologii dla biznesu.
Napisz do nas: kontakt@codapi.pl
Czasem zewnętrzna perspektywa pomaga zobaczyć to, co z wewnątrz wydaje się normalne. A czasem po prostu dobrze jest pogadać z kimś, kto rozumie, dlaczego projekty idą nie tak.
Bo najlepszą lekcją jest ta, której uczymy się na cudzych błędach. Zanim przybędą jeźdźcy.