Czytając ten tekst, pomyślisz może, że to obraz w krzywym zwierciadle. A jednak nie! To nie karykatura. W wielu firmach, zwłaszcza dużych, nadal w taki sposób wdraża się software. Zatem – jak to działa, że nie działa?

Przychodzi biznes do IT…

…i nieśmiało wspomina, że chciałby coś ulepszyć w firmie: lepiej zorganizować pracę, uporządkować ją. Słowem: potrzebny jest nowy system.

– “Na kiedy?” pyta IT.
– “Na wczoraj,” odpowiada biznes. Właśnie mieliśmy spotkanie z prezesem…”
– “Jak dobrze pójdzie, zrobimy to za rok, a jak będą komplikacje, to za trzy lata” – odpowiada IT i wybucha śmiechem.

Tym sposobem time-to-market pozostaje bliżej nieokreślony.

Czy to złośliwość? Gra na zwłokę? Nie, to raczej oznaka bezradności i inercji, które wynikają z braków kadrowych i kompetencyjnych. Branża IT jest jedną z najbardziej “niedotowarowanych”. Ludzi nie wystarcza do utrzymania działających już w firmach systemów, a co dopiero mówić o wdrażaniu kolejnych?
Biznes musi więc poradzić sobie sam. Zabiera swoje “zabawki”, czyli wyobrażenia o wymarzonym narzędziu i próbuje je ukształtować, spisując swoje oczekiwania. Powstaje długa lista pełna wymagań, które – niestety – są kompletnie nietrafione. Dlaczego? Bo biznes nie jest od rozwiązywania tego typu problemów.

 

Biznes robi “swój” biznes…

… czyli produkuje, sprzedaje, dostarcza. Sprzedaż czy produkcja nie zna (i nie musi znać) możliwości, jakie dają nowoczesne technologie ani – tym bardziej – wzorców projektowych. Nie potrafi ocenić: ten jest zły, a ten dobry, więc bierzemy go do firmy. Jest coś jeszcze: biznes podąża utartym szlakiem – szlakiem obowiązujących w firmie od lat schematów. Te nietrafione wymagania projektowe to poniekąd przelane na papier “święte” firmowe procedury.

W ten sposób niechciane dziecko IT i “święty” biznesowy wzorzec w jednym, czyli zamówienie na nowy system, trafiają do działu zakupów. Co robi procurement? Skoro zamówienie przyszło od biznesu, to też traktuje je jako “święte”, a ujęte w nim wymagania uznaje za definicję gotowego produktu. I zaczyna szukanie dostawcy. A że procurement zazwyczaj posługuje się jednym kryterium wyboru, którym jest w 100 procentach cena, szuka dostawcy najtańszego.

Najtańszy dostawca początkowo cieszy się jak dziecko, które dostało wymarzony prezent na Gwiazdkę, tylko jeszcze go nie rozpakowało. Jest zlecenie, duża firma, fajne logo – to będzie dobrze wyglądać w portfolio. Ale gdy zlecenie “rozpakuje”, mina mu rzednie… Bo widzi długą listę wymagań – tych “świętych” procedur. Listę sporządzoną przez biznes, który nie jest ekspertem od wdrożeń IT. Powstaje więc pytanie – jak zrealizować takie zlecenie?

Dostawca próbuje coś z tym fantem zrobić. Przede wszystkim: idzie do autora projektu, czyli biznesu, żeby “u źródła” skonsultować dziwne wymagania. Nic z tego. Z dopracowania szczegółów nic nie wychodzi.

 

Biznes wie, czego chce…

…i ma być tak, jak w zleceniu. Odprawia więc dostawcę z kwitkiem. Dostawca też już wie: że cały ten projekt-prezent to, niestety, bubel. Ale nadal walczy: tym razem próbuje w IT. Trafia do project managera i mówi, że ma problem. Chciałby “dowieźć”, ale do końca nie wie, co… I w dodatku, żeby biznes był zadowolony, i żeby budżet się zgadzał, no i data. Nierealne.

Project manager też widzi, że to wszystko się nie spina. Ale nie jest zainteresowany sukcesem biznesowym projektu i nie ma ochoty wnikać w jego zawiłości, odkręcać, wyjaśniać. Stawia więc sprawę jasno: “Dostarcz tak, jak jest w umowie”. Równie dobrze mógłby powiedzieć “pomidor” – byłoby to tak samo pomocne. Tylko wtedy lepiej byłoby go zastąpić przedszkolakiem, który zrobiłby to z dużo większą radością i wdziękiem.

I wreszcie jest! Któregoś dnia w firmie – zgodnie ze “świętymi” postanowieniami zawartymi w umowie –  debiutuje nowy system. Trochę to trwało, ale uff! Wymagania biznesu spełnione, budżet nie przekroczony, więc wszystko się zgadza. Sukces! Tylko dlaczego nikt nie otwiera szampana? Szybko wychodzi na jaw, że zainwestowano dużo czasu i pieniędzy w system, któremu daleko do ideału.

Ale to jeszcze nie koniec historii o chcianym-niechcianym projekcie. Okazuje się on bardzo niewygodny – nie tylko w użyciu, ale także w CV – tych, którzy go tworzyli. Chcąc nie chcąc, do odpowiedzialności poczuwają się także ci, którzy do jej wzięcia wcześniej nie bardzo się garnęli.

Jak teraz z tego wybrnąć? Po tej wdrożeniowej porażce trzeba się odkuć, czyli uratować projekt. Ale – żeby uratować – trzeba doinwestować. Wydaje się więc kolejne pieniądze, ale jedyny efekt, jaki udaje się uzyskać, to efekt utopionych kosztów.

Nadal nikt się nie cieszy, nawet dostawca, mimo że zarobił więcej niż mu obiecano na starcie. Bo żeby wyprostować to, co zrobił, musi lepić na sznurki i ślinę. Tworzy potworka, którego chętnie by się pozbył, ale nie może – bo tylko on umie się o niego zatroszczyć. Firma uzależnia się od dostawcy, on od firmy. Typowy vendor lock.

 

Biznes ma, czego chciał…

…ale nie jest zadowolony. Trudno być zadowolonym, mając kukułcze jajo zamiast wymarzonego systemu. Ale przecież historia tego wdrożenia mogłaby mieć całkiem inne, pozytywne zakończenie. Pod warunkiem, że ktoś z głową na karku zacząłby ją od pytania: “Kiedy będzie z tego kasa?” Trzeba jednak zakwestionować przestarzały model wdrożeniowy i poszukać innej drogi – zwinnej, w której pracuje się na celach biznesowych, metodą małych kroków, a do rozmów o projekcie siadają biznes i partner-konsultant – a nie dostawca. O tym, że budowa systemu IT metodą małych kroków przynosi lepsze rezultaty pisałem w artykule “Klocki zamiast linii, czyli o szybkim osiąganiu ROI w projektach IT”.

Pytanie tylko – czy jesteś na tyle odważny, aby pójść drogą agile, czy wolisz skończyć z produktem, którego nikt nie chce używać?

 

Posłuchaj, jak o typowych przeszkodach we wdrażaniu projektów IT mówiłem podczas pierwszej edycji kongresu MIT Sloan, zorganizowanej przez prestiżowy magazyn MIT Sloan Management Review Polska.

Autor

  • Jacek Zawłocki
  • Architekt IT, prezes i współzałożyciel Craftware
  • Doświadczony konsultant ds. transformacji cyfrowej i CRM, architekt rozwiązań i integracji. Doskonale zna i rozumie potrzeby biznesu oraz wyzwania stojące przed nowoczesnymi przedsiębiorstwami w erze rewolucji cyfrowej. Uważa, że kluczowe dla powodzenia projektu w organizacjach jest zwinność i umiejętność dostosowania się do zmieniających się oczekiwań biznesu.

    Nadrzędną rzeczą, którą kieruje się w swojej pracy to maksymalizacja wartości dostarczana klientowi. Dzięki temu zbudował zwinną i skuteczną organizację skupioną na sukcesie swoich partnerów biznesowych.

Podobał Ci się mój artykuł?

Jeśli tak, zapraszam Cię do grona najlepiej poinformowanych czytelników bloga. Dołącz do naszego newslettera, a nie ominą Cię żadne nowości.